Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

Greg KH  writes:

> On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > A handful of boot panics on ARM platforms were bisected to point at
>> > the version of this commit that's in linux-next (commit
>> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> > makes things happy again.
>> >
>> > Upon further digging, it seems that users of devres_alloc() are
>> > relying on the previous behavior of having the memory zero'd which is
>> > no longer the case after $SUBJECT patch.  The change below on top of
>> > -next makes these ARM boards happy again.
>> 
>> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
>
> Can you send this in a format that I can apply it in?  It was whitespace
> damaged.

hmm, sorry about that.  This one should work, though I wonder if Andrew
should pick this up since I think the patch that causes the breakage
came through his tree.

Kevin

---8<
>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated memory.  
However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO which 
leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong 
assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman 
---
 drivers/base/devres.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t size, 
gfp_t gfp,
 {
struct devres *dr;
 
-   dr = alloc_dr(release, size, gfp);
+   dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(>node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t size, 
gfp_t gfp)
 {
struct devres *dr;
 
-   dr = alloc_dr(release, size, gfp);
+   dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
return dr->data;
-- 
1.8.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: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM

[Yinghai Lu]

On Fri, Oct 18, 2013 at 5:38 AM, Vivek Goyal  wrote:
> On Thu, Oct 17, 2013 at 08:50:07PM -0700, Yinghai Lu wrote:
>
> [..]
>> > Previously high reservation (reservation above 896M) will anyway fail. So
>> > instead of failing, if we try reservation in higher memory areas why that
>> > would break old kexec-tools?
>>
>> If thel old kexec-tools would fail, we should let them fail early as 
>> possible,
>> do not reserve at first point.
>
> A user does not care if they get the message "memory nor reserved" or if
> they get the message that "could not find a suitable memory hole at
> address X".

you are asking for trouble.

Now we have two paths:
1. old kernel with old kexec tools. crashkernel=XM, work,
the new kernel with old kexec tools still working with crashkernel=XM
2. old kernel with old kernel tools, crashkernel=XM, not working.
as X is too big.
then user update to new kernel AND new kexec-tools, and crashkernel=XM,high

with this patch, you will need to test new kernel all old kexec tools
to make sure
it will fail later instead of fail early to remind them to update kexec tools.
Also would make user to guess and try to make new kernel to work with old
kexec-tools

>
>>
>> >
>> > IOW, previously anyway kexec-tools will not work as no memory will be
>> > reserved in higher memory area. Now memory will be reserved but old
>> > kexec-tools should fail as it can't load in that area.
>> >
>> > If that works, then one would use crashkernel=X,high only if he is
>> > particualr that memory reservation comes from area above 4G (despite
>> > the fact that same memory could have been reserved below 4G too).
>>
>> My point:
>> Push user to use ",high" as more as possible, so we only to handle one
>> path eventually.
>> for old kernel, leave them to use old grammer. do not need to change it.
>
> I don't understand this. Why we should push users to use ",high" syntax.
> That is an option. Those who want to use it, should use it.
>
> We have been using crashkernel=XM for a long time now. And it makes sense
> to extend this option to be able to reserve memory at higher addresses
> if asked memory is not available at lower addresses.
>
> You are not thinking about ease of use here for existing users.

most existing user don't need to do anything. just with new kernel and
old kexec tools.

those system that did not work kexec before because XM is too big, they have to
update kexec tools, and use ",high"

Make it simple, less error.

>
>>
>> Also boot loader should always have different entry for old kernel and
>> new kernel.
>
> What does memory reservation location has to do with kernel entry point?
> If it is a 64bit bzImage, we will use 64bit entry point by default, isn't
> it? Does not matter whether memory is reserved above 4G or not.
>
> I think it makes sense that existing crashkernel=XM usres be able to
> reserve memory in higher memory area if sufficient memory is not available
> below 896M or below 4G. Those who always want memory reservation above 4G
> they should use ",high" syntax and enforce memory allocation above 4G.

We already support above 4G, what is point for trying below 4G?

You could get more bug report about new kernel with old kexec-tools, as
old kexec-tools could work with range between 896M and 4G in some case,
but not all.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 0/7] 3.0.101-stable review

[Greg Kroah-Hartman]

On Fri, Oct 18, 2013 at 09:39:51PM -0600, Shuah Khan wrote:
> On 10/18/2013 01:52 PM, Greg Kroah-Hartman wrote:
> > NOTE:
> >This is the LAST 3.0.x stable kernel release that I will be doing.
> >After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> >or if you must, 3.4.x series.  For more information about longterm
> >stable releases and how long they will be maintained, please see
> >https://www.kernel.org/category/releases.html
> >
> > This is the start of the stable review cycle for the 3.0.101 release.
> > There are 7 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -
> 
> Patch applied cleanly  yes
> Compile testing  passed
> Boot testing   passed
> dmesg regression testing passed
> Cross-compile testingpassed
> 
> dmesgs look good. No regressions compared to the previous dmesgs for 
> this release. dmesg emerg, crit, alert, err are clean. No regressions
> in warn.

Thanks for testing and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 0/7] 3.0.101-stable review

[Greg Kroah-Hartman]

On Fri, Oct 18, 2013 at 05:19:32PM -0700, Guenter Roeck wrote:
> On Fri, Oct 18, 2013 at 12:52:47PM -0700, Greg Kroah-Hartman wrote:
> > NOTE:
> >   This is the LAST 3.0.x stable kernel release that I will be doing.
> >   After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> >   or if you must, 3.4.x series.  For more information about longterm
> >   stable releases and how long they will be maintained, please see
> >   https://www.kernel.org/category/releases.html
> > 
> > This is the start of the stable review cycle for the 3.0.101 release.
> > There are 7 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> > and the diffstat can be found below.
> > 
> Build results:
>   total: 98 pass: 71 skipped: 16 fail: 11
> 
> qemu tests all passed.
> 
> This matches the results seen with 3.0.100.

Great, thanks for testing and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/11] 3.4.67-stable review

[Greg Kroah-Hartman]

On Fri, Oct 18, 2013 at 09:41:15PM -0600, Shuah Khan wrote:
> On 10/18/2013 01:53 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.67 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Oct 20 19:50:39 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.67-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> Patch applied cleanly  yes
> Compile testing  passed
> Boot testing   passed
> dmesg regression testing passed
> Cross-compile testingpassed
> 
> dmesgs look good. No regressions compared to the previous dmesgs for 
> this release. dmesg emerg, crit, alert, err are clean. No regressions
> in warn.

Thanks for testing and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/11] 3.4.67-stable review

[Shuah Khan]

On 10/18/2013 01:53 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.4.67 release.
There are 11 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Oct 20 19:50:39 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.67-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h



Patch applied cleanlyyes
Compile testing  passed
Boot testing passed
dmesg regression testing passed
Cross-compile testingpassed

dmesgs look good. No regressions compared to the previous dmesgs for 
this release. dmesg emerg, crit, alert, err are clean. No regressions

in warn.

Test systems

Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile 
testing)


alpha   defconfig   Passed
arm defconfig   passed
arm64   defconfig   Not applicable
blackfin defconfig  Passed
c6x dsk6455_defconfig Passed
mipsdefconfig   Passed
mipsel  defconfig   Passed
powerpc wii_defconfig   Passed
sh  defconfig   Passed
sparc   defconfig   Passed
tiletilegx_defconfig Passed

-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/lib: Export fdt routines to modules

[Guenter Roeck]

On 10/18/2013 06:49 PM, Michael Bohan wrote:

On Fri, Oct 18, 2013 at 04:20:09PM -0500, Rob Herring wrote:

On 10/18/2013 02:32 PM, Michael Bohan wrote:

My preference is probably straight libfdt calls, but if others
think that unpacking is a better solution, I'm able to go that
route as well. My only concern there is that we provide a means
to detect invalid dtb image (ex. handle error codes) and also
free the device_node allocations once the device is released.


I think we need to understand what you are putting in the DT first.


That's understandable. Please see my response to Mark.


Given there are other desired uses like overlays which need to add the
necessary loading and unflattening support, a common solution is likely
more desirable.


But by convention, would overlays allow for 'application
specific' data, or are they expected to meet the more rigid
requirements of a real Device Tree?



Not that I am the authority on it, but the idea is that devicetree overlays
will be merged with the existing devicetree, which implies that the same
requirements would apply.

However, you would not really use overlays. You would use the devicetree
infrastructure to create a logically separate instance of a devicetree
to dynamically configure your driver (which I think is an ingenious idea).
I don't think the same rules would or should apply there.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 0/7] 3.0.101-stable review

[Shuah Khan]

On 10/18/2013 01:52 PM, Greg Kroah-Hartman wrote:

NOTE:
   This is the LAST 3.0.x stable kernel release that I will be doing.
   After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
   or if you must, 3.4.x series.  For more information about longterm
   stable releases and how long they will be maintained, please see
   https://www.kernel.org/category/releases.html

This is the start of the stable review cycle for the 3.0.101 release.
There are 7 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-


Patch applied cleanlyyes
Compile testing  passed
Boot testing passed
dmesg regression testing passed
Cross-compile testingpassed

dmesgs look good. No regressions compared to the previous dmesgs for 
this release. dmesg emerg, crit, alert, err are clean. No regressions

in warn.

Test systems

Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile 
testing)


alpha   defconfig   Passed
arm defconfig   not applicable
arm64   defconfig   Not applicable
blackfin defconfig  Passed
c6x defconfig   Not applicable
mipsdefconfig   Passed
mipsel  defconfig   Passed
powerpc wii_defconfig   Passed
sh  defconfig   Passed
sparc   defconfig   Passed
tiletilegx_defconfig Passed 

-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

int3 doing rcu_read_lock()

[Steven Rostedt]

Hey Paul,

I hit this in my tests:

[ 1597.688015] ===
[ 1597.688015] [ INFO: suspicious RCU usage. ]
[ 1597.688015] 3.12.0-rc4-test+ #48 Not tainted
[ 1597.688015] ---
[ 1597.688015] 
/home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:775 
rcu_read_lock() used illegally while idle!
[ 1597.688015] 
[ 1597.688015] other info that might help us debug this:
[ 1597.688015] 
[ 1597.688015] 
[ 1597.688015] RCU used illegally from idle CPU!
[ 1597.688015] rcu_scheduler_active = 1, debug_locks = 0
[ 1597.688015] RCU used illegally from extended quiescent state!
[ 1597.688015] 1 lock held by swapper/0/0:
[ 1597.688015]  #0:  (rcu_read_lock){.+.+..}, at: [] 
rcu_lock_acquire+0x0/0x29
[ 1597.688015] 
[ 1597.688015] stack backtrace:
[ 1597.688015] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-rc4-test+ #48
[ 1597.688015] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To 
be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
[ 1597.688015]  0001 88007a609e78 8151125f 
81a44f38
[ 1597.688015]  81a10490 88007a609ea8 8109abbe 
88007a609f08
[ 1597.688015]  81a407d0 0002  
88007a609ee8
[ 1597.688015] Call Trace:
[ 1597.688015]  <#DB>  [] dump_stack+0x52/0x8b
[ 1597.688015]  [] lockdep_rcu_suspicious+0x109/0x112
[ 1597.688015]  [] __atomic_notifier_call_chain+0x70/0xee
[ 1597.688015]  [] atomic_notifier_call_chain+0x14/0x16
[ 1597.688015]  [] notify_die+0x2e/0x30
[ 1597.688015]  [] do_int3+0x4f/0x9c
[ 1597.688015]  [] int3+0x34/0x50
[ 1597.688015]  [] ? trace_hardirqs_off_caller+0x3f/0xac
[ 1597.688015]  [] ? do_IRQ+0x1/0xa4
[ 1597.688015]  <>[] ? 
common_interrupt+0x6f/0x6f
[ 1597.688015][] ? trace_hardirqs_on+0xd/0xf
[ 1597.688015]  [] ? trace_hardirqs_off_caller+0x3f/0xac
[ 1597.688015]  [] ? default_idle+0x21/0x32
[ 1597.688015]  [] ? default_idle+0x1f/0x32
[ 1597.688015]  [] arch_cpu_idle+0x18/0x22
[ 1597.688015]  [] cpu_startup_entry+0x10b/0x16c
[ 1597.688015]  [] rest_init+0x13a/0x141
[ 1597.688015]  [] ? csum_partial_copy_generic+0x16c/0x16c
[ 1597.688015]  [] start_kernel+0x41c/0x429
[ 1597.688015]  [] ? repair_env_string+0x56/0x56
[ 1597.688015]  [] x86_64_start_reservations+0x2a/0x2c
[ 1597.688015]  [] x86_64_start_kernel+0xeb/0xf2

When function tracing is being enabled, to avoid stop machine we add a
break point to all functions that are about to be traced, convert them,
and then remove them. ftrace adds a breakpoint handler to be called by
int3 that simply skips the code.

The problem is that the do_int3 calls notify_die which does the notify
handler which does a rcu_read_lock().

The problem is if do_IRQ gets called during this transition (as it was
above) from idle. The breakpoint is hit at the beginning of do_IRQ()
before it gets to call irq_enter(), which means rcu_irq_enter() isn't
called either.

I wonder if we should have a rcu_bp_enter(), that basically does what
rcu_irq_enter() does, but it would not be traced.

Thinking about this more, it seems that because breakpoints are used
everywhere function tracing can be used, we may need to fix the
breakpoint code not to call rcu_read_lock() as it can be just as
dangerous to have as function tracing. We may need to have a different
kind of notifier that breakpoints use :-/

Something to talk about in Edinburgh ;-)

-- 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/

Re: [PATCH] acpi: update win8 OSI blacklist

[Felipe Contreras]

On Fri, Oct 18, 2013 at 5:43 AM, Stefan Hellermann
 wrote:
> 2013/10/3 Felipe Contreras 
>>
>> On Thu, Oct 3, 2013 at 12:13 PM, Felipe Contreras
>>  wrote:
>> > More people have reported they need this for their machines to work
>> > correctly.
>> >
>> > https://bugzilla.kernel.org/show_bug.cgi?id=60682
>>
>> Reported-by: Stefan Hellermann 
>
>
> That's not entirely correct! I reported bios version 2.52 is affected, but
> 2.54 is fixed. I think we should match all Lenovo 3259*, but only bios
> version < 2.54

As far as I know there's no way to do a match like that. So we have to
choose, either we apply the blacklist for all, or for none. Since
removing the win8 OSI doesn't cause any negative effects in 2.54, I
say we would do the former.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/lib: Export fdt routines to modules

[Michael Bohan]

On Fri, Oct 18, 2013 at 04:20:09PM -0500, Rob Herring wrote:
> On 10/18/2013 02:32 PM, Michael Bohan wrote:
> > My preference is probably straight libfdt calls, but if others
> > think that unpacking is a better solution, I'm able to go that
> > route as well. My only concern there is that we provide a means
> > to detect invalid dtb image (ex. handle error codes) and also
> > free the device_node allocations once the device is released.
> 
> I think we need to understand what you are putting in the DT first.

That's understandable. Please see my response to Mark.

> Given there are other desired uses like overlays which need to add the
> necessary loading and unflattening support, a common solution is likely
> more desirable.

But by convention, would overlays allow for 'application
specific' data, or are they expected to meet the more rigid
requirements of a real Device Tree?

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/lib: Export fdt routines to modules

[Michael Bohan]

On Fri, Oct 18, 2013 at 07:38:04PM +0100, Mark Rutland wrote:

Hi Mark,

> On Fri, Oct 18, 2013 at 01:44:07AM +0100, Guenter Roeck wrote:
> > On 10/17/2013 04:51 PM, Michael Bohan wrote:
> > > On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> > >> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> > >>> My motivation is actually to use the fdt format as a firmware.
> > >>> I have a requirement to express driver metadata that's loadable
> > >> >from the filesystem. This data is not reasonable to place in the
> > >>> system Device Tree, since it's application specific and does not
> > >>> actually describe hardware. The fact that the format chosen is
> > >>> 'flattened device tree' is merely just a coincidence.
> 
> Michael, could you elaborate on using the fdt format "as a firmware" and
> what driver metadata you need to be loadable from the filesystem?

We have a hardware device in which of its internal register state
is reconfigured for each application that uses it. And we may
need to quickly swap between applications many times within the
life of the system, so all of the data needs to be preloaded
ahead of the time. There's a lot of data that needs to be updated
in one-shot, and unfortunately there's really no great way to
abstract much of this information.

This metadata file is generated by a tool and lives on the
filesystem, and exists mainly so that each higher level
application driver doesn't need to change its code when such
parameters change. We also want it to be human-readable so that
people can view it, and possibly even tweak it by hand. As
mentioned, most of the data represent actual hardware
configurations, but some others describe per application software
implementation details.

> How are you intending to pass the DT to the kernel from userspace?

request_firmware()

> Given that you mention this is application-specific configuration, why
> is using sysfs attributes or some other sort of filesystem interaction
> not appropriate?

Sysfs is another option, but the major problem is that the driver
doesn't know the full list of applications until it reads the
firmware file. So if we went the sysfs route, it seems we'd need
to form some sort of 'virtual device' hierarchy so that the sysfs
files map 1:1 with each application. That is, read the metadata
file, and for each 'application node', instruct the driver to
create a virtual device for that application node, exposing sysfs
files that can hold its data. To me this seems a bit excessive
and complicated.

Another option would to have a flat sysfs representation and
have the write of one special file create an internal application
database entry for that configuration.

The point is, we can't proceed with normal operation until we
have the total list of applications and their respective
properties registered in memory.

But writing all the sysfs files could be expensive. There would
be complicated tables of different formats that would be
consuming to run through all the different possible entries.

To be honest, I mostly just thought the fdt would be a cool
implementation. It handles all of our requirements, while reusing
infrastructure within and external to the kernel.

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtlwifi: rtl8192se: Fix wrong assignment

[Larry Finger]

On 10/18/2013 07:52 PM, Felipe Pena wrote:

There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.

Signed-off-by: Felipe Pena 
---
  drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void 
_rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
  [RF90_PATH_A][chnl - 1];
}
} else {
--


Acked-by: Larry Finger 

John: I forgot to mention this earlier, but when you add your s-o-b, please add 
a Cc for Stable [3.0 +].


Thanks,

Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtlwifi: rtl8192se: Fix wrong assignment

[Larry Finger]

On 10/18/2013 08:05 PM, Joe Perches wrote:

On Fri, 2013-10-18 at 21:52 -0300, Felipe Pena wrote:

There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.

Signed-off-by: Felipe Pena 
---
  drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void 
_rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
  [RF90_PATH_A][chnl - 1];
}


Using min could help minimize typos

pwrdiff_limit[i] = min(pwrdiff_limit[i],
   
rtlefuse->pwrgroup_ht40[RF90_PATH_A][chnl - 1]);


In the initial driver, that would have been true; however, at this point, I 
prefer the patch as submitted. There is less churning of the source.


Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtlwifi: rtl8192se: Fix wrong assignment

[Joe Perches]

On Fri, 2013-10-18 at 21:52 -0300, Felipe Pena wrote:
> There is a typo in the struct member name on assignment when checking
> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses 
> pwrgroup_ht40
> for bound limit and uses pwrgroup_ht20 when assigning instead.
> 
> Signed-off-by: Felipe Pena 
> ---
>  drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c 
> b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> index 5061f1d..92d38ab 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
> @@ -265,7 +265,7 @@ static void 
> _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
>   rtlefuse->pwrgroup_ht40
>   [RF90_PATH_A][chnl - 1]) {
>   pwrdiff_limit[i] =
> -   rtlefuse->pwrgroup_ht20
> +   rtlefuse->pwrgroup_ht40
> [RF90_PATH_A][chnl - 1];
>   }

Using min could help minimize typos

pwrdiff_limit[i] = min(pwrdiff_limit[i],
   
rtlefuse->pwrgroup_ht40[RF90_PATH_A][chnl - 1]);




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 11/13] NTB: convert to dmaengine_unmap_data

[Jon Mason]

On Fri, Oct 18, 2013 at 07:35:31PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Use the generic unmap object to unmap dma buffers.
> 
> As NTB can be compiled without DMA_ENGINE support add

Seems like the stubs should be added outside of this patch.  Also, the
comment implies that NTB could not be compiled without DMA_ENGINE
support before, which it could be.

> stub functions to  for dma_set_unmap(),
> dmaengine_get_unmap_data() and dmaengine_unmap_put().
> 
> Cc: Dan Williams 
> Cc: Vinod Koul 
> Cc: Tomasz Figa 
> Cc: Dave Jiang 
> Cc: Jon Mason 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/ntb/ntb_transport.c | 63 
> +
>  include/linux/dmaengine.h   | 15 +++
>  2 files changed, 61 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index 12a9e83..fc6bbf1 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -1034,7 +1034,7 @@ static void ntb_async_rx(struct ntb_queue_entry *entry, 
> void *offset,
>   struct dma_chan *chan = qp->dma_chan;
>   struct dma_device *device;
>   size_t pay_off, buff_off;
> - dma_addr_t src, dest;
> + struct dmaengine_unmap_data *unmap;
>   dma_cookie_t cookie;
>   void *buf = entry->buf;
>   unsigned long flags;
> @@ -1054,27 +1054,41 @@ static void ntb_async_rx(struct ntb_queue_entry 
> *entry, void *offset,
>   if (!is_dma_copy_aligned(device, pay_off, buff_off, len))
>   goto err1;
>  
> - dest = dma_map_single(device->dev, buf, len, DMA_FROM_DEVICE);
> - if (dma_mapping_error(device->dev, dest))
> + unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
> + if (!unmap)
>   goto err1;
>  
> - src = dma_map_single(device->dev, offset, len, DMA_TO_DEVICE);
> - if (dma_mapping_error(device->dev, src))
> + unmap->addr[0] = dma_map_page(device->dev, virt_to_page(offset),
> +   pay_off, len, DMA_TO_DEVICE);
> + if (dma_mapping_error(device->dev, unmap->addr[0]))
>   goto err2;
>  
> - flags = DMA_COMPL_DEST_UNMAP_SINGLE | DMA_COMPL_SRC_UNMAP_SINGLE |
> + unmap->to_cnt = 1;
> +
> + unmap->addr[1] = dma_map_page(device->dev, virt_to_page(buf),
> +   buff_off, len, DMA_FROM_DEVICE);
> + if (dma_mapping_error(device->dev, unmap->addr[1]))
> + goto err2;
> +
> + unmap->from_cnt = 1;
> +
> + flags = DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP |
>   DMA_PREP_INTERRUPT;
> - txd = device->device_prep_dma_memcpy(chan, dest, src, len, flags);
> + txd = device->device_prep_dma_memcpy(chan, unmap->addr[1],
> +  unmap->addr[0], len, flags);

I must say, as a user I dislike this interface much less than the
previous.  Can we abstract all of this away in a helper function
that simply takes the src, dest, and len, then maps and calls
device_prep_dma_memcpy?  The driver does not keep track of the
dmaengine_unmap_data, so the helper function could simply return an
error if something isn't happy.  Thoughts?

Thanks,
Jon

>   if (!txd)
> - goto err3;
> + goto err2;
>  
>   txd->callback = ntb_rx_copy_callback;
>   txd->callback_param = entry;
> + dma_set_unmap(txd, unmap);
>  
>   cookie = dmaengine_submit(txd);
>   if (dma_submit_error(cookie))
>   goto err3;
>  
> + dmaengine_unmap_put(unmap);
> +
>   qp->last_cookie = cookie;
>  
>   qp->rx_async++;
> @@ -1082,9 +1096,9 @@ static void ntb_async_rx(struct ntb_queue_entry *entry, 
> void *offset,
>   return;
>  
>  err3:
> - dma_unmap_single(device->dev, src, len, DMA_TO_DEVICE);
> + dmaengine_unmap_put(unmap);
>  err2:
> - dma_unmap_single(device->dev, dest, len, DMA_FROM_DEVICE);
> + dmaengine_unmap_put(unmap);
>  err1:
>   /* If the callbacks come out of order, the writing of the index to the
>* last completed will be out of order.  This may result in the
> @@ -1245,7 +1259,8 @@ static void ntb_async_tx(struct ntb_transport_qp *qp,
>   struct dma_chan *chan = qp->dma_chan;
>   struct dma_device *device;
>   size_t dest_off, buff_off;
> - dma_addr_t src, dest;
> + struct dmaengine_unmap_data *unmap;
> + dma_addr_t dest;
>   dma_cookie_t cookie;
>   void __iomem *offset;
>   size_t len = entry->len;
> @@ -1273,28 +1288,42 @@ static void ntb_async_tx(struct ntb_transport_qp *qp,
>   if (!is_dma_copy_aligned(device, buff_off, dest_off, len))
>   goto err;
>  
> - src = dma_map_single(device->dev, buf, len, DMA_TO_DEVICE);
> - if (dma_mapping_error(device->dev, src))
> + unmap = dmaengine_get_unmap_data(device->dev, 1, GFP_NOIO);
> + if (!unmap)
>   goto err;
>  
> - flags = DMA_COMPL_SRC_UNMAP_SINGLE | 

Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x

[Javier Martinez Canillas]

On Sat, Oct 19, 2013 at 1:14 AM, NeilBrown  wrote:
> On Fri, 18 Oct 2013 12:12:48 +0200 Javier Martinez Canillas
>  wrote:
>
>> On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown  wrote:
>> > On Sat,  5 Oct 2013 13:17:09 +0200 Andreas Fenkart  
>> > wrote:
>> >
>> >> The am335x can't detect pending cirq in PM runtime suspend.
>> >> This patch reconfigures dat1 as a GPIO before going to suspend.
>> >> SDIO interrupts are detected with the GPIO, while in runtime
>> >> suspend, standard detection of the module block otherwise.
>> >>
>> >> Signed-off-by: Andreas Fenkart 
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
>> >> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> >> index 1136e6b..146f3ad 100644
>> >> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> >> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> >> @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
>> >>  ti,needs-special-reset: Requires a special softreset sequence
>> >>  ti,needs-special-hs-handling: HSMMC IP needs special setting for 
>> >> handling High Speed
>> >>  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
>> >> -SDIO irq while in suspend. Fallback to polling. Affected chips are
>> >> -am335x,
>> >> +SDIO irq while in suspend. The workaround is to reconfigure the dat1 
>> >> line as a
>> >> +GPIO upon suspend. Beyond this option and the GPIO config, you also need 
>> >> to set
>> >> +named pinctrl states "default", "active" and "idle ", see example below. 
>> >>  The
>> >> +MMC driver will then then toggle between default and idle during the 
>> >> runtime
>> >> +Affected chips are am335x,
>> >>
>> >>  --
>> >>  | PRCM |
>> >> @@ -49,3 +52,24 @@ Example:
>> >>   vmmc-supply = <>; /* phandle to regulator node */
>> >>   ti,non-removable;
>> >>   };
>> >> +
>> >> +[am335x with with gpio for sdio irq]
>> >> +
>> >> + mmc1_cirq_pin: pinmux_cirq_pin {
>> >> + pinctrl-single,pins = <
>> >> + 0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
>> >> + >;
>> >> + };
>> >> +
>> >> + mmc1: mmc@4806 {
>> >> + ti,non-removable;
>> >> + bus-width = <4>;
>> >> + vmmc-supply = <_reg>;
>> >> + vmmc_aux-supply = <>;
>> >> + ti,quirk-swakeup-missing;
>> >> + pinctrl-names = "default", "active", "idle";
>> >> + pinctrl-0 = <_pins>;
>> >> + pinctrl-1 = <_pins>;
>> >> + pinctrl-2 = <_cirq_pin>;
>> >> + ti,cirq-gpio = < 28 0>;
>> >> + };
>> >
>> >
>> > hi,
>> >  I've been trying to get SD irq to work on my  OMAP3 DM3730.
>> > I seems to need the magic to catch interrupts while FCLK is off, as
>> > the only way I can get it to work at the moment is to keep FCLK on.
>> >
>> > I discovered your patch and tried it out, but it doesn't seem to work for 
>> > me.
>> >
>> > I have a Libertas WIFI chip attached to the second mmc (which is sometimes
>> > called mmc1, and sometimes mmc2 - very confusing!).
>>
>> Hi Neil,
>>
>> I have a DM3730 board with the same setup, Libertas (Marvell SD8686)
>> wifi + bt chip attached to mmc2.
>>
>> I was going to try to add support for this to the DTS but it would be
>> great if I can use your as a reference.
>>
>> Would you be so kind to share your DTS?
>>
>
> My DTS is below.  It contains an number of things that are not supported in
> mainline yet.  Details can be found in
>git://neil.brown.name/gta04 mainline
> and
>http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/mainline
> (this is my working tree and gets rebased and messed up regularly).
>
> NeilBrown
>

Hello Neil,

Thanks a lot for your DTS and the pointers to your trees.

Best regards,
Javier

> /*
>  * Copyright (C) 2013 Marek Belisko 
>  *
>  * Based on omap3-beagle-xm.dts
>  *
>  * 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.
>  */
> /dts-v1/;
> #define RFKILL_TYPE_GPS 6
> #include "omap36xx.dtsi"
>
> / {
> model = "OMAP3 GTA04";
> compatible = "ti,omap3-gta04", "ti,omap3";
> chosen {
> bootargs = "console=ttyO2,115200n8 vram=12M 
> omapfb.rotate_type=0 omapdss.def_disp=lcd root=/dev/mmcblk0p2 rw 
> rootfstype=ext3 rootwait twl4030_charger.allow_usb=1 
> musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel no_console_suspend";
> };
>
> cpus {
> cpu@0 {
> cpu0-supply = <>;
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x8000 0x2000>; /* 512 MB */
> };
>
> aux-keys {
> compatible = "gpio-keys";
>
> aux-button {

Re: [PATCH] time: Fix signedness bug in sysfs_get_uname() and its callers

[Patrick Palka]

On Fri, Oct 18, 2013 at 8:16 PM, John Stultz  wrote:
> On 10/11/2013 10:11 AM, Patrick Palka wrote:
>> sysfs_get_uname() is erroneously declared as returning size_t even
>> though it may return a negative value, specifically -EINVAL.  Its
>> callers then check whether its return value is less than zero and indeed
>> that is never the case for size_t.
>>
>> This patch changes sysfs_get_uname() to return ssize_t and makes sure
>> its callers use ssize_t accordingly.
>
> So a similar fix has already been queued in tip/timers/core, but this
> seems more complete, so I've resolved the collisions with the earlier
> fix and queued it for 3.13.
>
> Would you please take a look at the resulting commit and double check I
> didn't flub the conflict resolution?
>
> https://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=commitdiff;h=891292a767c2453af0e5be9465e95b06b4b29ebe;hp=b7bc50e45111e59419474154736f419a555158d9

Looks good.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtlwifi: rtl8192se: Fix wrong assignment

[Felipe Pena]

There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.

Signed-off-by: Felipe Pena 
---
 drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void 
_rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
  [RF90_PATH_A][chnl - 1];
}
} else {
--
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] tracing: creates 'tracing_is_disabled()'

[Geyslan G. Bem]

This patch creates the function 'tracing_is_disabled', which
can be used outside trace.c.

Signed-off-by: Geyslan G. Bem 
---
 kernel/trace/trace.c | 5 +
 kernel/trace/trace.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..d7ceaf6 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2964,6 +2964,11 @@ int tracing_open_generic(struct inode *inode, struct 
file *filp)
return 0;
 }
 
+bool tracing_is_disabled(void)
+{
+   return (tracing_disabled) ? true: false;
+}
+
 /*
  * Open and update trace_array ref count.
  * Must have the current trace_array passed to it.
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 10c86fb..5deaa3b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -514,6 +514,7 @@ void tracing_reset_online_cpus(struct trace_buffer *buf);
 void tracing_reset_current(int cpu);
 void tracing_reset_all_online_cpus(void);
 int tracing_open_generic(struct inode *inode, struct file *filp);
+bool tracing_is_disabled(void);
 struct dentry *trace_create_file(const char *name,
 umode_t mode,
 struct dentry *parent,
-- 
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: linux-next: Tree for Oct 17 (pinctrl-single.c)

[Randy Dunlap]

On 10/18/13 17:39, Tony Lindgren wrote:
> * Tony Lindgren  [131018 16:49]:
>> * Randy Dunlap  [131018 16:41]:
>>> On 10/18/13 16:39, Tony Lindgren wrote:

 Looks like we need a little bit of arch specific handling
 with the generic IRQ. Fix the issue with an ifdef the
 same way as other drivers do.

 ARM needs things set to IRQF_VALID, which also then sets
 noprobe. Others seem to use just irq_set_noprobe().

 Otherwise we can get:

 drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
 drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
 function 'set_irq_flags' [-Werror=implicit-function-declaration]
>>>
>>> Did you address this error?  I don't see a fix for it...
>>
>> Yes set_irq_flags() is defined for ARM archs in
>> arch/arm/include/asm/hw_irq.h which is included from
>> include/linux/irq.h as . So the ifdef
>> below takes care of that too.
>>
 +#ifdef CONFIG_ARM
 +  set_irq_flags(irq, IRQF_VALID);
 +#else
 +  irq_set_noprobe(irq);
 +#endif
> 
> OK I've sent the pull request and Olof has now pulled the fix
> into arm-soc next/dt branch.

Thanks.

Acked-by: Randy Dunlap 



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Oct 17 (pinctrl-single.c)

[Tony Lindgren]

* Tony Lindgren  [131018 16:49]:
> * Randy Dunlap  [131018 16:41]:
> > On 10/18/13 16:39, Tony Lindgren wrote:
> > > 
> > > Looks like we need a little bit of arch specific handling
> > > with the generic IRQ. Fix the issue with an ifdef the
> > > same way as other drivers do.
> > > 
> > > ARM needs things set to IRQF_VALID, which also then sets
> > > noprobe. Others seem to use just irq_set_noprobe().
> > > 
> > > Otherwise we can get:
> > > 
> > > drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
> > > drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
> > > function 'set_irq_flags' [-Werror=implicit-function-declaration]
> > 
> > Did you address this error?  I don't see a fix for it...
> 
> Yes set_irq_flags() is defined for ARM archs in
> arch/arm/include/asm/hw_irq.h which is included from
> include/linux/irq.h as . So the ifdef
> below takes care of that too.
> 
> > > +#ifdef CONFIG_ARM
> > > + set_irq_flags(irq, IRQF_VALID);
> > > +#else
> > > + irq_set_noprobe(irq);
> > > +#endif

OK I've sent the pull request and Olof has now pulled the fix
into arm-soc next/dt branch.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] docbook/genericirq.tmpl: various typo corrections

[Randy Dunlap]

From: Randy Dunlap 

Typo corrections for DocBook/genericirq.tmpl.

Signed-off-by: Randy Dunlap 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
---
 Documentation/DocBook/genericirq.tmpl |   64 
 1 file changed, 32 insertions(+), 32 deletions(-)

--- linux-3.12-rc5.orig/Documentation/DocBook/genericirq.tmpl
+++ linux-3.12-rc5/Documentation/DocBook/genericirq.tmpl
@@ -87,7 +87,7 @@
   
 Rationale

-   The original implementation of interrupt handling in Linux is using
+   The original implementation of interrupt handling in Linux uses
the __do_IRQ() super-handler, which is able to deal with every
type of interrupt logic.

@@ -111,19 +111,19 @@



-   This split implementation of highlevel IRQ handlers allows us to
+   This split implementation of high-level IRQ handlers allows us to
optimize the flow of the interrupt handling for each specific
-   interrupt type. This reduces complexity in that particular codepath
+   interrupt type. This reduces complexity in that particular code path
and allows the optimized handling of a given type.


The original general IRQ implementation used hw_interrupt_type
structures and their ->ack(), ->end() [etc.] callbacks to
differentiate the flow control in the super-handler. This leads to
-   a mix of flow logic and lowlevel hardware logic, and it also leads
-   to unnecessary code duplication: for example in i386, there is a
-   ioapic_level_irq and a ioapic_edge_irq irq-type which share many
-   of the lowlevel details but have different flow handling.
+   a mix of flow logic and low-level hardware logic, and it also leads
+   to unnecessary code duplication: for example in i386, there is an
+   ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
+   of the low-level details but have different flow handling.


A more natural abstraction is the clean separation of the
@@ -132,23 +132,23 @@

Analysing a couple of architecture's IRQ subsystem implementations
reveals that most of them can use a generic set of 'irq flow'
-   methods and only need to add the chip level specific code.
+   methods and only need to add the chip-level specific code.
The separation is also valuable for (sub)architectures
-   which need specific quirks in the irq flow itself but not in the
-   chip-details - and thus provides a more transparent IRQ subsystem
+   which need specific quirks in the IRQ flow itself but not in the
+   chip details - and thus provides a more transparent IRQ subsystem
design.


-   Each interrupt descriptor is assigned its own highlevel flow
+   Each interrupt descriptor is assigned its own high-level flow
handler, which is normally one of the generic
-   implementations. (This highlevel flow handler implementation also
+   implementations. (This high-level flow handler implementation also
makes it simple to provide demultiplexing handlers which can be
found in embedded platforms on various architectures.)


The separation makes the generic interrupt handling layer more
flexible and extensible. For example, an (sub)architecture can
-   use a generic irq-flow implementation for 'level type' interrupts
+   use a generic IRQ-flow implementation for 'level type' interrupts
and add a (sub)architecture specific 'edge type' implementation.


@@ -172,9 +172,9 @@
 
There are three main levels of abstraction in the interrupt code:

- Highlevel driver API
- Highlevel IRQ flow handlers
- Chiplevel hardware encapsulation
+ High-level driver API
+ High-level IRQ flow handlers
+ Chip-level hardware encapsulation

 
 
@@ -189,16 +189,16 @@
which are assigned to this interrupt.


-   Whenever an interrupt triggers, the lowlevel arch code calls into
-   the generic interrupt code by calling desc->handle_irq().
-   This highlevel IRQ handling function only uses desc->irq_data.chip
+   Whenever an interrupt triggers, the low-level architecture code calls
+   into the generic interrupt code by calling desc->handle_irq().
+   This high-level IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.

 
 
-   Highlevel Driver API
+   High-level Driver API

- The highlevel Driver API consists of following functions:
+ The high-level Driver API consists of following functions:
  
  request_irq()
  free_irq()
@@ -216,7 +216,7 @@

 
 
-   Highlevel IRQ flow handlers
+   High-level IRQ flow handlers

   

Re: [PATCH] m68k/atari: Call paging_init() before nf_init()

[Michael Schmitz]

Hi Geert,


On Fri, Oct 18, 2013 at 9:29 AM, Michael Schmitz
 wrote:
does your fiddling with memory blocks in bootinfo now result in 
kernels

being possible to boot in FastRAM?


No, I only played with the start address of ST-RAM.

Probably you can run a kernel in FastRAM with some minor tweaks if
you remove the ST-RAM block from the bootinfo, but then you loose
(at least) atafb :-)


That, plus eventual ST-RAM bounce buffers for SCSI (which has been 
broken on my Falcon for a long time).




With the DISCONTIGMEM memory model, the kernel must be stored in the
first memory block. As ST-RAM is before FastRAM in memory, you cannot
have the kernel in FastRAM without losing ST-RAM (as main memory ---
you can still e.g. ioremap() it for atafb, and use the rest of it as
swap through
a block device like z2ram. This is basically what we do on Amiga with 
Chip RAM

and Z2 RAM).


As long as we can ioremap() the ST-RAM frame buffer, we ought to be 
fine in the first instance. How useful ST-RAM as swap may be is 
debatable so I'd leave that aside for now.


Main benefits would be for users of TTs that have been left out with 
recent kernel sizes.


OK - how would I go about ioremaping a chunk of ST-RAM when that has 
been left out of the mm setup because it violates the discontigmem 
layout rules? Set up a kernel private mapping for all of ST-RAM, and 
make that available to the stram allocator?




With the SPARSEMEM memory model, you should be able to store the kernel
in FastRAM and have ST-RAM, too.


I can still remember the headache I got when last playing with the mm 
code, I think I'll pass.



Cheers,

Michael




Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
ge...@linux-m68k.org


In personal conversations with technical people, I call myself a 
hacker. But
when I'm talking to journalists I just say "programmer" or something 
like that.

-- Linus Torvalds


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [bug] get_maintainer.pl incomplete output

[Joe Perches]

On Fri, 2013-10-18 at 15:58 -0700, David Rientjes wrote:
> On Thu, 17 Oct 2013, Joe Perches wrote:
> > Try this:
> > It adds authored/lines_added/lines_deleted to rolestats
> > For instance:
> > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c
> > Tejun Heo  
> > (commit_signer:6/7=86%,authored:3/7=43%,removed_lines:15/21=71%)
> > Michal Hocko  
> > (commit_signer:5/7=71%,authored:3/7=43%,added_lines:22/408=5%,removed_lines:6/21=29%)
> > Andrew Morton  (commit_signer:4/7=57%)
> > Li Zefan  (commit_signer:3/7=43%)
> > "Kirill A. Shutemov"  (commit_signer:1/7=14%)
> > Anton Vorontsov  
> > (authored:1/7=14%,added_lines:374/408=92%)
> > linux...@kvack.org (open list:MEMORY MANAGEMENT)
> > linux-kernel@vger.kernel.org (open list)
> > 
> > I haven't tested it much.
> This looks good, thanks very much!

Oh sure, it's a trifle.

> I'm not sure how useful the 
> removed_lines stat is, but perhaps it can be useful for someone to chime 
> in if someone proposes a patch that includes support that had already been 
> removed.

The whole concept of lines +/- is kind of dubious.
Quantity really doesn't judge value.

It makes some sense for patches where new files
are added, but new files are a relatively a small
percentage of the overall kernel source tree.

Let it stew for awhile in Andrew's tree and when
-next opens up again, let's see if there are any
other comments about it.

My guess is very few people will notice.

The best mechanism is to have MAINTAINERS entries.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tracing: creates 'tracing_is_disabled()'

[Geyslan Gregório Bem]

2013/10/18 Steven Rostedt :
> On Fri, 18 Oct 2013 17:59:41 -0300
> "Geyslan G. Bem"  wrote:
>
>> This patch creates the function 'tracing_is_disabled ", which
>> can be used outside trace.c.
>>
>> Signed-off-by: Geyslan G. Bem 
>> ---
>>  kernel/trace/trace.c | 5 +
>>  kernel/trace/trace.h | 1 +
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index 7974ba2..a120a73 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -2964,6 +2964,11 @@ int tracing_open_generic(struct inode *inode, struct 
>> file *filp)
>>   return 0;
>>  }
>>
>> +inline bool tracing_is_disabled(void)
>
> Nuke the "inline". Gcc and other compilers are smart enough to know to
> inline it on a -O2, that we don't need it. Especially, when it's used
> in another file.
>
> -- Steve

Done. Version 3 sent.

Thanks.
>> +{
>> + return (tracing_disabled) ? true: false;
>> +}
>> +
>>  /*
>>   * Open and update trace_array ref count.
>>   * Must have the current trace_array passed to it.
>> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] wireless: rt2800lib: Fix typo on checking

[Felipe Pena]

On rt2800_config_channel_rf53xx function the member default_power1 is checked
for bound limit, but default_power2 is used instead.

Signed-off-by: Felipe Pena 
---
 drivers/net/wireless/rt2x00/rt2800lib.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c 
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 88ce656..1c2ce93 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2650,7 +2650,7 @@ static void rt2800_config_channel_rf53xx(struct 
rt2x00_dev *rt2x00dev,

if (rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_rfcsr_read(rt2x00dev, 50, );
-   if (info->default_power1 > POWER_BOUND)
+   if (info->default_power2 > POWER_BOUND)
rt2x00_set_field8(, RFCSR50_TX, POWER_BOUND);
else
rt2x00_set_field8(, RFCSR50_TX,
--
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 0/7] 3.0.101-stable review

[Guenter Roeck]

On Fri, Oct 18, 2013 at 12:52:47PM -0700, Greg Kroah-Hartman wrote:
> NOTE:
>   This is the LAST 3.0.x stable kernel release that I will be doing.
>   After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
>   or if you must, 3.4.x series.  For more information about longterm
>   stable releases and how long they will be maintained, please see
>   https://www.kernel.org/category/releases.html
> 
> This is the start of the stable review cycle for the 3.0.101 release.
> There are 7 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> and the diffstat can be found below.
> 
Build results:
total: 98 pass: 71 skipped: 16 fail: 11

qemu tests all passed.

This matches the results seen with 3.0.100.

Details are available at http://server.roeck-us.net:8010/builders.

Thank
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] time: Fix signedness bug in sysfs_get_uname() and its callers

[John Stultz]

On 10/11/2013 10:11 AM, Patrick Palka wrote:
> sysfs_get_uname() is erroneously declared as returning size_t even
> though it may return a negative value, specifically -EINVAL.  Its
> callers then check whether its return value is less than zero and indeed
> that is never the case for size_t.
>
> This patch changes sysfs_get_uname() to return ssize_t and makes sure
> its callers use ssize_t accordingly.

So a similar fix has already been queued in tip/timers/core, but this
seems more complete, so I've resolved the collisions with the earlier
fix and queued it for 3.13.

Would you please take a look at the resulting commit and double check I
didn't flub the conflict resolution?

https://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=commitdiff;h=891292a767c2453af0e5be9465e95b06b4b29ebe;hp=b7bc50e45111e59419474154736f419a555158d9

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/15] clk: tegra: introduce common gen4 super clock

[Andrew Bresticker]

Hi Peter,

> +#define PLL_BASE_LOCK BIT(27)
> +#define PLL_MISC_LOCK_ENABLE 18

I don't see these used anywhere.

> +static const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", 
> "pll_m",
> +"pll_p", "pll_p_out4", "unused",
> +"unused", "pll_x", "pll_x_out0" };

nit: insert blank line here.

> +static void __init tegra_sclk_init(void __iomem *clk_base,
> +   struct tegra_clk *tegra_clks)
> +{

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] tracing: creates 'tracing_is_disabled()'

[Steven Rostedt]

On Fri, 18 Oct 2013 17:59:41 -0300
"Geyslan G. Bem"  wrote:

> This patch creates the function 'tracing_is_disabled ", which
> can be used outside trace.c.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  kernel/trace/trace.c | 5 +
>  kernel/trace/trace.h | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 7974ba2..a120a73 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -2964,6 +2964,11 @@ int tracing_open_generic(struct inode *inode, struct 
> file *filp)
>   return 0;
>  }
>  
> +inline bool tracing_is_disabled(void)

Nuke the "inline". Gcc and other compilers are smart enough to know to
inline it on a -O2, that we don't need it. Especially, when it's used
in another file.

-- Steve

> +{
> + return (tracing_disabled) ? true: false;
> +}
> +
>  /*
>   * Open and update trace_array ref count.
>   * Must have the current trace_array passed to it.
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 0/7] 3.0.101-stable review

[Steven Rostedt]

On Fri, 18 Oct 2013 12:52:47 -0700
Greg Kroah-Hartman  wrote:

> NOTE:
>   This is the LAST 3.0.x stable kernel release that I will be doing.
>   After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
>   or if you must, 3.4.x series.  For more information about longterm
>   stable releases and how long they will be maintained, please see
>   https://www.kernel.org/category/releases.html

Yeah! Yippee! Hooray!

-- 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/

Re: [PATCH v5 12/15] clk: tegra: move PMC, fixed clocks to common files

[Andrew Bresticker]

Hi Peter,

> +   val = readl_relaxed(clk_base + OSC_CTRL);
> +   osc_idx = val >> OSC_CTRL_OSC_FREQ_SHIFT;
> +
> +   if (osc_idx < num)
> +   *osc_freq = input_freqs[osc_idx];

else *osc_freq = 0?

> +   clk = clk_register_fixed_factor(NULL, "pll_ref", "clk_m",
> +   CLK_SET_RATE_PARENT, 1, pll_ref_div);

It seems silly to have CLK_SET_RATE_PARENT on a clock that can't have
its rate changed.

> +   /* clk_32k */
> +   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_32k, tegra_clks);
> +   if (dt_clk) {
> +   clk = clk_register_fixed_rate(NULL, "clk_32k", NULL,
> +   CLK_IS_ROOT, 32768);
> +   clk_register_clkdev(clk, "clk_32k", NULL);

Like with the audio clocks, I think this will be done tegra_register_devclks().

> +   *dt_clk = clk;
> +   }
> +
> +   /* clk_m_div2 */
> +   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_m_div2, tegra_clks);
> +   if (dt_clk) {
> +   clk = clk_register_fixed_factor(NULL, "clk_m_div2", "clk_m",
> +   CLK_SET_RATE_PARENT, 1, 2);
> +   clk_register_clkdev(clk, "clk_m_div2", NULL);

Ditto.

> +   *dt_clk = clk;
> +   }
> +
> +   /* clk_m_div4 */
> +   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_m_div4, tegra_clks);
> +   if (dt_clk) {
> +   clk = clk_register_fixed_factor(NULL, "clk_m_div4", "clk_m",
> +   CLK_SET_RATE_PARENT, 1, 4);
> +   clk_register_clkdev(clk, "clk_m_div4", NULL);

Ditto.

> +   clk = clk_register_gate(NULL, data->gate_name, data->mux_name,
> +   0, pmc_base + PMC_CLK_OUT_CNTRL,
> +   data->gate_shift, 0, _out_lock);
> +   *dt_clk = clk;
> +   clk_register_clkdev(clk, data->dev_name, data->gate_name);

Ditto.

> +   }
> +
> +   /* blink */
> +   clk = clk_register_gate(NULL, "blink_override", "clk_32k", 0,
> +   pmc_base + PMC_DPD_PADS_ORIDE,
> +   PMC_DPD_PADS_ORIDE_BLINK_ENB, 0, NULL);
> +
> +   dt_clk = tegra_lookup_dt_id(tegra_clk_blink, tegra_clks);
> +   if (!dt_clk)
> +   return;
> +

In tegra*_pmc_clk_init, there's a write to PMC_BLINK_TIMER here.
Why'd that disappear?

> +   clk = clk_register_gate(NULL, "blink", "blink_override", 0,
> +   pmc_base + PMC_CTRL,
> +   PMC_CTRL_BLINK_ENB, 0, NULL);
> +   clk_register_clkdev(clk, "blink", NULL);

Same comment about the other register_clkdev calls above.

> +   *dt_clk = clk;
> +}

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v5][PATCH 1/6] powerpc/book3e: load critical/machine/debug exception stack

[Scott Wood]

On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> We always alloc critical/machine/debug check exceptions. This is
> different from the normal exception. So we should load these exception
> stack properly like we did for booke.
> 
> Signed-off-by: Tiejun Chen 
> ---
>  arch/powerpc/kernel/exceptions-64e.S |   49 
> +++---
>  1 file changed, 46 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64e.S 
> b/arch/powerpc/kernel/exceptions-64e.S
> index 4b23119..4d8e57f 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -36,6 +36,37 @@
>   */
>  #define  SPECIAL_EXC_FRAME_SIZE  INT_FRAME_SIZE
>  
> +/* only on book3e */
> +#define DBG_STACK_BASE   dbgirq_ctx
> +#define MC_STACK_BASEmcheckirq_ctx
> +#define CRIT_STACK_BASE  critirq_ctx
> +
> +#ifdef CONFIG_RELOCATABLE
> +#define LOAD_STACK_BASE(reg, level)  \
> + tovirt(r2,r2);  \
> + LOAD_REG_ADDR(reg, level##_STACK_BASE);

Where does r2 come from here, where does it get used, and why do we need
tovirt() on book3e?

-Scott



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Oct 17 (pinctrl-single.c)

[Tony Lindgren]

* Randy Dunlap  [131018 16:41]:
> On 10/18/13 16:39, Tony Lindgren wrote:
> > 
> > Looks like we need a little bit of arch specific handling
> > with the generic IRQ. Fix the issue with an ifdef the
> > same way as other drivers do.
> > 
> > ARM needs things set to IRQF_VALID, which also then sets
> > noprobe. Others seem to use just irq_set_noprobe().
> > 
> > Otherwise we can get:
> > 
> > drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
> > drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
> > function 'set_irq_flags' [-Werror=implicit-function-declaration]
> 
> Did you address this error?  I don't see a fix for it...

Yes set_irq_flags() is defined for ARM archs in
arch/arm/include/asm/hw_irq.h which is included from
include/linux/irq.h as . So the ifdef
below takes care of that too.

> > +#ifdef CONFIG_ARM
> > +   set_irq_flags(irq, IRQF_VALID);
> > +#else
> > +   irq_set_noprobe(irq);
> > +#endif

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Oct 17 (pinctrl-single.c)

[Randy Dunlap]

On 10/18/13 16:39, Tony Lindgren wrote:
> * Linus Walleij  [131018 12:43]:
>> On Fri, Oct 18, 2013 at 8:08 PM, Randy Dunlap  wrote:
>>> On 10/17/13 17:38, Mark Brown wrote:
 Hi all,

 I've uploaded today's linux-next tree to the master branch of the
 repository below:

 git://gitorious.org/thierryreding/linux-next.git

 A next-20131017 tag is also provided for convenience.

 One new conflict today but otherwise uneventful.  x86_64 allmodconfigs
 build after each merge but no other build tests were done.
>>>
>>> on i386:
>>>
>>> drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
>>> drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
>>> function 'set_irq_flags' [-Werror=implicit-function-declaration]
>>> drivers/pinctrl/pinctrl-single.c:1750:21: error: 'IRQF_VALID' undeclared 
>>> (first use in this function)
>>> drivers/pinctrl/pinctrl-single.c:1750:34: error: 'IRQF_PROBE' undeclared 
>>> (first use in this function)
>>
>> H this looks like Tony's baby and the offending patch is
>> not in the pinctrl tree, I bet he'll have a fix for it in no time.
> 
> Ouch sorry about that. I'll send a pull request for the
> following fix ASAP. Build tested with Randy's randconfig.
> 
> Regards,
> 
> Tony
> 
> 8< 
> From: Tony Lindgren 
> Date: Fri, 18 Oct 2013 16:20:05 -0700
> Subject: [PATCH] pinctrl: single: Fix build when not built on ARM
> 
> Looks like we need a little bit of arch specific handling
> with the generic IRQ. Fix the issue with an ifdef the
> same way as other drivers do.
> 
> ARM needs things set to IRQF_VALID, which also then sets
> noprobe. Others seem to use just irq_set_noprobe().
> 
> Otherwise we can get:
> 
> drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
> drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
> function 'set_irq_flags' [-Werror=implicit-function-declaration]

Did you address this error?  I don't see a fix for it...

Thanks.

> drivers/pinctrl/pinctrl-single.c:1750:21: error: 'IRQF_VALID' undeclared 
> (first use in this function)
> drivers/pinctrl/pinctrl-single.c:1750:34: error: 'IRQF_PROBE' undeclared 
> (first use in this function)
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Tony Lindgren 
> 
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -1743,7 +1743,12 @@ static int pcs_irqdomain_map(struct irq_domain *d, 
> unsigned int irq,
>   irq_set_chip_data(irq, pcs_soc);
>   irq_set_chip_and_handler(irq, >chip,
>handle_level_irq);
> - set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
> +
> +#ifdef CONFIG_ARM
> + set_irq_flags(irq, IRQF_VALID);
> +#else
> + irq_set_noprobe(irq);
> +#endif
>  
>   return 0;
>  }
> --


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Oct 17 (pinctrl-single.c)

[Tony Lindgren]

* Linus Walleij  [131018 12:43]:
> On Fri, Oct 18, 2013 at 8:08 PM, Randy Dunlap  wrote:
> > On 10/17/13 17:38, Mark Brown wrote:
> >> Hi all,
> >>
> >> I've uploaded today's linux-next tree to the master branch of the
> >> repository below:
> >>
> >> git://gitorious.org/thierryreding/linux-next.git
> >>
> >> A next-20131017 tag is also provided for convenience.
> >>
> >> One new conflict today but otherwise uneventful.  x86_64 allmodconfigs
> >> build after each merge but no other build tests were done.
> >
> > on i386:
> >
> > drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
> > drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
> > function 'set_irq_flags' [-Werror=implicit-function-declaration]
> > drivers/pinctrl/pinctrl-single.c:1750:21: error: 'IRQF_VALID' undeclared 
> > (first use in this function)
> > drivers/pinctrl/pinctrl-single.c:1750:34: error: 'IRQF_PROBE' undeclared 
> > (first use in this function)
> 
> H this looks like Tony's baby and the offending patch is
> not in the pinctrl tree, I bet he'll have a fix for it in no time.

Ouch sorry about that. I'll send a pull request for the
following fix ASAP. Build tested with Randy's randconfig.

Regards,

Tony

8< 
From: Tony Lindgren 
Date: Fri, 18 Oct 2013 16:20:05 -0700
Subject: [PATCH] pinctrl: single: Fix build when not built on ARM

Looks like we need a little bit of arch specific handling
with the generic IRQ. Fix the issue with an ifdef the
same way as other drivers do.

ARM needs things set to IRQF_VALID, which also then sets
noprobe. Others seem to use just irq_set_noprobe().

Otherwise we can get:

drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map':
drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of 
function 'set_irq_flags' [-Werror=implicit-function-declaration]
drivers/pinctrl/pinctrl-single.c:1750:21: error: 'IRQF_VALID' undeclared (first 
use in this function)
drivers/pinctrl/pinctrl-single.c:1750:34: error: 'IRQF_PROBE' undeclared (first 
use in this function)

Reported-by: Randy Dunlap 
Signed-off-by: Tony Lindgren 

--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1743,7 +1743,12 @@ static int pcs_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
irq_set_chip_data(irq, pcs_soc);
irq_set_chip_and_handler(irq, >chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+
+#ifdef CONFIG_ARM
+   set_irq_flags(irq, IRQF_VALID);
+#else
+   irq_set_noprobe(irq);
+#endif
 
return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v5][PATCH 6/6] book3e/kgdb: Fix a single stgep case of lazy IRQ

[Scott Wood]

On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> When we're in kgdb_singlestep(), we have to work around to get
> thread_info by copying from the kernel stack before calling
> kgdb_handle_exception(), then copying it back afterwards.
> 
> But for PPC64, we have a lazy interrupt implementation. So after
> copying thread info frome kernle stack, if we need to replay an
> interrupt, we shouldn't restore that previous backup thread info
> to make sure we can replay an interrupt lately with a proper
> thread info.

Explain why copying it would be a problem.

> This patch use __check_irq_replay() to guarantee this process.
> 
> Signed-off-by: Tiejun Chen 
> ---
>  arch/powerpc/kernel/irq.c  |   10 ++
>  arch/powerpc/kernel/kgdb.c |3 ++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index ea185e0..3625453 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -339,7 +339,17 @@ bool prep_irq_for_idle(void)
>   return true;
>  }
>  
> +notrace unsigned int check_irq_replay(void)
> +{
> + return __check_irq_replay();
> +}
> +#else
> +notrace unsigned int check_irq_replay(void)
> +{
> + return 0;
> +}
>  #endif /* CONFIG_PPC64 */
> +EXPORT_SYMBOL(check_irq_replay);
>  
>  int arch_show_interrupts(struct seq_file *p, int prec)
>  {
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index cde7818..5b30408 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -152,6 +152,7 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
>  }
>  
>  static DEFINE_PER_CPU(struct thread_info, kgdb_thread_info);
> +extern notrace unsigned int check_irq_replay(void);

Please put prototypes in headers rather than C files.  Also, "extern" is
unnecessary on function prototypes.

>  static int kgdb_singlestep(struct pt_regs *regs)
>  {
>   struct thread_info *thread_info, *exception_thread_info;
> @@ -181,7 +182,7 @@ static int kgdb_singlestep(struct pt_regs *regs)
>  
>   kgdb_handle_exception(0, SIGTRAP, 0, regs);
>  
> - if (thread_info != exception_thread_info)
> + if ((thread_info != exception_thread_info) && (!check_irq_replay()))

Unnecessary parentheses.

Are you sure it's safe to call this here?  Won't __check_irq_replay()
clear the pending event and PACA_IRQ_HARD_DIS?

-Scott



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] timekeeping: Fix some trivial typos in comments

[John Stultz]

On 10/17/2013 06:13 PM, Xie XiuQi wrote:
> Signed-off-by: Xie XiuQi 
> ---
>  kernel/time/timekeeping.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 947ba25..3abf534 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1613,9 +1613,10 @@ void get_xtime_and_monotonic_and_sleep_offset(struct 
> timespec *xtim,
>   * ktime_get_update_offsets - hrtimer helper
>   * @offs_real:   pointer to storage for monotonic -> realtime offset
>   * @offs_boot:   pointer to storage for monotonic -> boottime offset
> + * @offs_tai:pointer to storage for monotonic -> clock tai offset
>   *
>   * Returns current monotonic time and updates the offsets
> - * Called from hrtimer_interupt() or retrigger_next_event()
> + * Called from hrtimer_interrupt() or retrigger_next_event()
>   */
>  ktime_t ktime_get_update_offsets(ktime_t *offs_real, ktime_t *offs_boot,
>   ktime_t *offs_tai)

Even though its trivial, next time please add some sort of commit
message, even if its redundent to the commit subject.

Queued in my 3.13 branch.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist

[John Stultz]

On 10/18/2013 04:12 PM, KOSAKI Motohiro wrote:
> On 10/18/2013 6:39 PM, John Stultz wrote:
>> On 10/17/2013 06:12 PM, KOSAKI Motohiro wrote:
>>> (10/17/13 1:05 PM), John Stultz wrote:
 On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro 
>
> Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora
> Rawhide
> on ARM. (http://bugs.ruby-lang.org/issues/9008)
>
> Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
> RTC device is present) intruduced to return ENOTSUPP when
> clock_get{time,res} can't find a RTC device. However it is incorrect.
>
> Posix and Linux man pages agree that clock_gettime and clock_getres
> should return EINVAL if clk_id argument is invalid. This is significant
> different from timer_create API.
>
> This patch fixes it.
 Hrm... So I feel like there is a difference here. The clockid for
 CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM are both valid.

 Its just that they're not supported on this specific hardware because it
 apparently lacks a RTC that has told the system it can be used as a
 wakeup device (Its actually quite likely on the hardware that the RTC
 can be a wakeup device, but that the driver is probably setting the
 wakeup flag after the RTC registered - so there is probably a driver bug
 here too).

 So I feel like in this case EINVAL isn't quite right.  I'll admit it is
 somewhat new behavior, because we haven't had any clockids before that
 were dependent on the particular hardware, they either existed in a
 kernel verison or didn't.

 Would updating the manpage be a better route?
>>> Nope.
>>>
>>> ENOTSUPP is not exported to userland. ENOTSUP (single P) and EOPNOTSUP is
>>> valid errno (and they are same on linux), but ENOTSUPP is a kernel
>>> internal specific.
>>>
>>> Moreover, I completely disagree your position. Both
>>> CLOCK_REALTIME_ALARM unsupported
>>> kernel and ARM which doesn't support RTC should use the same error
>>> because application
>>> need the same fallback.
>> Ok. You're right. The technicality that the clockid is valid but
>> unsupported isn't really useful to the applications, since the effect is
>> the same.
>>
>> What is the urgency on this? As the issue has been around since 3.0, is
>> it ok if it gets queued for 3.13 and marked for stable, or does it need
>> to land in 3.12?
> 3.13 is OK to me.

Ok. Applied to my 3.13 queue.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/15] clk: tegra: move audio clk to common file

[Andrew Bresticker]

Hi Peter,

> +#define PLL_BASE_LOCK BIT(27)
> +#define PLL_MISC_LOCK_ENABLE 18

It doesn't look like these are used anywhere.

> +static struct tegra_sync_source_initdata sync_source_clks[] __initdata = {
> +   { .name = "spdif_in_sync", .rate = 2400, .max_rate = 2400, 
> .clk_id = tegra_clk_spdif_in_sync},

It's a little weird that we have macros for audio_clks and
audio2x_clks, but not for these.

> +   /* PLLA */
> +   dt_clk = tegra_lookup_dt_id(tegra_clk_pll_a, tegra_clks);
> +   if (dt_clk) {
> +   clk = tegra_clk_register_pll("pll_a", "pll_p_out1", clk_base,
> +   pmc_base, 0, pll_a_params, NULL);
> +   clk_register_clkdev(clk, "pll_a", NULL);

Won't tegra_register_devclks() take care of this since there's an
entry for this in t114's devclks array?

> +   *dt_clk = clk;
> +   }
> +
> +   /* PLLA_OUT0 */
> +   dt_clk = tegra_lookup_dt_id(tegra_clk_pll_a_out0, tegra_clks);
> +   if (dt_clk) {
> +   clk = tegra_clk_register_divider("pll_a_out0_div", "pll_a",
> +   clk_base + PLLA_OUT, 0, 
> TEGRA_DIVIDER_ROUND_UP,
> +   8, 8, 1, NULL);
> +   clk = tegra_clk_register_pll_out("pll_a_out0", 
> "pll_a_out0_div",
> +   clk_base + PLLA_OUT, 1, 0, CLK_IGNORE_UNUSED |
> +   CLK_SET_RATE_PARENT, 0, NULL);
> +   clk_register_clkdev(clk, "pll_a_out0", NULL);

Ditto.

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] drivers: clk: sunxi: Fix memory leakage in clk-sunxi.c

[Victor N. Ramos Mello]

From: "Victor N. Ramos Mello" 

Fix a possible memory leak in sun4i_osc_clk_setup().
Moved clock-frequency check to save superfluous allocation.

Signed-off-by: Victor N. Ramos Mello 
---
 drivers/clk/sunxi/clk-sunxi.c |   28 +---
 1 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 34ee69f..9dcf43e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -38,18 +38,16 @@ static void __init sun4i_osc_clk_setup(struct device_node 
*node)
const char *clk_name = node->name;
u32 rate;
 
+   if (of_property_read_u32(node, "clock-frequency", ))
+   return;
+
/* allocate fixed-rate and gate clock structs */
fixed = kzalloc(sizeof(struct clk_fixed_rate), GFP_KERNEL);
if (!fixed)
return;
gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
-   if (!gate) {
-   kfree(fixed);
-   return;
-   }
-
-   if (of_property_read_u32(node, "clock-frequency", ))
-   return;
+   if (!gate)
+   goto err_free_fixed;
 
/* set up gate and fixed rate properties */
gate->reg = of_iomap(node, 0);
@@ -64,10 +62,18 @@ static void __init sun4i_osc_clk_setup(struct device_node 
*node)
>hw, _gate_ops,
CLK_IS_ROOT);
 
-   if (!IS_ERR(clk)) {
-   of_clk_add_provider(node, of_clk_src_simple_get, clk);
-   clk_register_clkdev(clk, clk_name, NULL);
-   }
+   if (IS_ERR(clk))
+   goto err_free_gate;
+
+   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   clk_register_clkdev(clk, clk_name, NULL);
+
+   return;
+
+err_free_gate:
+   kfree(gate);
+err_free_fixed:
+   kfree(fixed);
 }
 CLK_OF_DECLARE(sun4i_osc, "allwinner,sun4i-osc-clk", sun4i_osc_clk_setup);
 
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's

[Doug Ledford]

On Mon, 2013-10-14 at 22:49 -0700, Joe Perches wrote:
> On Mon, 2013-10-14 at 15:44 -0700, Eric Dumazet wrote:
>> On Mon, 2013-10-14 at 15:37 -0700, Joe Perches wrote:
>> > On Mon, 2013-10-14 at 15:18 -0700, Eric Dumazet wrote:
>> > > attached patch brings much better results
>> > > 
>> > > lpq83:~# ./netperf -H 7.7.8.84 -l 10 -Cc
>> > > MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
>> > > 7.7.8.84 () port 0 AF_INET
>> > > Recv   SendSend  Utilization   Service 
>> > > Demand
>> > > Socket Socket  Message  Elapsed  Send Recv Send
>> > > Recv
>> > > Size   SizeSize Time Throughput  localremote   local   
>> > > remote
>> > > bytes  bytes   bytessecs.10^6bits/s  % S  % S  us/KB   
>> > > us/KB
>> > > 
>> > >  87380  16384  1638410.00  8043.82   2.32 5.34 0.566   
>> > > 1.304  
>> > > 
>> > > diff --git a/arch/x86/lib/csum-partial_64.c 
>> > > b/arch/x86/lib/csum-partial_64.c
>> > []
>> > > @@ -68,7 +68,8 @@ static unsigned do_csum(const unsigned char *buff, 
>> > > unsigned len)
>> > >  zero = 0;
>> > >  count64 = count >> 3;
>> > >  while (count64) { 
>> > > -asm("addq 0*8(%[src]),%[res]\n\t"
>> > > +asm("prefetch 5*64(%[src])\n\t"
>> > 
>> > Might the prefetch size be too big here?
>> 
>> To be effective, you need to prefetch well ahead of time.
> 
> No doubt.
> 
>> 5*64 seems common practice (check arch/x86/lib/copy_page_64.S)
> 
> 5 cachelines for some processors seems like a lot.
> 
> Given you've got a test rig, maybe you could experiment
> with 2 and increase it until it doesn't get better.

You have a fundamental misunderstanding of the prefetch operation.  The 5*64
in the above asm statment does not mean a size, it is an index, with %[src]
as the base pointer.  So it is saying to go to address %[src] + 5*64 and
prefetch there.  The prefetch size itself is always a cache line.  Once the
address is known, whatever cacheline holds that address is the cacheline we
will prefetch.  Your size concerns have no meaning.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Run checksumming in parallel accross multiple alu's

[Doug Ledford]

On 2013-10-17, Ingo wrote:
> * Neil Horman  wrote:
> 
>> On Mon, Oct 14, 2013 at 03:18:47PM -0700, Eric Dumazet wrote:
>> > On Mon, 2013-10-14 at 14:19 -0700, Eric Dumazet wrote:
>> > > On Mon, 2013-10-14 at 16:28 -0400, Neil Horman wrote:
>> > > 
>> > > > So, early testing results today.  I wrote a test module that, 
>> > > > allocated a 4k
>> > > > buffer, initalized it with random data, and called csum_partial on it 
>> > > > 10
>> > > > times, recording the time at the start and end of that loop.  Results 
>> > > > on a 2.4
>> > > > GHz Intel Xeon processor:
>> > > > 
>> > > > Without patch: Average execute time for csum_partial was 808 ns
>> > > > With patch: Average execute time for csum_partial was 438 ns
>> > > 
>> > > Impressive, but could you try again with data out of cache ?
>> > 
>> > So I tried your patch on a GRE tunnel and got following results on a
>> > single TCP flow. (short result : no visible difference)

[ to Eric ]

You didn't show profile data from before and after the patch, only after.  And 
it
showed csum_partial at 19.9% IIRC.  That's a much better than I get on my test
machines (even though this is on a rhel6.5-beta kernel, understand that the 
entire
IB stack in rhel6.5-beta is up to a 3.10 level, with parts closer to 3.11+):

For IPoIB in connected mode, where there is no rx csum offload:

::
rhel6.5-beta-cm-no-offload-oprofile-run1
::
CPU: Intel Architectural Perfmon, speed 3392.17 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask 
of 0x00 (No unit mask) count 10
Samples on CPU 0
Samples on CPU 4
Samples on CPU 6 (edited out as it was only a few samples and ruined
  line wrapping)
samples  %samples  %image name   symbol name
9858859.1431  215  57.9515  vmlinuxcsum_partial_copy_generic
3003  1.8015  8 2.1563  vmlinux  tcp_sendmsg
2219  1.3312  0  0  vmlinuxirq_entries_start
2076  1.2454  4 1.0782  vmlinux avc_has_perm_noaudit
1815  1.0888  0  0  mlx4_ib.ko   mlx4_ib_poll_cq

So, here anyway, it's 60%.  At that level of showing, there is a lot more to be
gained from an improvement to that function.  And here's the measured 
performance
from those runs:

[root@rdma-master rhel6.5-beta-client]# more 
rhel6.5-beta-cm-no-offload-netperf.output 
Recv   SendSend  Utilization
Socket Socket  Message  Elapsed  Send Recv
Size   SizeSize Time Throughput  localremote
bytes  bytes   bytessecs.MBytes  /s  % S  % S
 87380  16384  1638420.00  2815.29   7.92 12.80  
 87380  16384  1638420.00  2798.22   7.88 12.87  
 87380  16384  1638420.00  2786.74   7.79 12.84

The test machine has 8 logical CPUs, so 12.5% is 100% of a single CPU.  That
said, the receive side is obviously the bottleneck here, and 60% of that
bottleneck is csum_partial.

[ snip a bunch of Neil's measurements ]

>> Based on these, prefetching is obviously a a good improvement, but not 
>> as good as parallel execution, and the winner by far is doing both.

OK, this is where I have to chime in that these tests can *not* be used
to say anything about prefetch, and not just for the reasons Ingo lists
in his various emails to this thread.  In fact I would argue that Ingo's
methodology on this is wrong as well.

All prefetch operations get sent to an access queue in the memory controller
where they compete with both other reads and writes for the available memory
bandwidth.  The optimal prefetch window is not a factor of memory bandwidth
and latency, it's a factor of memory bandwidth, memory latency, current memory
access queue depth at time prefetch is issued, and memory bank switch time *
number of queued memory operations that will require a bank switch.  In other
words, it's much more complex and also much more fluid than any static
optimization can pull out.  So every time I see someone run a series of micro-
benchmarks like you just did, where the system was only doing the micro-
benchmark and not a real workload, and we draw conclusions about optimal
prefetch distances from that test, I cringe inside and I think I even die...
just a little.

A better test for this, IMO, would be to start a local kernel compile with at
least twice as many gcc instances allowed as you have CPUs, *then* run your
benchmark kernel module and see what prefetch distance works well.  This
distance should be far enough out that it can withstand other memory pressure,
yet not so far as to constantly be prefetching, tossing the result out of cache
due to pressure, then fetching/stalling that same memory on load.  And it may
not benchmark as well on a quiescent system running only the micro-benchmark,
but it should end up performing better in actual real world usage.

> Also, it would be nice to see standard 

[GIT PULL] Btrfs

[Chris Mason]

Hi Linus,

My for-linus branch has a one line fix:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a
regression in our initial rc1 pull.  When doing nocow writes we were
sometimes starting a transaction with locks held.

Josef Bacik (1) commits (+1/-0):
Btrfs: release path before starting transaction in can_nocow_extent

Total: (1) commits (+1/-0)

 fs/btrfs/inode.c | 1 +
 1 file changed, 1 insertion(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2 v2] tracing: creates 'tracing_is_disabled()'

[Geyslan G. Bem]

This patch creates the function 'tracing_is_disabled', which
can be used outside trace.c.

Signed-off-by: Geyslan G. Bem 
---
 kernel/trace/trace.c | 5 +
 kernel/trace/trace.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..a120a73 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2964,6 +2964,11 @@ int tracing_open_generic(struct inode *inode, struct 
file *filp)
return 0;
 }
 
+inline bool tracing_is_disabled(void)
+{
+   return (tracing_disabled) ? true: false;
+}
+
 /*
  * Open and update trace_array ref count.
  * Must have the current trace_array passed to it.
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 10c86fb..5deaa3b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -514,6 +514,7 @@ void tracing_reset_online_cpus(struct trace_buffer *buf);
 void tracing_reset_current(int cpu);
 void tracing_reset_all_online_cpus(void);
 int tracing_open_generic(struct inode *inode, struct file *filp);
+bool tracing_is_disabled(void);
 struct dentry *trace_create_file(const char *name,
 umode_t mode,
 struct dentry *parent,
-- 
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/

[PATCH] drivers: scsi: lpfc_debugfs: Fix wrong assignment

[Felipe Pena]

On lpfc_debugfs_initialize function the dumpHostSlim member setup happens
when 'phba->sli_rev < LPFC_SLI_REV4' is true, however when it is false NULL
has been assigned to debug_dumpHBASlim instead of debug_dumpHostSlim.

Signed-off-by: Felipe Pena 
---
 drivers/scsi/lpfc/lpfc_debugfs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index 60084e6..b800cc9 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -4001,7 +4001,7 @@ lpfc_debugfs_initialize(struct lpfc_vport *vport)
goto debug_failed;
}
} else
-   phba->debug_dumpHBASlim = NULL;
+   phba->debug_dumpHostSlim = NULL;

/* Setup dumpData */
snprintf(name, sizeof(name), "dumpData");
--
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x

[NeilBrown]

On Fri, 18 Oct 2013 12:12:48 +0200 Javier Martinez Canillas
 wrote:

> On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown  wrote:
> > On Sat,  5 Oct 2013 13:17:09 +0200 Andreas Fenkart  
> > wrote:
> >
> >> The am335x can't detect pending cirq in PM runtime suspend.
> >> This patch reconfigures dat1 as a GPIO before going to suspend.
> >> SDIO interrupts are detected with the GPIO, while in runtime
> >> suspend, standard detection of the module block otherwise.
> >>
> >> Signed-off-by: Andreas Fenkart 
> >>
> >> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
> >> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> index 1136e6b..146f3ad 100644
> >> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> >> @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
> >>  ti,needs-special-reset: Requires a special softreset sequence
> >>  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
> >> High Speed
> >>  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
> >> -SDIO irq while in suspend. Fallback to polling. Affected chips are
> >> -am335x,
> >> +SDIO irq while in suspend. The workaround is to reconfigure the dat1 line 
> >> as a
> >> +GPIO upon suspend. Beyond this option and the GPIO config, you also need 
> >> to set
> >> +named pinctrl states "default", "active" and "idle ", see example below.  
> >> The
> >> +MMC driver will then then toggle between default and idle during the 
> >> runtime
> >> +Affected chips are am335x,
> >>
> >>  --
> >>  | PRCM |
> >> @@ -49,3 +52,24 @@ Example:
> >>   vmmc-supply = <>; /* phandle to regulator node */
> >>   ti,non-removable;
> >>   };
> >> +
> >> +[am335x with with gpio for sdio irq]
> >> +
> >> + mmc1_cirq_pin: pinmux_cirq_pin {
> >> + pinctrl-single,pins = <
> >> + 0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
> >> + >;
> >> + };
> >> +
> >> + mmc1: mmc@4806 {
> >> + ti,non-removable;
> >> + bus-width = <4>;
> >> + vmmc-supply = <_reg>;
> >> + vmmc_aux-supply = <>;
> >> + ti,quirk-swakeup-missing;
> >> + pinctrl-names = "default", "active", "idle";
> >> + pinctrl-0 = <_pins>;
> >> + pinctrl-1 = <_pins>;
> >> + pinctrl-2 = <_cirq_pin>;
> >> + ti,cirq-gpio = < 28 0>;
> >> + };
> >
> >
> > hi,
> >  I've been trying to get SD irq to work on my  OMAP3 DM3730.
> > I seems to need the magic to catch interrupts while FCLK is off, as
> > the only way I can get it to work at the moment is to keep FCLK on.
> >
> > I discovered your patch and tried it out, but it doesn't seem to work for 
> > me.
> >
> > I have a Libertas WIFI chip attached to the second mmc (which is sometimes
> > called mmc1, and sometimes mmc2 - very confusing!).
> 
> Hi Neil,
> 
> I have a DM3730 board with the same setup, Libertas (Marvell SD8686)
> wifi + bt chip attached to mmc2.
> 
> I was going to try to add support for this to the DTS but it would be
> great if I can use your as a reference.
> 
> Would you be so kind to share your DTS?
> 

My DTS is below.  It contains an number of things that are not supported in
mainline yet.  Details can be found in
   git://neil.brown.name/gta04 mainline
and
   http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/mainline
(this is my working tree and gets rebased and messed up regularly).

NeilBrown

/*
 * Copyright (C) 2013 Marek Belisko 
 *
 * Based on omap3-beagle-xm.dts
 *
 * 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.
 */
/dts-v1/;
#define RFKILL_TYPE_GPS 6
#include "omap36xx.dtsi"

/ {
model = "OMAP3 GTA04";
compatible = "ti,omap3-gta04", "ti,omap3";
chosen {
bootargs = "console=ttyO2,115200n8 vram=12M 
omapfb.rotate_type=0 omapdss.def_disp=lcd root=/dev/mmcblk0p2 rw 
rootfstype=ext3 rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 
log_buf_len=8M ignore_loglevel no_console_suspend";
};

cpus {
cpu@0 {
cpu0-supply = <>;
};
};

memory {
device_type = "memory";
reg = <0x8000 0x2000>; /* 512 MB */
};

aux-keys {
compatible = "gpio-keys";

aux-button {
label = "aux";
linux,code = <169>;
gpios = < 7 GPIO_ACTIVE_HIGH>;
gpio-key,wakeup;
};
};

incoming-keys {
compatible = "gpio-keys";

incoming-button {
  

Re: [PATCH] alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist

[KOSAKI Motohiro]

On 10/18/2013 6:39 PM, John Stultz wrote:
> On 10/17/2013 06:12 PM, KOSAKI Motohiro wrote:
>> (10/17/13 1:05 PM), John Stultz wrote:
>>> On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
 From: KOSAKI Motohiro 

 Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora
 Rawhide
 on ARM. (http://bugs.ruby-lang.org/issues/9008)

 Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
 RTC device is present) intruduced to return ENOTSUPP when
 clock_get{time,res} can't find a RTC device. However it is incorrect.

 Posix and Linux man pages agree that clock_gettime and clock_getres
 should return EINVAL if clk_id argument is invalid. This is significant
 different from timer_create API.

 This patch fixes it.
>>>
>>> Hrm... So I feel like there is a difference here. The clockid for
>>> CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM are both valid.
>>>
>>> Its just that they're not supported on this specific hardware because it
>>> apparently lacks a RTC that has told the system it can be used as a
>>> wakeup device (Its actually quite likely on the hardware that the RTC
>>> can be a wakeup device, but that the driver is probably setting the
>>> wakeup flag after the RTC registered - so there is probably a driver bug
>>> here too).
>>>
>>> So I feel like in this case EINVAL isn't quite right.  I'll admit it is
>>> somewhat new behavior, because we haven't had any clockids before that
>>> were dependent on the particular hardware, they either existed in a
>>> kernel verison or didn't.
>>>
>>> Would updating the manpage be a better route?
>>
>> Nope.
>>
>> ENOTSUPP is not exported to userland. ENOTSUP (single P) and EOPNOTSUP is
>> valid errno (and they are same on linux), but ENOTSUPP is a kernel
>> internal specific.
>>
>> Moreover, I completely disagree your position. Both
>> CLOCK_REALTIME_ALARM unsupported
>> kernel and ARM which doesn't support RTC should use the same error
>> because application
>> need the same fallback.
> 
> Ok. You're right. The technicality that the clockid is valid but
> unsupported isn't really useful to the applications, since the effect is
> the same.
> 
> What is the urgency on this? As the issue has been around since 3.0, is
> it ok if it gets queued for 3.13 and marked for stable, or does it need
> to land in 3.12?

3.13 is OK to me.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > A handful of boot panics on ARM platforms were bisected to point at
> > the version of this commit that's in linux-next (commit
> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> > makes things happy again.
> >
> > Upon further digging, it seems that users of devres_alloc() are
> > relying on the previous behavior of having the memory zero'd which is
> > no longer the case after $SUBJECT patch.  The change below on top of
> > -next makes these ARM boards happy again.
> 
> Oops, it should've fixed __devres_alloc() also.  Updated patch below.

Can you send this in a format that I can apply it in?  It was whitespace
damaged.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v5][PATCH 4/6] powerpc/book3e: support kgdb for kernel space

[Scott Wood]

On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> Currently we need to skip this for supporting KGDB.

Does it need to depend on CONFIG_KGDB?  Either you've fixed the "can't
quite save properly" part, or you haven't.

-Scott

> 
> Signed-off-by: Tiejun Chen 
> ---
>  arch/powerpc/kernel/exceptions-64e.S |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64e.S 
> b/arch/powerpc/kernel/exceptions-64e.S
> index 07cf657..a286b51 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -639,11 +639,13 @@ kernel_dbg_exc:
>   rfdi
>  
>   /* Normal debug exception */
> +1:   andi.   r14,r11,MSR_PR; /* check for userspace again */
> +#ifndef CONFIG_KGDB
>   /* XXX We only handle coming from userspace for now since we can't
>* quite save properly an interrupted kernel state yet
>*/
> -1:   andi.   r14,r11,MSR_PR; /* check for userspace again */
>   beq kernel_dbg_exc; /* if from kernel mode */
> +#endif
>  
>   /* Now we mash up things to make it look like we are coming on a
>* normal exception



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [bug] get_maintainer.pl incomplete output

[David Rientjes]

On Thu, 17 Oct 2013, Joe Perches wrote:

> Try this:
> 
> It adds authored/lines_added/lines_deleted to rolestats
> 
> For instance:
> 
> $ ./scripts/get_maintainer.pl -f mm/vmpressure.c
> Tejun Heo  
> (commit_signer:6/7=86%,authored:3/7=43%,removed_lines:15/21=71%)
> Michal Hocko  
> (commit_signer:5/7=71%,authored:3/7=43%,added_lines:22/408=5%,removed_lines:6/21=29%)
> Andrew Morton  (commit_signer:4/7=57%)
> Li Zefan  (commit_signer:3/7=43%)
> "Kirill A. Shutemov"  (commit_signer:1/7=14%)
> Anton Vorontsov  
> (authored:1/7=14%,added_lines:374/408=92%)
> linux...@kvack.org (open list:MEMORY MANAGEMENT)
> linux-kernel@vger.kernel.org (open list)
> 
> I haven't tested it much.
> 

This looks good, thanks very much!  I'm not sure how useful the 
removed_lines stat is, but perhaps it can be useful for someone to chime 
in if someone proposes a patch that includes support that had already been 
removed.

Once it's signed off, feel free to add

Acked-by: David Rientjes 

Thanks again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v5][PATCH 3/6] book3e/kgdb: update thread's dbcr0

[Scott Wood]

On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> gdb always need to generate a single step properly to invoke
> a kgdb state. But with lazy interrupt, book3e can't always
> trigger a debug exception with a single step since the current
> is blocked for handling those pending exception, then we miss
> that expected dbcr configuration at last to generate a debug
> exception.

What do you mean by "the current is blocked"?  Could you explain more
clearly what lazy EE has to do with MSR_DE and DBCR0?

> So here we also update thread's dbcr0 to make sure the current
> can go back with that missed dbcr0 configuration.
> 
> Signed-off-by: Tiejun Chen 
> ---
>  arch/powerpc/kernel/kgdb.c |   13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index c1eef24..55409ac 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -410,7 +410,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int 
> err_code,
>  struct pt_regs *linux_regs)
>  {
>   char *ptr = _in_buffer[1];
> - unsigned long addr;
> + unsigned long addr, dbcr0;
>  
>   switch (remcom_in_buffer[0]) {
>   /*
> @@ -427,8 +427,15 @@ int kgdb_arch_handle_exception(int vector, int signo, 
> int err_code,
>   /* set the trace bit if we're stepping */
>   if (remcom_in_buffer[0] == 's') {
>  #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> - mtspr(SPRN_DBCR0,
> -   mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
> + dbcr0 = mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM;
> + mtspr(SPRN_DBCR0, dbcr0);
> +#ifdef CONFIG_PPC_BOOK3E_64

This could as well be "CONFIG_PPC64" -- CONFIG_PPC_ADV_DEBUG_REGS
implies booke or 40x.  Lazy EE is a CONFIG_PPC64 thing, not specifically
CONFIG_PPC_BOOK3E_64.

> + /* With lazy interrut we have to update thread dbcr0 
> here

s/interrut/interrupts/

> +  * to make sure we can set debug properly at last to 
> invoke
> +  * kgdb again to work well.
> +  */
> + current->thread.dbcr0 = dbcr0;
> +#endif
>   linux_regs->msr |= MSR_DE;
>  #else
>   linux_regs->msr |= MSR_SE;

Hmm, what happens here if we enable KGDB on booke without
CONFIG_PPC_ADV_DEBUG_REGS?  Kconfig doesn't appear to prevent it.

-Scott



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: Do not drop unheld reference on device node

[Thierry Reding]

When booting a recent kernel on ARM with OF_DYNAMIC enabled, the kernel
warns about the following:

[0.00] ERROR: Bad of_node_put() on /timer@50004600
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
3.12.0-rc5-next-20131017-00077-gedfd827-dirty #406
[0.00] [] (unwind_backtrace+0x0/0xf4) from 
[] (show_stack+0x10/0x14)
[0.00] [] (show_stack+0x10/0x14) from [] 
(dump_stack+0x9c/0xc8)
[0.00] [] (dump_stack+0x9c/0xc8) from [] 
(of_node_release+0x90/0x9c)
[0.00] [] (of_node_release+0x90/0x9c) from 
[] (of_find_matching_node_and_match+0x78/0xb4)
[0.00] [] (of_find_matching_node_and_match+0x78/0xb4) 
from [] (clocksource_of_init+0x60/0x70)
[0.00] [] (clocksource_of_init+0x60/0x70) from 
[] (start_kernel+0x1f4/0x33c)
[0.00] [] (start_kernel+0x1f4/0x33c) from 
[<80008074>] (0x80008074)

This is caused by clocksource_of_init() dropping a reference on the
device node that it never took. The reference taken by the loop is
implicitly dropped on subsequent iterations. See the implementation of
and the comment on top of the of_find_matching_node_and_match()
function for reference (no pun intended).

Signed-off-by: Thierry Reding 
---
 drivers/clocksource/clksrc-of.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clocksource/clksrc-of.c b/drivers/clocksource/clksrc-of.c
index 35639cf4..b9ddd9e 100644
--- a/drivers/clocksource/clksrc-of.c
+++ b/drivers/clocksource/clksrc-of.c
@@ -35,6 +35,5 @@ void __init clocksource_of_init(void)
 
init_func = match->data;
init_func(np);
-   of_node_put(np);
}
 }
-- 
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 RESEND 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Rich Johnston]

Sorry if there are others please let me know.

On 10/18/2013 05:44 PM, Dave Chinner wrote:

On Fri, Oct 18, 2013 at 12:24:22PM -0500, Rich Johnston wrote:

This has been committed.

Thanks
--Rich

commit e64190f8440286a815060524777b435e06a7b364
Author: Namjae Jeon 
Date:   Sun Oct 6 20:13:38 2013 +

 [RESEND, 4/7] xfsprogs: xfsio: add support
FALLOC_FL_COLLAPSE_RANGE for fallocate


Hi Rich,

This isn't ready for being committed into xfsprogs. The kernel code
is still under review, and until we actually have it in a tree to be
merged int eh kernel, we shoul d't be making any userspace changes
at all. Indeed, there's a chance (unlikely, but still there) that
this code may still not end up in the kernel at all...

So, it's probably best right now to revert this patch until we have
the fallocate API support merged into the kernel...

Cheers,

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: [PATCH 1/1] drivers: net: wireless: rtlwifi: Fix wrong assignment

[Felipe Pena]

On Fri, Oct 18, 2013 at 7:27 PM, Larry Finger  wrote:
> On 10/18/2013 05:15 PM, Felipe Pena wrote:
>>
>> There is a typo in the struct member name on assignment when checking
>> rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses
>> pwrgroup_ht40
>> for bound limit and uses pwrgroup_ht20 when assigning instead.
>>
>> Signed-off-by: Felipe Pena 
>> ---
>>   drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> index 5061f1d..92d38ab 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
>> @@ -265,7 +265,7 @@ static void
>> _rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
>> rtlefuse->pwrgroup_ht40
>> [RF90_PATH_A][chnl - 1]) {
>> pwrdiff_limit[i] =
>> - rtlefuse->pwrgroup_ht20
>> + rtlefuse->pwrgroup_ht40
>>   [RF90_PATH_A][chnl - 1];
>> }
>> } else {
>
>
> Good catch. There is only one problem - by convention we skip
> drivers/net/wireless in the subject. That would probably be OK, but you are
> missing the rtl8192se part, which needs to be there. I suggest that you use
> the subject "rtlwifi: rtl8192de: Fix wrong assignment".
>
> Larry
>
>

Thanks for the reply. I'll re-send it with the suggested subject.

-- 
Regards,
Felipe Pena
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Dave Chinner]

On Fri, Oct 18, 2013 at 12:24:22PM -0500, Rich Johnston wrote:
> This has been committed.
> 
> Thanks
> --Rich
> 
> commit e64190f8440286a815060524777b435e06a7b364
> Author: Namjae Jeon 
> Date:   Sun Oct 6 20:13:38 2013 +
> 
> [RESEND, 4/7] xfsprogs: xfsio: add support
> FALLOC_FL_COLLAPSE_RANGE for fallocate

Hi Rich,

This isn't ready for being committed into xfsprogs. The kernel code
is still under review, and until we actually have it in a tree to be
merged int eh kernel, we shoul d't be making any userspace changes
at all. Indeed, there's a chance (unlikely, but still there) that
this code may still not end up in the kernel at all...

So, it's probably best right now to revert this patch until we have
the fallocate API support merged into the kernel...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v5][PATCH 2/6] powerpc/book3e: store critical/machine/debug exception thread info

[Scott Wood]

On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> We need to store thread info to these exception thread info like something
> we already did for PPC32.
> 
> Signed-off-by: Tiejun Chen 
> ---
>  arch/powerpc/kernel/exceptions-64e.S |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64e.S 
> b/arch/powerpc/kernel/exceptions-64e.S
> index 4d8e57f..07cf657 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -67,6 +67,18 @@
>   std r10,PACA_##level##_STACK(r13);
>  #endif
>  
> +/* Store something to exception thread info */
> +#define  BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(type) 
> \
> + ld  r14,PACAKSAVE(r13); 
> \
> + CURRENT_THREAD_INFO(r14, r14);  
> \
> + CURRENT_THREAD_INFO(r15, r1);   
> \
> + ld  r10,TI_FLAGS(r14);  
> \
> + std r10,TI_FLAGS(r15);  
> \
> + ld  r10,TI_PREEMPT(r14);
> \
> + std r10,TI_PREEMPT(r15);
> \
> + ld  r10,TI_TASK(r14);   
> \
> + std r10,TI_TASK(r15);

Where is "type" used?

BTW, no need for a BOOK3E prefix for things local to this file.

-Scott



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thinkpad-acpi: Fix wrong assignment

[Felipe Pena]

In the thermal_init function when checking for thinkpad_id.ec_model,
the 'ta2' variable is being OR'd when acpi_ec_read call succeeds,
on fail it is setting 0 to 'ta1' variable instead.

Signed-off-by: Felipe Pena 
---
 drivers/platform/x86/thinkpad_acpi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 03ca6c1..ac6f938 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5730,7 +5730,7 @@ static int __init thermal_init(struct ibm_init_struct 
*iibm)
if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, )) {
ta2 |= t;
} else {
-   ta1 = 0;
+   ta2 = 0;
break;
}
}
--
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist

[John Stultz]

On 10/17/2013 06:12 PM, KOSAKI Motohiro wrote:
> (10/17/13 1:05 PM), John Stultz wrote:
>> On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
>>> From: KOSAKI Motohiro 
>>>
>>> Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora
>>> Rawhide
>>> on ARM. (http://bugs.ruby-lang.org/issues/9008)
>>>
>>> Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
>>> RTC device is present) intruduced to return ENOTSUPP when
>>> clock_get{time,res} can't find a RTC device. However it is incorrect.
>>>
>>> Posix and Linux man pages agree that clock_gettime and clock_getres
>>> should return EINVAL if clk_id argument is invalid. This is significant
>>> different from timer_create API.
>>>
>>> This patch fixes it.
>>
>> Hrm... So I feel like there is a difference here. The clockid for
>> CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM are both valid.
>>
>> Its just that they're not supported on this specific hardware because it
>> apparently lacks a RTC that has told the system it can be used as a
>> wakeup device (Its actually quite likely on the hardware that the RTC
>> can be a wakeup device, but that the driver is probably setting the
>> wakeup flag after the RTC registered - so there is probably a driver bug
>> here too).
>>
>> So I feel like in this case EINVAL isn't quite right.  I'll admit it is
>> somewhat new behavior, because we haven't had any clockids before that
>> were dependent on the particular hardware, they either existed in a
>> kernel verison or didn't.
>>
>> Would updating the manpage be a better route?
>
> Nope.
>
> ENOTSUPP is not exported to userland. ENOTSUP (single P) and EOPNOTSUP is
> valid errno (and they are same on linux), but ENOTSUPP is a kernel
> internal specific.
>
> Moreover, I completely disagree your position. Both
> CLOCK_REALTIME_ALARM unsupported
> kernel and ARM which doesn't support RTC should use the same error
> because application
> need the same fallback.

Ok. You're right. The technicality that the clockid is valid but
unsupported isn't really useful to the applications, since the effect is
the same.

What is the urgency on this? As the issue has been around since 3.0, is
it ok if it gets queued for 3.13 and marked for stable, or does it need
to land in 3.12?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v5][PATCH 1/6] powerpc/book3e: load critical/machine/debug exception stack

[Scott Wood]

On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
> We always alloc critical/machine/debug check exceptions. This is
> different from the normal exception. So we should load these exception
> stack properly like we did for booke.

This is "booke".  Do you mean like "like we did for 32-bit"?

And the code is already trying to load the special stack; it just
happens that it's loading from a different location than the C code
placed the stack addresses.  The changelog should point out the specific
thing that is being fixed.

> Signed-off-by: Tiejun Chen 
> ---
>  arch/powerpc/kernel/exceptions-64e.S |   49 
> +++---
>  1 file changed, 46 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64e.S 
> b/arch/powerpc/kernel/exceptions-64e.S
> index 4b23119..4d8e57f 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -36,6 +36,37 @@
>   */
>  #define  SPECIAL_EXC_FRAME_SIZE  INT_FRAME_SIZE
>  
> +/* only on book3e */
> +#define DBG_STACK_BASE   dbgirq_ctx
> +#define MC_STACK_BASEmcheckirq_ctx
> +#define CRIT_STACK_BASE  critirq_ctx
> +
> +#ifdef CONFIG_RELOCATABLE
> +#define LOAD_STACK_BASE(reg, level)  \
> + tovirt(r2,r2);  \
> + LOAD_REG_ADDR(reg, level##_STACK_BASE);
> +#else
> +#define LOAD_STACK_BASE(reg, level)  \
> + LOAD_REG_IMMEDIATE(reg, level##_STACK_BASE);
> +#endif
> +
> +#ifdef CONFIG_SMP
> +#define BOOK3E_LOAD_EXC_LEVEL_STACK(level)   \
> + mfspr   r14,SPRN_PIR;   \
> + slwir14,r14,3;  \
> + LOAD_STACK_BASE(r10, level);\
> + add r10,r10,r14;\
> + ld  r10,0(r10); \
> + addir10,r10,THREAD_SIZE;\
> + std r10,PACA_##level##_STACK(r13);
> +#else
> +#define BOOK3E_LOAD_EXC_LEVEL_STACK(level)   \
> + LOAD_STACK_BASE(r10, level);\
> + ld  r10,0(r10); \
> + addir10,r10,THREAD_SIZE;\
> + std r10,PACA_##level##_STACK(r13);
> +#endif

It looks like you're loading the stack from *irq_ctx, storing it in
PACA_*_stack, and then (immediately after this in the caller) loading it
back from PACA_*_STACK.  Why not just load it from *irq_ctx and get rid
of PACA_*_STACK altogether -- or change the C code to initialize the
addresses in the PACA instead, and get ird of *irq_ctx on 64-bit?

>  /* Exception prolog code for all exceptions */
>  #define EXCEPTION_PROLOG(n, intnum, type, addition)  \
>   mtspr   SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */   \
> @@ -68,20 +99,32 @@
>  #define SPRN_GDBELL_SRR1 SPRN_GSRR1
>  
>  #define CRIT_SET_KSTACK  
> \
> + andi.   r10,r11,MSR_PR; 
> \
> + bne 1f; 
> \
> + BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT);  
> \
>   ld  r1,PACA_CRIT_STACK(r13);\
> - subir1,r1,SPECIAL_EXC_FRAME_SIZE;
> + subir1,r1,SPECIAL_EXC_FRAME_SIZE;   
> \

The caller will already check MSR_PR and override this if coming from
userspace; why do you need to check again here?

-Scott



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next v2] ns: do not allocate a new nsproxy at each call

[Eric W. Biederman]

"Guillaume Gaudonville"  writes:

> Currently, at each call of setns system call a new nsproxy is allocated,
> the old nsproxy namespaces are copied into the new one and the old nsproxy
> is freed if the task was the only one to use it.

In principle this looks ok.  However you are not using rcu properly.

What you are doing is just far enough outside of normal rcu usage my
brain refuses to think it through today.

Paul can you give us a hand?

Specific code comments below.

It looks like what we really want for the pointer variables in nsproxy
is an atomic pointer type.  We have something like that with
ACCESS_ONCE.Without a prebuilt idiom I am not thinking through this
issue clearly right now.

Maybe you are right that we need to push the rcu protection down a
level.  So we can have free reads and inexpensive writes.

> It can creates large delays on hardware with large number of cpus since
> to free a nsproxy a synchronize_rcu() call is done.
>
> When a task is the only one to use a nsproxy, only the task can do an action
> that will make this nsproxy to be shared by another task or thread (fork,...).
> So when the refcount of the nsproxy is equal to 1, we can simply update the
> current nsproxy field without allocating a new one and freeing the old one.
>
> The install operations of each kind of namespace cannot fails, so there's no
> need to check for an error and calling ops->install().
>
> However since we can have readers of the nsproxy that are not the current 
> task,
> we need to protect access to each namespace pointer in the nsproxy. This is
> done by assigning it using rcu_assign_pointer() and when it is possible
> that the reader is not the current task, read the pointer using
> rcu_dereference().
>
> Finally the install function of each namespace type must be modified to ensure
> that the refcount of the old namespace is released after the assignment in
> nsproxy.
>
> On kernel 3.12-rc1, using a small application that does:
>
> - call setns on a first net namespace and open a socket,
> - call setns on a second net namespace and open a socket,
> - switch back to the first namespace and close the socket,
> - switch back to the second namespace and close the socket,

Note.  You don't need to switch namespaces for any operation except
opening the socket.  Sockets are always fixed in a single network
namespace.

Part of me wonders if this is the time to introduce the socketat system
call I threatend people with a while ago that takes a netns file
descriptor and gives you a socket in the specified namespace.

> On an Intel Westmere with 24 logical cores at 3.33 GHz, it gives the
> following results using the time command:
>
> - without the proposed patch:
>
>   root@blackcloudy:~# time ./test_x86
>
>   real0m0.130s
>   user0m0.000s
>   sys 0m0.000s
>
> - with the proposed patch:
>
>   root@blackcloudy:~# time ./test_x86
>
>   real0m0.020s
>   user0m0.000s
>   sys 0m0.000s
>
> Reported-by: Chris Metcalf 
> Signed-off-by: Guillaume Gaudonville 
> ---
>
> v2:
>   - protect readers, by releasing namespaces refcount after updating the
> nsproxy pointer,
>   - protect readers, by using rcu_assign_pointer() to affect nsproxy
> pointers,
>   - readers need to use rcu_dereference() to access the namespace and
> must take a reference on it before leaving the rcu_read_lock section
> (this last part was already present),
>   - do not add additional exit point in setns syscall.
>
> There are still 2 suspicious functions, nfs_server_list_open() and
> nfs_volume_list_open(). They are accessing directly to the net_ns
> like below:
>
> struct net *net = pid_ns->child_reaper->nsproxy->net_ns;
>
> It seems to me that currently they should access it under rcu_read_lock()
> and using task_nsproxy(pid_ns->child_reaper). It looks like a bug, no?
>
> And then with this proposed patch they should access the netns through
> a rcu_dereference and take a reference on the netns. I didn't
> modify them for now, but if it is confirmed I can send a patch
> fixing the first issue and then send a v3 of this proposed patch.
>
>  fs/namespace.c   |9 +
>  fs/proc/proc_net.c   |2 +-
>  fs/proc_namespace.c  |2 +-
>  ipc/namespace.c  |9 +
>  kernel/nsproxy.c |   11 +++
>  kernel/pid_namespace.c   |7 ---
>  kernel/utsname.c |9 +
>  net/core/net_namespace.c |   11 ++-
>  8 files changed, 38 insertions(+), 22 deletions(-)
>

[snip]

> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> index afc0456..4ad9f9f 100644
> --- a/kernel/nsproxy.c
> +++ b/kernel/nsproxy.c
> @@ -255,6 +255,17 @@ SYSCALL_DEFINE2(setns, int, fd, int, nstype)
>   if (nstype && (ops->type != nstype))
>   goto out;
>  
> + /*
> +  * If count == 1, only the current task can increment it,
> +  * by doing a fork for example so we can safely update the
> +  * current nsproxy pointers without 

RE: [PATCH v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed

[Seiji Aguchi]

Matt,

> It seems to me that because you're no longer dropping __efivars->lock
> when reading from the EFI variable store, you actually don't need all
> the ->scanning and ->deleting logic because anything that sets those
> flags runs to completion while holding the lock.

The scanning and deleting logic is still needed.
In case an entry(A) is found, the pointer is saved to psi->data.
And efi_pstore_read() passes the entry(A) to a pstore filesystem by releasing  
__efivars->lock.

And then, the pstore filesystem calls efi_pstore_read() again and the same 
entry(A), which is saved to
psi->data, is used for re-scanning a sysfs-list.
(That is why list_for_each_entry_safe_from () is used in 
efi_pstore_sysfs_entry_iter().)

So, to protect the entry(A), the logic is needed because, in pstore filesystem, 
 __efivars->lock
Is released. 

> Can't the patch be simplified to just allocating data.buf at the
> beginning of efi_pstore_read()? 

I think data.buf is simply allocated at the beginning of efi_pstore_read() with 
this patch v3.
If you are not satisfied with it, could you please show me your pseudo code?

>Also, it would be a good idea to
> introduce a #define for the 1024 magic number, e.g.
> 
> #define EFIVARS_DATA_SIZE_MAX 1024

It is good idea. I can fix it.

Seiji


+/**
+ * efi_pstore_read
+ *
+ * This function returns a size of NVRAM entry logged via efi_pstore_write().
+ * The meaning and behavior of efi_pstore/pstore are as below.
+ *
+ * size > 0: Got data of an entry logged via efi_pstore_write() successfully,
+ *   and pstore filesystem will continue reading subsequent entries.
+ * size == 0: Entry was not logged via efi_pstore_write(),
+ *and efi_pstore driver will continue reading subsequent entries.
+ * size < 0: Failed to get data of entry logging via efi_pstore_write(),
+ *   and pstore will stop reading entry.
+ */
 static ssize_t efi_pstore_read(u64 *id, enum pstore_type_id *type,
   int *count, struct timespec *timespec,
   char **buf, bool *compressed,
   struct pstore_info *psi)
 {
struct pstore_read_data data;
+   ssize_t size;
 
data.id = id;
data.type = type;
@@ -112,8 +216,17 @@ static ssize_t efi_pstore_read(u64 *id, enum 
pstore_type_id *type,
data.compressed = compressed;
data.buf = buf;
 
-   return __efivar_entry_iter(efi_pstore_read_func, _sysfs_list, 
,
-  (struct efivar_entry **)>data);
+   *data.buf = kzalloc(1024, GFP_KERNEL);
+   if (!*data.buf)
+   return -ENOMEM;
+
+   efivar_entry_iter_begin();
+   size = efi_pstore_sysfs_entry_iter(,
+  (struct efivar_entry **)>data);
+   efivar_entry_iter_end();
+   if (size <= 0)
+   kfree(*data.buf);
+   return size;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] drivers: net: wireless: rtlwifi: Fix wrong assignment

[Larry Finger]

On 10/18/2013 05:15 PM, Felipe Pena wrote:

There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.

Signed-off-by: Felipe Pena 
---
  drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void 
_rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
  [RF90_PATH_A][chnl - 1];
}
} else {


Good catch. There is only one problem - by convention we skip 
drivers/net/wireless in the subject. That would probably be OK, but you are 
missing the rtl8192se part, which needs to be there. I suggest that you use the 
subject "rtlwifi: rtl8192de: Fix wrong assignment".


Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 4/9] ACPI, x86: Extended error log driver for x86 platform

[Luck, Tony]

@@ -154,6 +154,10 @@ void mce_log(struct mce *mce)
/* Emit the trace record: */
trace_mce_record(mce);
 
+   if (mce_ext_err_print)
+   if (mce_ext_err_print(NULL, m.extcpu, i))
+   return;
+
ret = atomic_notifier_call_chain(_mce_decoder_chain, 0, mce);
if (ret == NOTIFY_STOP)
return;

If we move mce_ext_err_print() this far ... then it's only one line further down
to have it be part of the x86_mce_decoder_chain as suggested by Naveen.

-Tony

[PATCH 1/1] drivers: net: wireless: rtlwifi: Fix wrong assignment

[Felipe Pena]

There is a typo in the struct member name on assignment when checking
rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_20_40, the check uses pwrgroup_ht40
for bound limit and uses pwrgroup_ht20 when assigning instead.

Signed-off-by: Felipe Pena 
---
 drivers/net/wireless/rtlwifi/rtl8192se/rf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
index 5061f1d..92d38ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/rf.c
@@ -265,7 +265,7 @@ static void 
_rtl92s_get_txpower_writeval_byregulatory(struct ieee80211_hw *hw,
rtlefuse->pwrgroup_ht40
[RF90_PATH_A][chnl - 1]) {
pwrdiff_limit[i] =
- rtlefuse->pwrgroup_ht20
+ rtlefuse->pwrgroup_ht40
  [RF90_PATH_A][chnl - 1];
}
} else {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/3] mmc: core: Support the optional init_card() callback for MMC and SD

[Doug Anderson]

In (3fcb027 ARM: MXC: mxcmmc: work around a bug in the SDHC busy line
handling) the optional init_card() callback was added.  According to
the original change it was "for now only called from
mmc_sdio_init_card()".

This callback really ought to be called from the SD and MMC init
functions as well.  One current user of this callback
(mxcmci_init_card) will not work as expected if you insert an SDIO
card, then eject it and put a normal SD card in.  Specifically the
normal SD card will not get to run with 4-bit data.

I'd like to use the init_card() callback to handle a similar quirk on
dw_mmc when using SDIO Interrupts (the "low power" feature of the card
needs to be disabled), so that will add a second user of the function.

As part of this change fixup the one place that relied on the callback
only happening for SDIO cards.

Signed-off-by: Doug Anderson 
Reviewed-by: Grant Grundler 
---
Changes in v3:
- Add fixup to pandora_wl1251_init_card().

Changes in v2:
- New for this version.

 arch/arm/mach-omap2/board-omap3pandora.c | 14 --
 drivers/mmc/core/mmc.c   |  6 ++
 drivers/mmc/core/sd.c|  7 ++-
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index de1bc6b..6404595 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -254,12 +254,14 @@ static void pandora_wl1251_init_card(struct mmc_card 
*card)
 * We have TI wl1251 attached to MMC3. Pass this information to
 * SDIO core because it can't be probed by normal methods.
 */
-   card->quirks |= MMC_QUIRK_NONSTD_SDIO;
-   card->cccr.wide_bus = 1;
-   card->cis.vendor = 0x104c;
-   card->cis.device = 0x9066;
-   card->cis.blksize = 512;
-   card->cis.max_dtr = 2000;
+   if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
+   card->quirks |= MMC_QUIRK_NONSTD_SDIO;
+   card->cccr.wide_bus = 1;
+   card->cis.vendor = 0x104c;
+   card->cis.device = 0x9066;
+   card->cis.blksize = 512;
+   card->cis.max_dtr = 2000;
+   }
 }
 
 static struct omap2_hsmmc_info omap3pandora_mmc[] = {
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 6d02012..7ad75c0 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -940,6 +940,12 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
 
/*
+* Call the optional HC's init_card function to handle quirks.
+*/
+   if (host->ops->init_card)
+   host->ops->init_card(host, card);
+
+   /*
 * For native busses:  set card RCA and quit open drain mode.
 */
if (!mmc_host_is_spi(host)) {
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 5e8823d..59e2318 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -940,6 +940,12 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
}
 
/*
+* Call the optional HC's init_card function to handle quirks.
+*/
+   if (host->ops->init_card)
+   host->ops->init_card(host, card);
+
+   /*
 * For native busses:  get card RCA and quit open drain mode.
 */
if (!mmc_host_is_spi(host)) {
@@ -1286,4 +1292,3 @@ err:
 
return err;
 }
-
-- 
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 11/12] mm, thp, tmpfs: enable thp page cache in tmpfs

[Ning Qu]

Hi, Kirill,

I have reviewed the current migration code and seems huge page will
get splitted during migration. Since our current split_huge_page
handle file cache as well, it seems not a problem for us?

We just simply not removing the __GFP_MOVABLE flag? Anything else I am
missing here?

Thanks!
Best wishes,
-- 
Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066


On Fri, Oct 18, 2013 at 11:24 AM, Ning Qu  wrote:
> I guess this is the last review I have for this around, but not sure
> what's the best solution right now.
>
> Kirill, do you think it's OK to just split the huge page when it will
> be moved. Will look into how thp anon handle this situation.
>
> Then after this, I probably will post v2.
>
> Thanks!
> Best wishes,
> --
> Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066
>
>
> On Tue, Oct 15, 2013 at 11:42 AM, Ning Qu  wrote:
>> I agree with this. It has been like this just for a quick proof, but I
>> need to address this problem as soon as possible.
>>
>> Thanks!
>> Best wishes,
>> --
>> Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066
>>
>>
>> On Tue, Oct 15, 2013 at 4:09 AM, Kirill A. Shutemov
>>  wrote:
>>> Ning Qu wrote:
 Signed-off-by: Ning Qu 
 ---
  mm/Kconfig | 4 ++--
  mm/shmem.c | 5 +
  2 files changed, 7 insertions(+), 2 deletions(-)

 diff --git a/mm/Kconfig b/mm/Kconfig
 index 562f12f..4d2f90f 100644
 --- a/mm/Kconfig
 +++ b/mm/Kconfig
 @@ -428,8 +428,8 @@ config TRANSPARENT_HUGEPAGE_PAGECACHE
   help
 Enabling the option adds support hugepages for file-backed
 mappings. It requires transparent hugepage support from
 -   filesystem side. For now, the only filesystem which supports
 -   hugepages is ramfs.
 +   filesystem side. For now, the filesystems which support
 +   hugepages are: ramfs and tmpfs.

  config CROSS_MEMORY_ATTACH
   bool "Cross Memory Support"
 diff --git a/mm/shmem.c b/mm/shmem.c
 index 75c0ac6..50a3335 100644
 --- a/mm/shmem.c
 +++ b/mm/shmem.c
 @@ -1672,6 +1672,11 @@ static struct inode *shmem_get_inode(struct 
 super_block *sb, const struct inode
   break;
   case S_IFREG:
   inode->i_mapping->a_ops = _aops;
 + /*
 +  * TODO: make tmpfs pages movable
 +  */
 + mapping_set_gfp_mask(inode->i_mapping,
 +  GFP_TRANSHUGE & ~__GFP_MOVABLE);
>>>
>>> Unlike ramfs, tmpfs pages are movable before transparent page cache
>>> patchset.
>>> Making tmpfs pages non-movable looks like a big regression to me. It need
>>> to be fixed before proposing it upstream.
>>>
>>> --
>>>  Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] rsxx: Fix possible kernel panic with invalid config.

[Philip J. Kelleher]

From: Philip J Kelleher 

This patch fixes a possible Kernel Panic on driver load if 
the configuration on the card is messed up or not yet set.
The driver could possible give a 32 bit unsigned all Fs to
the kernel as the device's block size.

Now we only write the block size to the kernel if the
configuration from the card is valid.

Also, driver version is being updated.

Signed-off-by: Philip J Kelleher 
---


diff -uprN -X linux-2.6.32-422.el6-vanilla/Documentation/dontdiff 
linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/dev.c 
linux-2.6.32-422.el6/drivers/block/rsxx/dev.c
--- linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/dev.c   2013-10-15 
15:19:39.406674940 -0500
+++ linux-2.6.32-422.el6/drivers/block/rsxx/dev.c   2013-10-18 
13:40:30.943877311 -0500
@@ -297,13 +297,15 @@ int rsxx_setup_dev(struct rsxx_cardinfo 
return -ENOMEM;
}
 
-   blk_size = card->config.data.block_size;
+   if (card->config_valid) {
+   blk_size = card->config.data.block_size;
+   blk_queue_dma_alignment(card->queue, blk_size - 1);
+   blk_queue_logical_block_size(card->queue, blk_size);
+   }
 
blk_queue_make_request(card->queue, rsxx_make_request);
blk_queue_bounce_limit(card->queue, BLK_BOUNCE_ANY);
-   blk_queue_dma_alignment(card->queue, blk_size - 1);
blk_queue_max_hw_sectors(card->queue, blkdev_max_hw_sectors);
-   blk_queue_logical_block_size(card->queue, blk_size);
blk_queue_physical_block_size(card->queue, RSXX_HW_BLK_SIZE);
 
queue_flag_set_unlocked(QUEUE_FLAG_NONROT, card->queue);
diff -uprN -X linux-2.6.32-422.el6-vanilla/Documentation/dontdiff 
linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/rsxx_priv.h 
linux-2.6.32-422.el6/drivers/block/rsxx/rsxx_priv.h
--- linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/rsxx_priv.h 2013-10-18 
13:21:36.219677235 -0500
+++ linux-2.6.32-422.el6/drivers/block/rsxx/rsxx_priv.h 2013-10-18 
13:40:30.952991256 -0500
@@ -52,7 +52,7 @@ struct proc_cmd;
 #define RS70_PCI_REV_SUPPORTED 4
 
 #define DRIVER_NAME "rsxx"
-#define DRIVER_VERSION "4.0.2.2510"
+#define DRIVER_VERSION "4.0.3.2516"
 
 /* Block size is 4096 */
 #define RSXX_HW_BLK_SHIFT  12

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] rsxx: Disallow discards from being unmapped.

[Philip J. Kelleher]

From: Philip J Kelleher 

This patch fixes a bug in which discards were always
calling pci_unmap_page. Discards should never call the
pci_unmap_page function call because they are never mapped.

This caused a race condition on PowerPC systems when issuing
discards, writes, and reads all at the same time. The
pci_map_page function would eventually map logical address
0 for a read or write. Discards are always assigned a DMA
address of 0 because they are never mapped. So if
pci_map_page mapped address 0 for a DMA and a discard was
"unmapped" then the address would be freed and would cause 
an EEH event to occur when Hardware accesses the address.

This was injected/uncovered in commit:
b347f9cf0bc8d42ee95ba1d3837fd93045ab336b

The pci_dma_mapping_error function declares -1 a DMA_ERROR
not 0 like initially thought So before we would never unmap
discards because they were considered NULL.

This patch should fall on top of commit id:
fc1967bb08a6184ed44ef990e1dd4389901b809c

Also, the driver version is being up dated.

Signed-off-by: Philip J Kelleher 
---


diff -uprN -X linux-2.6.32-422.el6-vanilla/Documentation/dontdiff 
linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/dma.c 
linux-2.6.32-422.el6/drivers/block/rsxx/dma.c
--- linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/dma.c   2013-10-15 
15:19:39.404677428 -0500
+++ linux-2.6.32-422.el6/drivers/block/rsxx/dma.c   2013-10-15 
15:37:33.800759570 -0500
@@ -223,12 +223,14 @@ static void dma_intr_coal_auto_tune(stru
 /*- RSXX DMA Handling ---*/
 static void rsxx_free_dma(struct rsxx_dma_ctrl *ctrl, struct rsxx_dma *dma)
 {
-   if (!pci_dma_mapping_error(ctrl->card->dev, dma->dma_addr)) {
-   pci_unmap_page(ctrl->card->dev, dma->dma_addr,
-  get_dma_size(dma),
-  dma->cmd == HW_CMD_BLK_WRITE ?
-  PCI_DMA_TODEVICE :
-  PCI_DMA_FROMDEVICE);
+   if (dma->cmd != HW_CMD_BLK_DISCARD) {
+   if (!pci_dma_mapping_error(ctrl->card->dev, dma->dma_addr)) {
+   pci_unmap_page(ctrl->card->dev, dma->dma_addr,
+  get_dma_size(dma),
+  dma->cmd == HW_CMD_BLK_WRITE ?
+  PCI_DMA_TODEVICE :
+  PCI_DMA_FROMDEVICE);
+   }
}
 
kmem_cache_free(rsxx_dma_pool, dma);
@@ -1057,11 +1059,14 @@ int rsxx_eeh_save_issued_dmas(struct rsx
else
card->ctrl[i].stats.reads_issued--;
 
-   pci_unmap_page(card->dev, dma->dma_addr,
-  get_dma_size(dma),
-  dma->cmd == HW_CMD_BLK_WRITE ?
-  PCI_DMA_TODEVICE :
-  PCI_DMA_FROMDEVICE);
+   if (dma->cmd != HW_CMD_BLK_DISCARD) {
+   pci_unmap_page(card->dev, dma->dma_addr,
+  get_dma_size(dma),
+  dma->cmd == HW_CMD_BLK_WRITE ?
+  PCI_DMA_TODEVICE :
+  PCI_DMA_FROMDEVICE);
+   }
+
list_add_tail(>list, _dmas[i]);
push_tracker(card->ctrl[i].trackers, j);
cnt++;
diff -uprN -X linux-2.6.32-422.el6-vanilla/Documentation/dontdiff 
linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/rsxx_priv.h 
linux-2.6.32-422.el6/drivers/block/rsxx/rsxx_priv.h
--- linux-2.6.32-422.el6-vanilla/drivers/block/rsxx/rsxx_priv.h 2013-10-15 
15:19:39.414675085 -0500
+++ linux-2.6.32-422.el6/drivers/block/rsxx/rsxx_priv.h 2013-10-15 
15:40:40.074863193 -0500
@@ -52,7 +52,7 @@ struct proc_cmd;
 #define RS70_PCI_REV_SUPPORTED 4
 
 #define DRIVER_NAME "rsxx"
-#define DRIVER_VERSION "4.0.1.2498"
+#define DRIVER_VERSION "4.0.2.2510"
 
 /* Block size is 4096 */
 #define RSXX_HW_BLK_SHIFT  12

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] rsxx: Two important bug fixes for the rsxx block driver.

[Philip J. Kelleher]

The incoming patches are for the rsxx driver (drivers/block/rsxx)

Patch1:
This patch fixes a bug in which discards were always
calling pci_unmap_page. Discards should never call the
pci_unmap_page function call because they are never mapped.

This caused a race condition on PowerPC systems when issuing
discards, writes, and reads all at the same time. The
pci_map_page function would eventually map logical address
0 for a read or write. Discards are always assigned a DMA
address of 0 because they are never mapped. So if
pci_map_page mapped address 0 for a DMA and a discard was
"unmapped" then the address would be freed and would cause 
an EEH event to occur when Hardware accesses the address.

This was injected/uncovered in commit:
b347f9cf0bc8d42ee95ba1d3837fd93045ab336b

The pci_dma_mapping_error function declares -1 a DMA_ERROR
not 0 like initially thought.

This patch should fall on top of commit id:
fc1967bb08a6184ed44ef990e1dd4389901b809c


Patch2:
This patch fixes a possible Kernel Panic on driver load if 
the configuration on the card is messed up or not yet set.
The driver could possible give a 32 bit unsigned all Fs to
the kernel as the device's block size.

Now we only write the block size to the kernel if the
configuration from the card is valid.

Regards,
- Philip Kelleher


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts

[Doug Anderson]

In the patch (9623b5b mmc: dw_mmc: Disable low power mode if SDIO
interrupts are used) I added code that disabled the low power mode of
dw_mmc when SDIO interrupts are used.  That code worked but always
felt a little hacky because we ended up disabling low power as a side
effect of the first enable_sdio_irq() call.  That wouldn't be so bad
except that disabling low power involves a complicated process of
writing to the CMD/CMDARG registers and that extra process makes it
difficult to cleanly the read-modify-write race in
dw_mci_enable_sdio_irq() (see future patch in the series).

Change the code to take advantage of the init_card() callback of the
mmc core to know when an SDIO card has been inserted.  If we've got a
SDIO card and we're configured to use SDIO Interrupts then turn off
"low power mode" right away.

Signed-off-by: Doug Anderson 
---
Changes in v3: None
Changes in v2:
- Fixed "|" to "&".

 drivers/mmc/host/dw_mmc.c | 68 ---
 drivers/mmc/host/dw_mmc.h |  1 +
 2 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 0a6a512..6c8d6a9 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -822,7 +823,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool 
force_clkinit)
 
/* enable clock; only low power if no SDIO */
clk_en_a = SDMMC_CLKEN_ENABLE << slot->id;
-   if (!(mci_readl(host, INTMASK) & SDMMC_INT_SDIO(slot->id)))
+   if (!test_bit(DW_MMC_CARD_NO_LOW_PWR, >flags))
clk_en_a |= SDMMC_CLKEN_LOW_PWR << slot->id;
mci_writel(host, CLKENA, clk_en_a);
 
@@ -1050,27 +1051,37 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
return present;
 }
 
-/*
- * Disable lower power mode.
- *
- * Low power mode will stop the card clock when idle.  According to the
- * description of the CLKENA register we should disable low power mode
- * for SDIO cards if we need SDIO interrupts to work.
- *
- * This function is fast if low power mode is already disabled.
- */
-static void dw_mci_disable_low_power(struct dw_mci_slot *slot)
+static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card)
 {
+   struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot->host;
-   u32 clk_en_a;
-   const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
 
-   clk_en_a = mci_readl(host, CLKENA);
+   /*
+* Low power mode will stop the card clock when idle.  According to the
+* description of the CLKENA register we should disable low power mode
+* for SDIO cards if we need SDIO interrupts to work.
+*/
+   if (mmc->caps & MMC_CAP_SDIO_IRQ) {
+   const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
+   u32 clk_en_a_old;
+   u32 clk_en_a;
 
-   if (clk_en_a & clken_low_pwr) {
-   mci_writel(host, CLKENA, clk_en_a & ~clken_low_pwr);
-   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
-SDMMC_CMD_PRV_DAT_WAIT, 0);
+   clk_en_a_old = mci_readl(host, CLKENA);
+
+   if (card->type == MMC_TYPE_SDIO ||
+   card->type == MMC_TYPE_SD_COMBO) {
+   set_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
+   clk_en_a = clk_en_a_old & ~clken_low_pwr;
+   } else {
+   clear_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
+   clk_en_a = clk_en_a_old | clken_low_pwr;
+   }
+
+   if (clk_en_a != clk_en_a_old) {
+   mci_writel(host, CLKENA, clk_en_a);
+   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
+SDMMC_CMD_PRV_DAT_WAIT, 0);
+   }
}
 }
 
@@ -1082,21 +1093,11 @@ static void dw_mci_enable_sdio_irq(struct mmc_host 
*mmc, int enb)
 
/* Enable/disable Slot Specific SDIO interrupt */
int_mask = mci_readl(host, INTMASK);
-   if (enb) {
-   /*
-* Turn off low power mode if it was enabled.  This is a bit of
-* a heavy operation and we disable / enable IRQs a lot, so
-* we'll leave low power mode disabled and it will get
-* re-enabled again in dw_mci_setup_bus().
-*/
-   dw_mci_disable_low_power(slot);
-
-   mci_writel(host, INTMASK,
-  (int_mask | SDMMC_INT_SDIO(slot->id)));
-   } else {
-   mci_writel(host, INTMASK,
-  (int_mask & ~SDMMC_INT_SDIO(slot->id)));
-   }
+   if (enb)
+   int_mask |= SDMMC_INT_SDIO(slot->id);
+   else
+   int_mask &= ~SDMMC_INT_SDIO(slot->id);
+   mci_writel(host, INTMASK, 

[PATCH v3 0/3] Prevent races when doing read-modify-write of INTMASK

[Doug Anderson]

Bing Zhao at Marvell discovered a race in the way that dw_mmc was
doing a read-modify-write of the INTMASK register.  This 2-patch
series attempts to fix the problem using a simple spinlock.  In order
to do so cleanly, we include a patch to tidy up the way that we
disable low power mode when using SDIO interrupts.

This patch series was not tested on ToT Linux other than basic
compiling and booting, since we don't have the whole Marvell SDIO
stack up and running in mainline yet.  This series is based on
mmc-next (e76b855 mmc: sdhci-esdhc-imx: set actual_clock in clock
setting) merged atop mainlinx Linux.

Changes in v3:
- Add fixup to pandora_wl1251_init_card().

Changes in v2:
- Core patch new for this version.
- Fixed "|" to "&".
- intmask_lock renamed to irq_lock

Doug Anderson (3):
  mmc: core: Support the optional init_card() callback for MMC and SD
  mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
  mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock

 arch/arm/mach-omap2/board-omap3pandora.c | 14 +++---
 drivers/mmc/core/mmc.c   |  6 +++
 drivers/mmc/core/sd.c|  7 ++-
 drivers/mmc/host/dw_mmc.c| 79 +++-
 drivers/mmc/host/dw_mmc.h|  1 +
 include/linux/mmc/dw_mmc.h   |  6 +++
 6 files changed, 74 insertions(+), 39 deletions(-)

-- 
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/

[PATCH v3 3/3] mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock

[Doug Anderson]

We're running into cases where our enabling of the SDIO interrupt in
dw_mmc doesn't actually take effect.  Specifically, adding patch like
this:

 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -1076,6 +1076,9 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, 
int enb)

  mci_writel(host, INTMASK,
   (int_mask | SDMMC_INT_SDIO(slot->id)));
 +int_mask = mci_readl(host, INTMASK);
 +if (!(int_mask & SDMMC_INT_SDIO(slot->id)))
 +  dev_err(>class_dev, "failed to enable sdio irq\n");
} else {

...actually triggers the error message.  That's because the
dw_mci_enable_sdio_irq() unsafely does a read-modify-write of the
INTMASK register.

We can't just use the standard host->lock since that lock is not irq
safe and mmc_signal_sdio_irq() (called from interrupt context) calls
dw_mci_enable_sdio_irq().  Add a new irq-safe lock to protect INTMASK.

An alternate solution to this is to punt mmc_signal_sdio_irq() to the
tasklet and then protect INTMASK modifications by the standard host
lock.  This seemed like a bit more of a high-latency change.

Reported-by: Bing Zhao 
Signed-off-by: Doug Anderson 
Reviewed-by: James Hogan 
---
Changes in v3: None
Changes in v2:
- intmask_lock renamed to irq_lock

 drivers/mmc/host/dw_mmc.c  | 13 +
 include/linux/mmc/dw_mmc.h |  6 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 6c8d6a9..3b910ec 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -657,6 +657,7 @@ disable:
 
 static int dw_mci_submit_data_dma(struct dw_mci *host, struct mmc_data *data)
 {
+   unsigned long irqflags;
int sg_len;
u32 temp;
 
@@ -693,9 +694,11 @@ static int dw_mci_submit_data_dma(struct dw_mci *host, 
struct mmc_data *data)
mci_writel(host, CTRL, temp);
 
/* Disable RX/TX IRQs, let DMA handle it */
+   spin_lock_irqsave(>irq_lock, irqflags);
temp = mci_readl(host, INTMASK);
temp  &= ~(SDMMC_INT_RXDR | SDMMC_INT_TXDR);
mci_writel(host, INTMASK, temp);
+   spin_unlock_irqrestore(>irq_lock, irqflags);
 
host->dma_ops->start(host, sg_len);
 
@@ -704,6 +707,7 @@ static int dw_mci_submit_data_dma(struct dw_mci *host, 
struct mmc_data *data)
 
 static void dw_mci_submit_data(struct dw_mci *host, struct mmc_data *data)
 {
+   unsigned long irqflags;
u32 temp;
 
data->error = -EINPROGRESS;
@@ -732,9 +736,12 @@ static void dw_mci_submit_data(struct dw_mci *host, struct 
mmc_data *data)
host->part_buf_count = 0;
 
mci_writel(host, RINTSTS, SDMMC_INT_TXDR | SDMMC_INT_RXDR);
+
+   spin_lock_irqsave(>irq_lock, irqflags);
temp = mci_readl(host, INTMASK);
temp |= SDMMC_INT_TXDR | SDMMC_INT_RXDR;
mci_writel(host, INTMASK, temp);
+   spin_unlock_irqrestore(>irq_lock, irqflags);
 
temp = mci_readl(host, CTRL);
temp &= ~SDMMC_CTRL_DMA_ENABLE;
@@ -1089,8 +1096,11 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, 
int enb)
 {
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot->host;
+   unsigned long irqflags;
u32 int_mask;
 
+   spin_lock_irqsave(>irq_lock, irqflags);
+
/* Enable/disable Slot Specific SDIO interrupt */
int_mask = mci_readl(host, INTMASK);
if (enb)
@@ -1098,6 +1108,8 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, 
int enb)
else
int_mask &= ~SDMMC_INT_SDIO(slot->id);
mci_writel(host, INTMASK, int_mask);
+
+   spin_unlock_irqrestore(>irq_lock, irqflags);
 }
 
 static int dw_mci_execute_tuning(struct mmc_host *mmc, u32 opcode)
@@ -2500,6 +2512,7 @@ int dw_mci_probe(struct dw_mci *host)
host->quirks = host->pdata->quirks;
 
spin_lock_init(>lock);
+   spin_lock_init(>irq_lock);
INIT_LIST_HEAD(>queue);
 
/*
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 6ce7d2c..55e1d4e 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -102,6 +102,11 @@ struct mmc_data;
  * @cur_slot, @mrq and @state. These must always be updated
  * at the same time while holding @lock.
  *
+ * @irq_lock is an irq-safe spinlock protecting the INTMASK register
+ * to allow the interrupt handler to modify it directly.  Held for only long
+ * enough to read-modify-write INTMASK and no other locks are grabbed when
+ * holding this one.
+ *
  * The @mrq field of struct dw_mci_slot is also protected by @lock,
  * and must always be written at the same time as the slot is added to
  * @queue.
@@ -121,6 +126,7 @@ struct mmc_data;
  */
 struct dw_mci {
spinlock_t  lock;
+   spinlock_t  irq_lock;
void __iomem*regs;
 
struct scatterlist  *sg;
-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH] USB: wusbcore: fix usb_dev leaks

[Alexey Khoroshilov]

cbaf_probe() does cbaf->usb_dev = usb_get_dev(interface_to_usbdev(iface)),
but there is no usb_put_dev() anywhere in cbaf.

The patch adds usb_put_dev() to cbaf_disconnect() and to an error path in 
cbaf_probe().
Also it adds missed usb_put_intf(iface) to the error path.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/usb/wusbcore/cbaf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/wusbcore/cbaf.c b/drivers/usb/wusbcore/cbaf.c
index 7f78f30..4035004 100644
--- a/drivers/usb/wusbcore/cbaf.c
+++ b/drivers/usb/wusbcore/cbaf.c
@@ -623,6 +623,8 @@ static int cbaf_probe(struct usb_interface *iface,
 
 error_create_group:
 error_check:
+   usb_put_intf(iface);
+   usb_put_dev(cbaf->usb_dev);
kfree(cbaf->buffer);
 error_kmalloc_buffer:
kfree(cbaf);
@@ -637,6 +639,7 @@ static void cbaf_disconnect(struct usb_interface *iface)
sysfs_remove_group(>kobj, _dev_attr_group);
usb_set_intfdata(iface, NULL);
usb_put_intf(iface);
+   usb_put_dev(cbaf->usb_dev);
kfree(cbaf->buffer);
/* paranoia: clean up crypto keys */
kzfree(cbaf);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/7] ARM: at91/dt: define sama5d3 clocks

[Boris BREZILLON]

Define sama5d3 clocks in sama5d3 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON 
---
Changes since v2:
 - add usb_clk to usb ehci controller node

This new version (and the associated patch
"USB: ehci-atmel: add usb_clk for transition to CCF") fixes a bug in ehci clk
initialization.

 arch/arm/boot/dts/sama5d3.dtsi  |  331 ++-
 arch/arm/boot/dts/sama5d3_can.dtsi  |   18 ++
 arch/arm/boot/dts/sama5d3_emac.dtsi |   10 ++
 arch/arm/boot/dts/sama5d3_gmac.dtsi |   10 ++
 arch/arm/boot/dts/sama5d3_lcd.dtsi  |   15 ++
 arch/arm/boot/dts/sama5d3_mci2.dtsi |   11 ++
 arch/arm/boot/dts/sama5d3_tcb1.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_uart.dtsi |   19 ++
 8 files changed, 425 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 5cdaba4..20a6e4e 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Atmel SAMA5D3 family SoC";
@@ -56,6 +57,14 @@
reg = <0x2000 0x800>;
};
 
+   clocks {
+   adc_op_clk: adc_op_clk{
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2000>;
+   };
+   };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -79,6 +88,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < 21>;
+   clock-names = "mci_clk";
};
 
spi0: spi@f0004000 {
@@ -92,6 +103,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <_spi0>;
+   clocks = < 24>;
+   clock-names = "spi_clk";
status = "disabled";
};
 
@@ -101,6 +114,8 @@
interrupts = <38 IRQ_TYPE_LEVEL_HIGH 4>;
pinctrl-names = "default";
pinctrl-0 = <_ssc0_tx _ssc0_rx>;
+   clocks = < 38>;
+   clock-names = "pclk";
status = "disabled";
};
 
@@ -108,6 +123,8 @@
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf001 0x100>;
interrupts = <26 IRQ_TYPE_LEVEL_HIGH 0>;
+   clocks = < 26>;
+   clock-names = "t0_clk";
};
 
i2c0: i2c@f0014000 {
@@ -121,6 +138,7 @@
pinctrl-0 = <_i2c0>;
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < 18>;
status = "disabled";
};
 
@@ -135,6 +153,7 @@
pinctrl-0 = <_i2c1>;
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < 19>;
status = "disabled";
};
 
@@ -144,6 +163,8 @@
interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <_usart0>;
+   clocks = < 12>;
+   clock-names = "usart";
status = "disabled";
};
 
@@ -153,6 +174,8 @@
interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <_usart1>;
+   clocks = < 13>;
+   clock-names = "usart";
status = "disabled";
};
 
@@ -174,6 +197,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < 22>;
+   clock-names = "mci_clk";
};
 
spi1: spi@f8008000 {
@@ -187,6 +212,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <_spi1>;
+  

[PATCH v1.1 1/3] MAINTAINERS: INTEL MID SOC: add maintainers

[David Cohen]

Low-power Intel MID SoC support is currently quite outdated.
The code is meant for the old Moorestown platform and has not proper
support for newer platforms like Medfield, Clovertrail, Merrifield, ...

This patch adds official maintainers for such platforms in order to get
things in a better shape from now on.

Signed-off-by: David Cohen 
Cc: Kuppuswamy Sathyanarayanan 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7534a80..25a0aa0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5203,6 +5203,15 @@ W:   logfs.org
 S: Maintained
 F: fs/logfs/
 
+LOW-POWER INTEL MID SOC SUPPORT
+M: David Cohen 
+M: Kuppuswamy Sathyanarayanan 
+S: Supported
+F: arch/x86/platform/intel-mid/
+F: arch/x86/pci/intel_mid_pci.c
+F: arch/x86/include/asm/intel-mid.h
+F: arch/x86/include/asm/intel_mid*.h
+
 LPC32XX MACHINE SUPPORT
 M: Roland Stigge 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/9] ACPI, x86: Extended error log driver for x86 platform

[Borislav Petkov]

On Fri, Oct 18, 2013 at 08:57:22PM +, Luck, Tony wrote:
> Long term ... I'd be happy to see mce_log() go away. But we need to
> have a robust, well tested replacement in place for some time before
> such a move is up for discussion.

Basically a userspace daemon consuming the tracepoint or plural,
tracepoints.

> Yes - double error reporting should be avoided.

Right.

> Our first platforms to implement this only do so for memory errors.
> This could change in the future (the UEFI appendix N error record has
> defined sub-sections for lots of types of errors).

Ok.

> Currently EDAC hooked into the mce even notification chain provides a
> return code to indicate whether it completely processed the error, or
> whether to fall through to the rest of mce_log():
> 
>   if (ret == NOTIFY_STOP)
>   return;
> 
> Having both EDAC and this new extended error log both registered on this
> chain would probably not be helpful in most cases.

Not only that - you don't need EDAC because all the information is in
the MCA registers and the eMCA supplement, if there is one.

EDAC would be used on older systems which don't sport eMCA.

Now, concerning the current situation, we probably want to do something
like this:

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index b1b04123f3d9..382c78eaf474 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -154,6 +154,10 @@ void mce_log(struct mce *mce)
/* Emit the trace record: */
trace_mce_record(mce);
 
+   if (mce_ext_err_print)
+   if (mce_ext_err_print(NULL, m.extcpu, i))
+   return;
+
ret = atomic_notifier_call_chain(_mce_decoder_chain, 0, mce);
if (ret == NOTIFY_STOP)
return;
--

Right, we've moved the eMCA print thingie to mce_log so that we get a
chance to run the first TP issuing the raw MCA registers and then run
the eMCA TP as a follow-up.

We've taught mce_ext_err_print() to return a true/false retval to denote:

* true: it has collected data successfully, no need to go down the reporting
  chain

* false: eMCA failed somehow, log the error down and trigger mcelog in
  userspace.

How does that sound?

> Not sure if we should handle that with user education to not load both
> an EDAC and ext_log driver or if there should be some enforcement.

Definitely enforcement. The flags thing I was telling you about recently
could be one way to do it.

> trace_mce_record() dumps the raw data from the machine check banks. I
> think there may still be a case for having this. Analysis tools that
> look at this trace as well should be smart enough to connect the dots.

Yes, sure. The more non-overlaping data we get, the better.

Thanks.

-- 
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] MAINTAINERS: INTEL MID SOC: add maintainers

[David Cohen]

On 10/18/2013 02:21 PM, Joe Perches wrote:

On Fri, 2013-10-18 at 14:18 -0700, David Cohen wrote:

Low-power Intel MID SoC support is currently quite outdated.
The code is meant for the old Moorestown platform and has not proper
support for newer platforms like Medfield, Clovertrail, Merrifield, ...

This patch adds official maintainers for such platforms in order to get
things in a better shape from now on.


 From MAINTAINERS:

Note: For the hard of thinking, this list is meant to remain in alphabetical
order. If you could add yourselves to it in alphabetical order that would be
so much easier [Ed]


Thanks. Fixing it right now.

Br, David Cohen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/11] 3.4.67-stable review

[Greg Kroah-Hartman]

On Fri, Oct 18, 2013 at 01:49:17PM -0700, Guenter Roeck wrote:
> On Fri, Oct 18, 2013 at 12:53:29PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.67 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Oct 20 19:50:39 UTC 2013.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.67-rc1.gz
> > and the diffstat can be found below.
> > 
> Build results:
>   total: 103 pass: 89 skipped: 10 fail: 4
> 
> qemu tests all pass.
> 
> This matches the results seen with the previous 3.4 release, so everything
> is as expected.

Great, thanks for testing and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] MAINTAINERS: INTEL MID SOC: add maintainers

[Joe Perches]

On Fri, 2013-10-18 at 14:18 -0700, David Cohen wrote:
> Low-power Intel MID SoC support is currently quite outdated.
> The code is meant for the old Moorestown platform and has not proper
> support for newer platforms like Medfield, Clovertrail, Merrifield, ...
> 
> This patch adds official maintainers for such platforms in order to get
> things in a better shape from now on.

>From MAINTAINERS:

Note: For the hard of thinking, this list is meant to remain in alphabetical
order. If you could add yourselves to it in alphabetical order that would be
so much easier [Ed]

> diff --git a/MAINTAINERS b/MAINTAINERS

> @@ -7570,6 +7570,15 @@ F: arch/x86/platform/sfi/
>  F:   drivers/sfi/
>  F:   include/linux/sfi*.h
>  
> +LOW-POWER INTEL MID SOC SUPPORT
> +M:   David Cohen 
> +M:   Kuppuswamy Sathyanarayanan 
> +S:   Supported
> +F:   arch/x86/platform/intel-mid/
> +F:   arch/x86/pci/intel_mid_pci.c
> +F:   arch/x86/include/asm/intel-mid.h
> +F:   arch/x86/include/asm/intel_mid*.h
> +
>  SIMTEC EB110ATX (Chalice CATS)
>  P:   Ben Dooks
>  P:   Vincent Sanders 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/lib: Export fdt routines to modules

[Rob Herring]

On 10/18/2013 02:32 PM, Michael Bohan wrote:
> On Fri, Oct 18, 2013 at 09:30:32AM -0700, David Daney wrote:
>> On 10/18/2013 08:57 AM, Rob Herring wrote:
>> [...]
>>>
>>> Unflattening is definitely the right
>>> direction to go here.
>>>
>>
>> I wonder if that is really true.
>>
>> The device tree in question is very short lived, and used to control
>> the configuration of some hardware device when loading the driver.
>>
>> The use of it is completely contained within a single driver (at
>> least that is my understanding), it is not information that needs to
>> be shared system wide.
> 
> That's correct.
> 
>> Given that it is a driver implementation issue, rather than making
>> things work nicely system wide, I don't think it really matters what
>> is done.
>>
>> It may be that the overhead of unflattening the tree and then
>> freeing it, is much greater than just extracting a few things from
>> the FDT.
> 
> Yes, this was my original thought as well. On the other hand,
> having libfdt in the kernel does add a little extra bloat, and so
> it seems a tradeoff from one-time runtime overhead to footprint.
> 
>> That said, I don't really have a preference for what is done.  My
>> original questions were targeted at understanding this particular
>> use case.
> 
> My preference is probably straight libfdt calls, but if others
> think that unpacking is a better solution, I'm able to go that
> route as well. My only concern there is that we provide a means
> to detect invalid dtb image (ex. handle error codes) and also
> free the device_node allocations once the device is released.

I think we need to understand what you are putting in the DT first.

Given there are other desired uses like overlays which need to add the
necessary loading and unflattening support, a common solution is likely
more desirable.

Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Add maintainers + Clovertrail support to Intel Mid

[David Cohen]

This is the next series of patches to add initial support to more Intel Mid
platforms. This time is Clovertrail. Next it will be Merrifield.

This patch set:
1. adds maintainers to Intel Mid architecture
2. moves Medfield code to its own file
3. adds Clovertrail support to Intel Mid

---
David Cohen (2):
  MAINTAINERS: INTEL MID SOC: add maintainers
  x86: intel-mid: move Medfield code out of intel-mid.c core file

Kuppuswamy Sathyanarayanan (1):
  x86: intel-mid: add Clovertrail platform support

 MAINTAINERS|  9 +++
 arch/x86/include/asm/intel-mid.h   | 46 -
 arch/x86/platform/intel-mid/Makefile   |  4 +-
 arch/x86/platform/intel-mid/intel-mid.c| 60 -
 arch/x86/platform/intel-mid/intel_mid_weak_decls.h | 18 ++
 arch/x86/platform/intel-mid/mfld.c | 75 ++
 6 files changed, 178 insertions(+), 34 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/intel_mid_weak_decls.h
 create mode 100644 arch/x86/platform/intel-mid/mfld.c

-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] MAINTAINERS: INTEL MID SOC: add maintainers

[David Cohen]

Low-power Intel MID SoC support is currently quite outdated.
The code is meant for the old Moorestown platform and has not proper
support for newer platforms like Medfield, Clovertrail, Merrifield, ...

This patch adds official maintainers for such platforms in order to get
things in a better shape from now on.

Signed-off-by: David Cohen 
Cc: Kuppuswamy Sathyanarayanan 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7534a80..8ef9e65 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7570,6 +7570,15 @@ F:   arch/x86/platform/sfi/
 F: drivers/sfi/
 F: include/linux/sfi*.h
 
+LOW-POWER INTEL MID SOC SUPPORT
+M: David Cohen 
+M: Kuppuswamy Sathyanarayanan 
+S: Supported
+F: arch/x86/platform/intel-mid/
+F: arch/x86/pci/intel_mid_pci.c
+F: arch/x86/include/asm/intel-mid.h
+F: arch/x86/include/asm/intel_mid*.h
+
 SIMTEC EB110ATX (Chalice CATS)
 P: Ben Dooks
 P: Vincent Sanders 
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] x86: intel-mid: add Clovertrail platform support

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

This patch adds Clovertrail support on intel-mid and makes it more
flexible to support other SoCs.

Signed-off-by: David Cohen 
Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: Fei Yang 
---
 arch/x86/include/asm/intel-mid.h   | 46 +-
 arch/x86/platform/intel-mid/intel-mid.c| 39 --
 arch/x86/platform/intel-mid/intel_mid_weak_decls.h |  7 +++-
 arch/x86/platform/intel-mid/mfld.c | 32 +--
 4 files changed, 113 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 459769d..f8a8314 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -51,10 +51,39 @@ struct devs_id {
 enum intel_mid_cpu_type {
/* 1 was Moorestown */
INTEL_MID_CPU_CHIP_PENWELL = 2,
+   INTEL_MID_CPU_CHIP_CLOVERVIEW,
 };
 
 extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
 
+/**
+ * struct intel_mid_ops - Interface between intel-mid & sub archs
+ * @arch_setup: arch_setup function to re-initialize platform
+ * structures (x86_init, x86_platform_init)
+ *
+ * This structure can be extended if any new interface is required
+ * between intel-mid & its sub arch files.
+ */
+struct intel_mid_ops {
+   void (*arch_setup)(void);
+};
+
+/* Helper API's for INTEL_MID_OPS_INIT */
+#define DECLARE_INTEL_MID_OPS_INIT(cpuname, cpuid) \
+   [cpuid] = get_##cpuname##_ops
+
+/* Maximum number of CPU ops */
+#define MAX_CPU_OPS(a) (sizeof(a)/sizeof(void *))
+
+/*
+ * For every new cpu addition, a weak get__ops() function needs be
+ * declared in arch/x86/platform/intel_mid/intel_mid_weak_decls.h.
+ */
+#define INTEL_MID_OPS_INIT {\
+   DECLARE_INTEL_MID_OPS_INIT(penwell, INTEL_MID_CPU_CHIP_PENWELL), \
+   DECLARE_INTEL_MID_OPS_INIT(cloverview, INTEL_MID_CPU_CHIP_CLOVERVIEW), \
+};
+
 #ifdef CONFIG_X86_INTEL_MID
 
 static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
@@ -86,8 +115,21 @@ extern enum intel_mid_timer_options intel_mid_timer_options;
  * Penwell uses spread spectrum clock, so the freq number is not exactly
  * the same as reported by MSR based on SDM.
  */
-#define PENWELL_FSB_FREQ_83SKU 83200
-#define PENWELL_FSB_FREQ_100SKU99840
+#define FSB_FREQ_83SKU 83200
+#define FSB_FREQ_100SKU99840
+#define FSB_FREQ_133SKU133000
+
+#define FSB_FREQ_167SKU167000
+#define FSB_FREQ_200SKU20
+#define FSB_FREQ_267SKU267000
+#define FSB_FREQ_333SKU333000
+#define FSB_FREQ_400SKU40
+
+/* Bus Select SoC Fuse value */
+#define BSEL_SOC_FUSE_MASK 0x7
+#define BSEL_SOC_FUSE_001  0x1 /* FSB 133MHz */
+#define BSEL_SOC_FUSE_101  0x5 /* FSB 100MHz */
+#define BSEL_SOC_FUSE_111  0x7 /* FSB 83MHz */
 
 #define SFI_MTMR_MAX_NUM 8
 #define SFI_MRTC_MAX   8
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 803a17f..bb0cf4d 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -60,14 +60,27 @@
 
 enum intel_mid_timer_options intel_mid_timer_options;
 
+/* intel_mid_ops to store sub arch ops */
+struct intel_mid_ops *intel_mid_ops;
+/* getter function for sub arch ops*/
+static void *(*get_intel_mid_ops[])(void) = INTEL_MID_OPS_INIT;
 enum intel_mid_cpu_type __intel_mid_cpu_chip;
 EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
+static void intel_mid_power_off(void)
+{
+};
+
 static void intel_mid_reboot(void)
 {
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
 }
 
+static unsigned long __init intel_mid_calibrate_tsc(void)
+{
+   return 0;
+}
+
 static void __init intel_mid_time_init(void)
 {
sfi_table_parse(SFI_SIG_MTMR, NULL, NULL, sfi_parse_mtmr);
@@ -92,13 +105,33 @@ static void __init intel_mid_time_init(void)
 
 static void __cpuinit intel_mid_arch_setup(void)
 {
-   if (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x27)
-   __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_PENWELL;
-   else {
+   if (boot_cpu_data.x86 != 6) {
pr_err("Unknown Intel MID CPU (%d:%d), default to Penwell\n",
boot_cpu_data.x86, boot_cpu_data.x86_model);
__intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_PENWELL;
+   goto out;
+   }
+
+   switch (boot_cpu_data.x86_model) {
+   case 0x35:
+   __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_CLOVERVIEW;
+   break;
+   case 0x27:
+   default:
+   __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_PENWELL;
+   break;
}
+
+   if (__intel_mid_cpu_chip < MAX_CPU_OPS(get_intel_mid_ops))
+   intel_mid_ops = get_intel_mid_ops[__intel_mid_cpu_chip]();
+   else {
+   intel_mid_ops = get_intel_mid_ops[INTEL_MID_CPU_CHIP_PENWELL]();
+   

[PATCH 2/3] x86: intel-mid: move Medfield code out of intel-mid.c core file

[David Cohen]

In order make the driver more portable and support other Intel Mid
platforms we need to move Medfield code from intel-mid.c core to its own
mfld.c file.

This patch does no functional change.

Signed-off-by: David Cohen 
Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 arch/x86/platform/intel-mid/Makefile   |  4 +-
 arch/x86/platform/intel-mid/intel-mid.c| 37 +---
 arch/x86/platform/intel-mid/intel_mid_weak_decls.h | 15 +++
 arch/x86/platform/intel-mid/mfld.c | 51 ++
 4 files changed, 70 insertions(+), 37 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/intel_mid_weak_decls.h
 create mode 100644 arch/x86/platform/intel-mid/mfld.c

diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile
index 01cc29e..78a14ba 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,6 +1,6 @@
-obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
-obj-$(CONFIG_X86_INTEL_MID) += intel_mid_vrtc.o
+obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o intel_mid_vrtc.o mfld.o
 obj-$(CONFIG_EARLY_PRINTK_INTEL_MID) += early_printk_intel_mid.o
+
 # SFI specific code
 ifdef CONFIG_X86_INTEL_MID
 obj-$(CONFIG_SFI) += sfi.o device_libs/
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 523a1c8..803a17f 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -35,6 +35,8 @@
 #include 
 #include 
 
+#include "intel_mid_weak_decls.h"
+
 /*
  * the clockevent devices on Moorestown/Medfield can be APBT or LAPIC clock,
  * cmdline option x86_intel_mid_timer can be used to override the configuration
@@ -61,46 +63,11 @@ enum intel_mid_timer_options intel_mid_timer_options;
 enum intel_mid_cpu_type __intel_mid_cpu_chip;
 EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
-static void intel_mid_power_off(void)
-{
-}
-
 static void intel_mid_reboot(void)
 {
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
 }
 
-static unsigned long __init intel_mid_calibrate_tsc(void)
-{
-   unsigned long fast_calibrate;
-   u32 lo, hi, ratio, fsb;
-
-   rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
-   pr_debug("IA32 perf status is 0x%x, 0x%0x\n", lo, hi);
-   ratio = (hi >> 8) & 0x1f;
-   pr_debug("ratio is %d\n", ratio);
-   if (!ratio) {
-   pr_err("read a zero ratio, should be incorrect!\n");
-   pr_err("force tsc ratio to 16 ...\n");
-   ratio = 16;
-   }
-   rdmsr(MSR_FSB_FREQ, lo, hi);
-   if ((lo & 0x7) == 0x7)
-   fsb = PENWELL_FSB_FREQ_83SKU;
-   else
-   fsb = PENWELL_FSB_FREQ_100SKU;
-   fast_calibrate = ratio * fsb;
-   pr_debug("read penwell tsc %lu khz\n", fast_calibrate);
-   lapic_timer_frequency = fsb * 1000 / HZ;
-   /* mark tsc clocksource as reliable */
-   set_cpu_cap(_cpu_data, X86_FEATURE_TSC_RELIABLE);
-
-   if (fast_calibrate)
-   return fast_calibrate;
-
-   return 0;
-}
-
 static void __init intel_mid_time_init(void)
 {
sfi_table_parse(SFI_SIG_MTMR, NULL, NULL, sfi_parse_mtmr);
diff --git a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h 
b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h
new file mode 100644
index 000..519beb7
--- /dev/null
+++ b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h
@@ -0,0 +1,15 @@
+/*
+ * intel_mid_weak_decls.h: Weak declarations of intel-mid.c
+ *
+ * (C) Copyright 2013 Intel Corporation
+ *
+ * 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; version 2
+ * of the License.
+ */
+
+
+/* __attribute__((weak)) makes these declarations overridable */
+extern void intel_mid_power_off(void) __attribute__((weak));
+extern unsigned long __init intel_mid_calibrate_tsc(void) 
__attribute__((weak));
diff --git a/arch/x86/platform/intel-mid/mfld.c 
b/arch/x86/platform/intel-mid/mfld.c
new file mode 100644
index 000..c7ff83c
--- /dev/null
+++ b/arch/x86/platform/intel-mid/mfld.c
@@ -0,0 +1,51 @@
+/*
+ * mfld.c: Intel Medfield platform setup code
+ *
+ * (C) Copyright 2013 Intel Corporation
+ *
+ * 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; version 2
+ * of the License.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+void intel_mid_power_off(void)
+{
+}
+
+unsigned long __init intel_mid_calibrate_tsc(void)
+{
+   unsigned long fast_calibrate;
+   u32 lo, hi, ratio, fsb;
+
+   rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
+   pr_debug("IA32 perf status is 0x%x, 0x%0x\n", lo, hi);
+   ratio = (hi >> 8) & 0x1f;
+   pr_debug("ratio is %d\n", ratio);
+   if (!ratio) {
+   pr_err("read a zero ratio, should be incorrect!\n");
+  

Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's

[Eric Dumazet]

On Fri, 2013-10-18 at 16:11 -0400, Neil Horman wrote:

> #define BUFSIZ_ORDER 4
> #define BUFSIZ ((2 << BUFSIZ_ORDER) * (1024*1024*2))
> static int __init csum_init_module(void)
> {
>   int i;
>   __wsum sum = 0;
>   struct timespec start, end;
>   u64 time;
>   struct page *page;
>   u32 offset = 0;
> 
>   page = alloc_pages((GFP_TRANSHUGE & ~__GFP_MOVABLE), BUFSIZ_ORDER);

Not sure what you are doing here, but its not correct.

You have a lot of variations in your results, I suspect a NUMA affinity
problem.

You can try the following code, and use taskset to make sure you run
this on a cpu on node 0

#define BUFSIZ 2*1024*1024
#define NBPAGES 16

static int __init csum_init_module(void)
{
int i;
__wsum sum = 0;
u64 start, end;
void *base, *addrs[NBPAGES];
u32 rnd, offset;

memset(addrs, 0, sizeof(addrs));
for (i = 0; i < NBPAGES; i++) {
addrs[i] = kmalloc_node(BUFSIZ, GFP_KERNEL, 0);
if (!addrs[i])
goto out;
}

local_bh_disable();
pr_err("STARTING ITERATIONS on cpu %d\n", smp_processor_id());
start = ktime_to_ns(ktime_get());

for (i = 0; i < 10; i++) {
rnd = prandom_u32();
base = addrs[rnd % NBPAGES];
rnd /= NBPAGES;
offset = rnd % (BUFSIZ - 1500);
offset &= ~1U;
sum = csum_partial_opt(base + offset, 1500, sum);
}
end = ktime_to_ns(ktime_get());
local_bh_enable();

pr_err("COMPLETED 10 iterations of csum %x in %llu nanosec\n", sum, 
end - start);

out:
for (i = 0; i < NBPAGES; i++)
kfree(addrs[i]);

return 0;
}

static void __exit csum_cleanup_module(void)
{
return;
}



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] tracing: fix referencing after memory freeing and refactors code

[Geyslan G. Bem]

In 'system_tr_open()':
Fix possible 'dir' assignment after freeing it.

In both functions:
Restructures logic conditions testing 'tracing_is_disabled()'
return before the others tests.
Centralizes the exiting in accordance to Coding Style, Chapter 7.

Signed-off-by: Geyslan G. Bem 
---
 kernel/trace/trace_events.c | 46 +++--
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 368a4d5..0f56ebf 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1060,7 +1060,10 @@ static int subsystem_open(struct inode *inode, struct 
file *filp)
struct event_subsystem *system = NULL;
struct ftrace_subsystem_dir *dir = NULL; /* Initialize for gcc */
struct trace_array *tr;
-   int ret;
+   int ret = -ENODEV;
+
+   if (tracing_is_disabled())
+   return ret;
 
/* Make sure the system still exists */
mutex_lock(_types_lock);
@@ -1082,23 +1085,21 @@ static int subsystem_open(struct inode *inode, struct 
file *filp)
mutex_unlock(_types_lock);
 
if (!system)
-   return -ENODEV;
+   return ret;
 
/* Some versions of gcc think dir can be uninitialized here */
WARN_ON(!dir);
 
/* Still need to increment the ref count of the system */
-   if (trace_array_get(tr) < 0) {
-   put_system(dir);
-   return -ENODEV;
-   }
+   ret = trace_array_get(tr);
+   if (ret)
+   goto err_get;
 
-   ret = tracing_open_generic(inode, filp);
-   if (ret < 0) {
-   trace_array_put(tr);
-   put_system(dir);
-   }
+   filp->private_data = dir;
+   return 0;
 
+err_get:
+   put_system(dir);
return ret;
 }
 
@@ -1106,28 +1107,29 @@ static int system_tr_open(struct inode *inode, struct 
file *filp)
 {
struct ftrace_subsystem_dir *dir;
struct trace_array *tr = inode->i_private;
-   int ret;
+   int ret = -ENODEV;
 
-   if (trace_array_get(tr) < 0)
-   return -ENODEV;
+   if (tracing_is_disabled())
+   return ret;
+
+   ret = trace_array_get(tr);
+   if (ret)
+   return ret;
 
/* Make a temporary dir that has no system but points to tr */
dir = kzalloc(sizeof(*dir), GFP_KERNEL);
if (!dir) {
-   trace_array_put(tr);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_dir;
}
 
dir->tr = tr;
 
-   ret = tracing_open_generic(inode, filp);
-   if (ret < 0) {
-   trace_array_put(tr);
-   kfree(dir);
-   }
-
filp->private_data = dir;
+   return 0;
 
+err_dir:
+   trace_array_put(tr);
return ret;
 }
 
-- 
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/

[PATCH 1/2] tracing: creates 'tracing_is_disabled()'

[Geyslan G. Bem]

This patch creates the function 'tracing_is_disabled ", which
can be used outside trace.c.

Signed-off-by: Geyslan G. Bem 
---
 kernel/trace/trace.c | 5 +
 kernel/trace/trace.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..a120a73 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2964,6 +2964,11 @@ int tracing_open_generic(struct inode *inode, struct 
file *filp)
return 0;
 }
 
+inline bool tracing_is_disabled(void)
+{
+   return (tracing_disabled) ? true: false;
+}
+
 /*
  * Open and update trace_array ref count.
  * Must have the current trace_array passed to it.
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 10c86fb..5deaa3b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -514,6 +514,7 @@ void tracing_reset_online_cpus(struct trace_buffer *buf);
 void tracing_reset_current(int cpu);
 void tracing_reset_all_online_cpus(void);
 int tracing_open_generic(struct inode *inode, struct file *filp);
+bool tracing_is_disabled(void);
 struct dentry *trace_create_file(const char *name,
 umode_t mode,
 struct dentry *parent,
-- 
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 v3 4/9] ACPI, x86: Extended error log driver for x86 platform

[Luck, Tony]

> Hmm, that's a good question you raise: but the more important question
> is, do you guys - Gong and Tony - want to replace the logging we're
> already doing, i.e. mce_log() with extlog or not.

Long term ... I'd be happy to see mce_log() go away.  But we need to have
a robust, well tested replacement in place for some time before such a
move is up for discussion.

> Because if you want to replace the current logging you actually have to
> exit machine_check_poll() after having done mce_ext_err_print() so that
> the rest of the chain doesn't see the error.

Yes - double error reporting should be avoided.

> And, does mce_ext_err_print only report DRAM ECC errors or other error
> types too?

Our first platforms to implement this only do so for memory errors.  This
could change in the future (the UEFI appendix N error record has defined
sub-sections for lots of types of errors).

Currently EDAC hooked into the mce even notification chain provides a
return code to indicate whether it completely processed the error, or
whether to fall through to the rest of mce_log():

if (ret == NOTIFY_STOP)
return;

Having both EDAC and this new extended error log both registered on this
chain would probably not be helpful in most cases.  Not sure if we should
handle that with user education to not load both an EDAC and ext_log driver
or if there should be some enforcement.

> Btw, if we keep both, then we're going to have two tracepoints -
> trace_mce_record() in mce_log() and this one - issuing each a record for
> the same event. Which is not really what we want I'd say...

trace_mce_record() dumps the raw data from the machine check banks.
I think there may still be a case for having this.  Analysis tools that look at
this trace as well should be smart enough to connect the dots.

-Tony
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: [ 00/11] 3.4.67-stable review

[Guenter Roeck]

On Fri, Oct 18, 2013 at 12:53:29PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.67 release.
> There are 11 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Oct 20 19:50:39 UTC 2013.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.67-rc1.gz
> and the diffstat can be found below.
> 
Build results:
total: 103 pass: 89 skipped: 10 fail: 4

qemu tests all pass.

This matches the results seen with the previous 3.4 release, so everything
is as expected.

Details are available at http://server.roeck-us.net:8010/builders.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] net: dccp: Remove extern from function prototypes

[Joe Perches]

There are a mix of function prototypes with and without extern
in the kernel sources.  Standardize on not using extern for
function prototypes.

Function prototypes don't need to be written with extern.
extern is assumed by the compiler.  Its use is as unnecessary as
using auto to declare automatic/local variables in a block.

Signed-off-by: Joe Perches 
---
 net/dccp/ackvec.h   |  21 ++--
 net/dccp/ccid.h |  18 ++--
 net/dccp/ccids/lib/loss_interval.h  |   8 +-
 net/dccp/ccids/lib/packet_history.h |  25 +++--
 net/dccp/ccids/lib/tfrc.h   |  22 ++---
 net/dccp/dccp.h | 186 +---
 net/dccp/feat.h |  26 ++---
 7 files changed, 148 insertions(+), 158 deletions(-)

diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h
index a269aa7..3284bfa 100644
--- a/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -101,16 +101,16 @@ struct dccp_ackvec_record {
u8   avr_ack_nonce:1;
 };
 
-extern int dccp_ackvec_init(void);
-extern void dccp_ackvec_exit(void);
+int dccp_ackvec_init(void);
+void dccp_ackvec_exit(void);
 
-extern struct dccp_ackvec *dccp_ackvec_alloc(const gfp_t priority);
-extern void dccp_ackvec_free(struct dccp_ackvec *av);
+struct dccp_ackvec *dccp_ackvec_alloc(const gfp_t priority);
+void dccp_ackvec_free(struct dccp_ackvec *av);
 
-extern void dccp_ackvec_input(struct dccp_ackvec *av, struct sk_buff *skb);
-extern int  dccp_ackvec_update_records(struct dccp_ackvec *av, u64 seq, u8 
sum);
-extern void dccp_ackvec_clear_state(struct dccp_ackvec *av, const u64 ackno);
-extern u16  dccp_ackvec_buflen(const struct dccp_ackvec *av);
+void dccp_ackvec_input(struct dccp_ackvec *av, struct sk_buff *skb);
+int dccp_ackvec_update_records(struct dccp_ackvec *av, u64 seq, u8 sum);
+void dccp_ackvec_clear_state(struct dccp_ackvec *av, const u64 ackno);
+u16 dccp_ackvec_buflen(const struct dccp_ackvec *av);
 
 static inline bool dccp_ackvec_is_empty(const struct dccp_ackvec *av)
 {
@@ -133,7 +133,6 @@ struct dccp_ackvec_parsed {
struct list_head node;
 };
 
-extern int dccp_ackvec_parsed_add(struct list_head *head,
- u8 *vec, u8 len, u8 nonce);
-extern void dccp_ackvec_parsed_cleanup(struct list_head *parsed_chunks);
+int dccp_ackvec_parsed_add(struct list_head *head, u8 *vec, u8 len, u8 nonce);
+void dccp_ackvec_parsed_cleanup(struct list_head *parsed_chunks);
 #endif /* _ACKVEC_H */
diff --git a/net/dccp/ccid.h b/net/dccp/ccid.h
index fb85d37..6eb837a 100644
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -93,8 +93,8 @@ extern struct ccid_operations ccid2_ops;
 extern struct ccid_operations ccid3_ops;
 #endif
 
-extern int  ccid_initialize_builtins(void);
-extern void ccid_cleanup_builtins(void);
+int ccid_initialize_builtins(void);
+void ccid_cleanup_builtins(void);
 
 struct ccid {
struct ccid_operations *ccid_ops;
@@ -106,12 +106,12 @@ static inline void *ccid_priv(const struct ccid *ccid)
return (void *)ccid->ccid_priv;
 }
 
-extern bool ccid_support_check(u8 const *ccid_array, u8 array_len);
-extern int  ccid_get_builtin_ccids(u8 **ccid_array, u8 *array_len);
-extern int  ccid_getsockopt_builtin_ccids(struct sock *sk, int len,
- char __user *, int __user *);
+bool ccid_support_check(u8 const *ccid_array, u8 array_len);
+int ccid_get_builtin_ccids(u8 **ccid_array, u8 *array_len);
+int ccid_getsockopt_builtin_ccids(struct sock *sk, int len,
+ char __user *, int __user *);
 
-extern struct ccid *ccid_new(const u8 id, struct sock *sk, bool rx);
+struct ccid *ccid_new(const u8 id, struct sock *sk, bool rx);
 
 static inline int ccid_get_current_rx_ccid(struct dccp_sock *dp)
 {
@@ -131,8 +131,8 @@ static inline int ccid_get_current_tx_ccid(struct dccp_sock 
*dp)
return ccid->ccid_ops->ccid_id;
 }
 
-extern void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk);
-extern void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk);
+void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk);
+void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk);
 
 /*
  * Congestion control of queued data packets via CCID decision.
diff --git a/net/dccp/ccids/lib/loss_interval.h 
b/net/dccp/ccids/lib/loss_interval.h
index d1d2f53..57f631a 100644
--- a/net/dccp/ccids/lib/loss_interval.h
+++ b/net/dccp/ccids/lib/loss_interval.h
@@ -65,9 +65,9 @@ static inline u8 tfrc_lh_length(struct tfrc_loss_hist *lh)
 
 struct tfrc_rx_hist;
 
-extern int  tfrc_lh_interval_add(struct tfrc_loss_hist *, struct tfrc_rx_hist 
*,
-u32 (*first_li)(struct sock *), struct sock *);
-extern u8   tfrc_lh_update_i_mean(struct tfrc_loss_hist *lh, struct sk_buff *);
-extern void tfrc_lh_cleanup(struct tfrc_loss_hist *lh);
+int tfrc_lh_interval_add(struct tfrc_loss_hist *, struct tfrc_rx_hist *,
+u32 (*first_li)(struct sock *), struct sock *);

[PATCH 1/4] net: 8021q/bluetooth/bridge/can/ceph: Remove extern from function prototypes

[Joe Perches]

There are a mix of function prototypes with and without extern
in the kernel sources.  Standardize on not using extern for
function prototypes.

Function prototypes don't need to be written with extern.
extern is assumed by the compiler.  Its use is as unnecessary as
using auto to declare automatic/local variables in a block.

Signed-off-by: Joe Perches 
---
 net/8021q/vlan.h|  28 ++---
 net/bluetooth/hidp/hidp.h   |   4 +-
 net/bridge/br_private.h | 299 
 net/bridge/br_private_stp.h |  24 ++--
 net/can/af_can.h|   6 +-
 net/ceph/auth_none.h|   2 +-
 net/ceph/auth_x.h   |   2 +-
 net/ceph/crypto.h   |  48 ---
 8 files changed, 194 insertions(+), 219 deletions(-)

diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index ba5983f..a2caf00 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -196,12 +196,12 @@ static inline u32 vlan_get_ingress_priority(struct 
net_device *dev,
 }
 
 #ifdef CONFIG_VLAN_8021Q_GVRP
-extern int vlan_gvrp_request_join(const struct net_device *dev);
-extern void vlan_gvrp_request_leave(const struct net_device *dev);
-extern int vlan_gvrp_init_applicant(struct net_device *dev);
-extern void vlan_gvrp_uninit_applicant(struct net_device *dev);
-extern int vlan_gvrp_init(void);
-extern void vlan_gvrp_uninit(void);
+int vlan_gvrp_request_join(const struct net_device *dev);
+void vlan_gvrp_request_leave(const struct net_device *dev);
+int vlan_gvrp_init_applicant(struct net_device *dev);
+void vlan_gvrp_uninit_applicant(struct net_device *dev);
+int vlan_gvrp_init(void);
+void vlan_gvrp_uninit(void);
 #else
 static inline int vlan_gvrp_request_join(const struct net_device *dev) { 
return 0; }
 static inline void vlan_gvrp_request_leave(const struct net_device *dev) {}
@@ -212,12 +212,12 @@ static inline void vlan_gvrp_uninit(void) {}
 #endif
 
 #ifdef CONFIG_VLAN_8021Q_MVRP
-extern int vlan_mvrp_request_join(const struct net_device *dev);
-extern void vlan_mvrp_request_leave(const struct net_device *dev);
-extern int vlan_mvrp_init_applicant(struct net_device *dev);
-extern void vlan_mvrp_uninit_applicant(struct net_device *dev);
-extern int vlan_mvrp_init(void);
-extern void vlan_mvrp_uninit(void);
+int vlan_mvrp_request_join(const struct net_device *dev);
+void vlan_mvrp_request_leave(const struct net_device *dev);
+int vlan_mvrp_init_applicant(struct net_device *dev);
+void vlan_mvrp_uninit_applicant(struct net_device *dev);
+int vlan_mvrp_init(void);
+void vlan_mvrp_uninit(void);
 #else
 static inline int vlan_mvrp_request_join(const struct net_device *dev) { 
return 0; }
 static inline void vlan_mvrp_request_leave(const struct net_device *dev) {}
@@ -229,8 +229,8 @@ static inline void vlan_mvrp_uninit(void) {}
 
 extern const char vlan_fullname[];
 extern const char vlan_version[];
-extern int vlan_netlink_init(void);
-extern void vlan_netlink_fini(void);
+int vlan_netlink_init(void);
+void vlan_netlink_fini(void);
 
 extern struct rtnl_link_ops vlan_link_ops;
 
diff --git a/net/bluetooth/hidp/hidp.h b/net/bluetooth/hidp/hidp.h
index 9e6cc35..ab52414 100644
--- a/net/bluetooth/hidp/hidp.h
+++ b/net/bluetooth/hidp/hidp.h
@@ -182,7 +182,7 @@ struct hidp_session {
 };
 
 /* HIDP init defines */
-extern int __init hidp_init_sockets(void);
-extern void __exit hidp_cleanup_sockets(void);
+int __init hidp_init_sockets(void);
+void __exit hidp_cleanup_sockets(void);
 
 #endif /* __HIDP_H */
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index efb57d9..767c4da 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -344,10 +344,9 @@ static inline int br_is_root_bridge(const struct 
net_bridge *br)
 }
 
 /* br_device.c */
-extern void br_dev_setup(struct net_device *dev);
-extern void br_dev_delete(struct net_device *dev, struct list_head *list);
-extern netdev_tx_t br_dev_xmit(struct sk_buff *skb,
-  struct net_device *dev);
+void br_dev_setup(struct net_device *dev);
+void br_dev_delete(struct net_device *dev, struct list_head *list);
+netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev);
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static inline void br_netpoll_send_skb(const struct net_bridge_port *p,
   struct sk_buff *skb)
@@ -358,8 +357,8 @@ static inline void br_netpoll_send_skb(const struct 
net_bridge_port *p,
netpoll_send_skb(np, skb);
 }
 
-extern int br_netpoll_enable(struct net_bridge_port *p, gfp_t gfp);
-extern void br_netpoll_disable(struct net_bridge_port *p);
+int br_netpoll_enable(struct net_bridge_port *p, gfp_t gfp);
+void br_netpoll_disable(struct net_bridge_port *p);
 #else
 static inline void br_netpoll_send_skb(const struct net_bridge_port *p,
   struct sk_buff *skb)
@@ -377,116 +376,99 @@ static inline void br_netpoll_disable(struct 
net_bridge_port *p)
 #endif
 
 /* br_fdb.c */
-extern int br_fdb_init(void);

[PATCH 4/4] net: misc: Remove extern from function prototypes

[Joe Perches]

There are a mix of function prototypes with and without extern
in the kernel sources.  Standardize on not using extern for
function prototypes.

Function prototypes don't need to be written with extern.
extern is assumed by the compiler.  Its use is as unnecessary as
using auto to declare automatic/local variables in a block.

Signed-off-by: Joe Perches 
---
 net/irda/irnet/irnet.h   |  15 ++---
 net/l2tp/l2tp_core.h |  57 +---
 net/mac80211/rate.h  |  12 ++--
 net/netfilter/nf_internals.h |  28 
 net/rds/rds.h|   2 +-
 net/rxrpc/ar-internal.h  | 150 ---
 net/tipc/core.h  |  28 
 net/wimax/wimax-internal.h   |  18 +++---
 net/wireless/core.h  |   6 +-
 net/wireless/sysfs.h |   4 +-
 net/xfrm/xfrm_hash.h |   4 +-
 11 files changed, 157 insertions(+), 167 deletions(-)

diff --git a/net/irda/irnet/irnet.h b/net/irda/irnet/irnet.h
index 564eb0b..8d65bb9 100644
--- a/net/irda/irnet/irnet.h
+++ b/net/irda/irnet/irnet.h
@@ -509,16 +509,11 @@ typedef struct irnet_ctrl_channel
  */
 
 /* -- IRDA PART -- */
-extern int
-   irda_irnet_create(irnet_socket *);  /* Initialise a IrNET socket */
-extern int
-   irda_irnet_connect(irnet_socket *); /* Try to connect over IrDA */
-extern void
-   irda_irnet_destroy(irnet_socket *); /* Teardown  a IrNET socket */
-extern int
-   irda_irnet_init(void);  /* Initialise IrDA part of IrNET */
-extern void
-   irda_irnet_cleanup(void);   /* Teardown IrDA part of IrNET */
+int irda_irnet_create(irnet_socket *); /* Initialise an IrNET socket */
+int irda_irnet_connect(irnet_socket *);/* Try to connect over IrDA */
+void irda_irnet_destroy(irnet_socket *);   /* Teardown an IrNET socket */
+int irda_irnet_init(void); /* Initialise IrDA part of IrNET */
+void irda_irnet_cleanup(void); /* Teardown IrDA part of IrNET */
 
 / VARIABLES /
 
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index 6f251cb..1ee9f69 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -238,29 +238,40 @@ out:
return tunnel;
 }
 
-extern struct sock *l2tp_tunnel_sock_lookup(struct l2tp_tunnel *tunnel);
-extern void l2tp_tunnel_sock_put(struct sock *sk);
-extern struct l2tp_session *l2tp_session_find(struct net *net, struct 
l2tp_tunnel *tunnel, u32 session_id);
-extern struct l2tp_session *l2tp_session_find_nth(struct l2tp_tunnel *tunnel, 
int nth);
-extern struct l2tp_session *l2tp_session_find_by_ifname(struct net *net, char 
*ifname);
-extern struct l2tp_tunnel *l2tp_tunnel_find(struct net *net, u32 tunnel_id);
-extern struct l2tp_tunnel *l2tp_tunnel_find_nth(struct net *net, int nth);
-
-extern int l2tp_tunnel_create(struct net *net, int fd, int version, u32 
tunnel_id, u32 peer_tunnel_id, struct l2tp_tunnel_cfg *cfg, struct l2tp_tunnel 
**tunnelp);
-extern void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel);
-extern int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel);
-extern struct l2tp_session *l2tp_session_create(int priv_size, struct 
l2tp_tunnel *tunnel, u32 session_id, u32 peer_session_id, struct 
l2tp_session_cfg *cfg);
-extern void __l2tp_session_unhash(struct l2tp_session *session);
-extern int l2tp_session_delete(struct l2tp_session *session);
-extern void l2tp_session_free(struct l2tp_session *session);
-extern void l2tp_recv_common(struct l2tp_session *session, struct sk_buff 
*skb, unsigned char *ptr, unsigned char *optr, u16 hdrflags, int length, int 
(*payload_hook)(struct sk_buff *skb));
-extern int l2tp_session_queue_purge(struct l2tp_session *session);
-extern int l2tp_udp_encap_recv(struct sock *sk, struct sk_buff *skb);
-
-extern int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, 
int hdr_len);
-
-extern int l2tp_nl_register_ops(enum l2tp_pwtype pw_type, const struct 
l2tp_nl_cmd_ops *ops);
-extern void l2tp_nl_unregister_ops(enum l2tp_pwtype pw_type);
+struct sock *l2tp_tunnel_sock_lookup(struct l2tp_tunnel *tunnel);
+void l2tp_tunnel_sock_put(struct sock *sk);
+struct l2tp_session *l2tp_session_find(struct net *net,
+  struct l2tp_tunnel *tunnel,
+  u32 session_id);
+struct l2tp_session *l2tp_session_find_nth(struct l2tp_tunnel *tunnel, int 
nth);
+struct l2tp_session *l2tp_session_find_by_ifname(struct net *net, char 
*ifname);
+struct l2tp_tunnel *l2tp_tunnel_find(struct net *net, u32 tunnel_id);
+struct l2tp_tunnel *l2tp_tunnel_find_nth(struct net *net, int nth);
+
+int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id,
+  u32 peer_tunnel_id, struct l2tp_tunnel_cfg *cfg,
+  struct l2tp_tunnel **tunnelp);
+void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel);
+int l2tp_tunnel_delete(struct 

[PATCH 3/4] net: ipv4/ipv6: Remove extern from function prototypes

[Joe Perches]

There are a mix of function prototypes with and without extern
in the kernel sources.  Standardize on not using extern for
function prototypes.

Function prototypes don't need to be written with extern.
extern is assumed by the compiler.  Its use is as unnecessary as
using auto to declare automatic/local variables in a block.

Signed-off-by: Joe Perches 
---
 net/ipv4/fib_lookup.h | 26 +++---
 net/ipv4/tcp_vegas.h  | 10 +-
 net/ipv4/udp_impl.h   | 36 ++--
 net/ipv6/udp_impl.h   | 41 -
 4 files changed, 54 insertions(+), 59 deletions(-)

diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h
index 50cfb3e..388d113 100644
--- a/net/ipv4/fib_lookup.h
+++ b/net/ipv4/fib_lookup.h
@@ -24,21 +24,17 @@ static inline void fib_alias_accessed(struct fib_alias *fa)
 }
 
 /* Exported by fib_semantics.c */
-extern void fib_release_info(struct fib_info *);
-extern struct fib_info *fib_create_info(struct fib_config *cfg);
-extern int fib_nh_match(struct fib_config *cfg, struct fib_info *fi);
-extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
-u32 tb_id, u8 type, __be32 dst,
-int dst_len, u8 tos, struct fib_info *fi,
-unsigned int);
-extern void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, const struct nl_info *info,
- unsigned int nlm_flags);
-extern struct fib_alias *fib_find_alias(struct list_head *fah,
-   u8 tos, u32 prio);
-extern int fib_detect_death(struct fib_info *fi, int order,
-   struct fib_info **last_resort,
-   int *last_idx, int dflt);
+void fib_release_info(struct fib_info *);
+struct fib_info *fib_create_info(struct fib_config *cfg);
+int fib_nh_match(struct fib_config *cfg, struct fib_info *fi);
+int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event, u32 tb_id,
+ u8 type, __be32 dst, int dst_len, u8 tos, struct fib_info *fi,
+ unsigned int);
+void rtmsg_fib(int event, __be32 key, struct fib_alias *fa, int dst_len,
+  u32 tb_id, const struct nl_info *info, unsigned int nlm_flags);
+struct fib_alias *fib_find_alias(struct list_head *fah, u8 tos, u32 prio);
+int fib_detect_death(struct fib_info *fi, int order,
+struct fib_info **last_resort, int *last_idx, int dflt);
 
 static inline void fib_result_assign(struct fib_result *res,
 struct fib_info *fi)
diff --git a/net/ipv4/tcp_vegas.h b/net/ipv4/tcp_vegas.h
index 6c0eea2..0531b99 100644
--- a/net/ipv4/tcp_vegas.h
+++ b/net/ipv4/tcp_vegas.h
@@ -15,10 +15,10 @@ struct vegas {
u32 baseRTT;/* the min of all Vegas RTT measurements seen 
(in usec) */
 };
 
-extern void tcp_vegas_init(struct sock *sk);
-extern void tcp_vegas_state(struct sock *sk, u8 ca_state);
-extern void tcp_vegas_pkts_acked(struct sock *sk, u32 cnt, s32 rtt_us);
-extern void tcp_vegas_cwnd_event(struct sock *sk, enum tcp_ca_event event);
-extern void tcp_vegas_get_info(struct sock *sk, u32 ext, struct sk_buff *skb);
+void tcp_vegas_init(struct sock *sk);
+void tcp_vegas_state(struct sock *sk, u8 ca_state);
+void tcp_vegas_pkts_acked(struct sock *sk, u32 cnt, s32 rtt_us);
+void tcp_vegas_cwnd_event(struct sock *sk, enum tcp_ca_event event);
+void tcp_vegas_get_info(struct sock *sk, u32 ext, struct sk_buff *skb);
 
 #endif /* __TCP_VEGAS_H */
diff --git a/net/ipv4/udp_impl.h b/net/ipv4/udp_impl.h
index 5a681e2..f3c2789 100644
--- a/net/ipv4/udp_impl.h
+++ b/net/ipv4/udp_impl.h
@@ -5,30 +5,30 @@
 #include 
 #include 
 
-extern int __udp4_lib_rcv(struct sk_buff *, struct udp_table *, int );
-extern void__udp4_lib_err(struct sk_buff *, u32, struct udp_table *);
+int __udp4_lib_rcv(struct sk_buff *, struct udp_table *, int);
+void __udp4_lib_err(struct sk_buff *, u32, struct udp_table *);
 
-extern int udp_v4_get_port(struct sock *sk, unsigned short snum);
+int udp_v4_get_port(struct sock *sk, unsigned short snum);
 
-extern int udp_setsockopt(struct sock *sk, int level, int optname,
-  char __user *optval, unsigned int optlen);
-extern int udp_getsockopt(struct sock *sk, int level, int optname,
-  char __user *optval, int __user *optlen);
+int udp_setsockopt(struct sock *sk, int level, int optname,
+  char __user *optval, unsigned int optlen);
+int udp_getsockopt(struct sock *sk, int level, int optname,
+  char __user *optval, int __user *optlen);
 
 #ifdef CONFIG_COMPAT
-extern int compat_udp_setsockopt(struct sock *sk, int level, int optname,
- char __user *optval, unsigned int optlen);
-extern int compat_udp_getsockopt(struct sock *sk, int level, int optname,

[PATCH 0/4] net: Remove extern from function prototypes

[Joe Perches]

Remove the remainder of extern function prototypes from net/.../*.h files.

Joe Perches (4):
  net: 8021q/bluetooth/bridge/can/ceph: Remove extern from function prototypes
  net: dccp: Remove extern from function prototypes
  net: ipv4/ipv6: Remove extern from function prototypes
  net: misc: Remove extern from function prototypes

 net/8021q/vlan.h|  28 ++--
 net/bluetooth/hidp/hidp.h   |   4 +-
 net/bridge/br_private.h | 299 +---
 net/bridge/br_private_stp.h |  24 +--
 net/can/af_can.h|   6 +-
 net/ceph/auth_none.h|   2 +-
 net/ceph/auth_x.h   |   2 +-
 net/ceph/crypto.h   |  48 +++---
 net/dccp/ackvec.h   |  21 ++-
 net/dccp/ccid.h |  18 +--
 net/dccp/ccids/lib/loss_interval.h  |   8 +-
 net/dccp/ccids/lib/packet_history.h |  25 ++-
 net/dccp/ccids/lib/tfrc.h   |  22 +--
 net/dccp/dccp.h | 186 +++---
 net/dccp/feat.h |  26 ++--
 net/ipv4/fib_lookup.h   |  26 ++--
 net/ipv4/tcp_vegas.h|  10 +-
 net/ipv4/udp_impl.h |  36 ++---
 net/ipv6/udp_impl.h |  41 +++--
 net/irda/irnet/irnet.h  |  15 +-
 net/l2tp/l2tp_core.h|  57 ---
 net/mac80211/rate.h |  12 +-
 net/netfilter/nf_internals.h|  28 ++--
 net/rds/rds.h   |   2 +-
 net/rxrpc/ar-internal.h | 150 +-
 net/tipc/core.h |  28 ++--
 net/wimax/wimax-internal.h  |  18 +--
 net/wireless/core.h |   6 +-
 net/wireless/sysfs.h|   4 +-
 net/xfrm/xfrm_hash.h|   4 +-
 30 files changed, 553 insertions(+), 603 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] udf: fix for pathetic mount times in case of invalid file system

[Jan Kara]

On Fri 18-10-13 20:07:44, Péter András Felvégi wrote:
> From: Peter A. Felvegi 
> 
> The UDF driver was not strict enough about checking the IDs in the
> VSDs when mounting, which resulted in reading through all the sectors
> of the block device in some unfortunate cases. Eg, trying to mount my
> uninitialized 200G SSD partition (all 0xFF bytes) took ~350 minutes to
> fail, because the code expected some of the valid IDs or a zero byte.
> During this, the mount couldn't be killed, sync from the cmdline
> blocked, and the machine froze into the shutdown. Valid filesystems
> (extX, btrfs, ntfs) were rejected by the mere accident of having a
> zero byte at just the right place in some of their sectors, close
> enough to the beginning not to generate excess I/O. The fix adds a
> hard limit on the VSD sector offset, adds the two missing VSD IDs, and
> stops scanning when encountering an invalid ID. Also replaced the
> magic number 32768 with a more meaningful #define, and supressed the
> bogus message about failing to read the first sector if no UDF fs was
> detected.
  Thanks. I've merged the patch into my tree.

Honza
> 
> Signed-off-by: Peter A. Felvegi 
> ---
> The fix was developed for 3.9.4, and applies to 3.12-rc3, too.
> 
> patch v2: edited the code so that added/changed lines are not longer than
> 80 chars. sending the patch as an attachment, as gmail messes it up
> otherwise.


-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] floppy: Correct documentation of driver options when used as a module.

[Ben Harris]

From: Ben Harris 

The options have to be passed space-separated and prefixed by "floppy=", 
rather than separately and unprefixed.


This fixes .

Signed-off-by: Ben Harris 
---
This patch is against Linux 3.12-rc5.

--- linux-3.12-rc5/Documentation/blockdev/floppy.txt.orig   2013-10-13 
23:41:28.0 +0100
+++ linux-3.12-rc5/Documentation/blockdev/floppy.txt2013-10-18 
21:03:27.0 +0100
@@ -39,15 +39,15 @@ Module configuration options
 

  If you use the floppy driver as a module, use the following syntax:
-modprobe floppy 
+modprobe floppy floppy=""

 Example:
- modprobe floppy omnibook messages
+ modprobe floppy floppy="omnibook messages"

  If you need certain options enabled every time you load the floppy driver,
 you can put:

- options floppy omnibook messages
+ options floppy floppy="omnibook messages"

 in a configuration file in /etc/modprobe.d/.

--
Ben Harris, University of Cambridge Computing Service.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v3 0/9] Introduce support to lazy initialize mostly static keys

[David Miller]

From: Hannes Frederic Sowa 
Date: Thu, 17 Oct 2013 07:31:54 +0200

> This series implements support for delaying the initialization of secret
> keys, e.g. used for hashing, for as long as possible. This functionality
> is implemented by a new macro, net_get_random_bytes.
> 
> I already used it to protect the socket hashes, the syncookie secret
> (most important) and the tcp_fastopen secrets.

I generally have no problem with this series and like how it improves the
secret being input on the ipv6 side.

Please address the commit message feedback and respin this series.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH v2 5/6] ARM: dts: Specify clocks for timer on bcm11351

[Tim Kryger]

On Thu, Oct 17, 2013 at 7:06 AM, Mark Rutland  wrote:
>> diff --git a/arch/arm/boot/dts/bcm11351.dtsi 
>> b/arch/arm/boot/dts/bcm11351.dtsi
>> index 193659c..39c1395 100644
>> --- a/arch/arm/boot/dts/bcm11351.dtsi
>> +++ b/arch/arm/boot/dts/bcm11351.dtsi
>> @@ -95,7 +95,7 @@
>>   compatible = "brcm,kona-timer";
>>   reg = <0x35006000 0x1000>;
>>   interrupts = ;
>> - clock-frequency = <32768>;
>> + clocks = <_timer_clk>;
>
> This should probably be after the code change that enables support for a
> clocks property.
>
> Thanks,
> Mark.

This is already the case.

The driver change is patch 4 and this dts change is patch 5 of the series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/