Re: [PATCH 1/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag

[Paolo Bonzini]

Il 24/08/2013 22:14, Yann Droneaud ha scritto:
> KVM uses anon_inode_get() to allocate file descriptors as part
> of some of its ioctls. But those ioctls are lacking a flag argument
> allowing userspace to choose options for the newly opened file descriptor.
> 
> In such case it's advised to use O_CLOEXEC by default so that
> userspace is allowed to choose, without race, if the file descriptor
> is going to be inherited across exec().
> 
> This patch set O_CLOEXEC flag on all file descriptors created
> with anon_inode_getfd() to not leak file descriptors across exec().
> 
> Signed-off-by: Yann Droneaud 
> Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com

Reviewed-by: Paolo Bonzini 

> ---
>  virt/kvm/kvm_main.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89f74d1..d65cc0c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1896,7 +1896,7 @@ static struct file_operations kvm_vcpu_fops = {
>   */
>  static int create_vcpu_fd(struct kvm_vcpu *vcpu)
>  {
> - return anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, O_RDWR);
> + return anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, O_RDWR | 
> O_CLOEXEC);
>  }
>  
>  /*
> @@ -2306,7 +2306,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
>   return ret;
>   }
>  
> - ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR);
> + ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | 
> O_CLOEXEC);
>   if (ret < 0) {
>   ops->destroy(dev);
>   return ret;
> @@ -2590,7 +2590,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
>   return r;
>   }
>  #endif
> - r = anon_inode_getfd("kvm-vm", &kvm_vm_fops, kvm, O_RDWR);
> + r = anon_inode_getfd("kvm-vm", &kvm_vm_fops, kvm, O_RDWR | O_CLOEXEC);
>   if (r < 0)
>   kvm_put_kvm(kvm);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: apple: Add another device ID for the mid-2013 Macbook Air

[Henrik Rydberg]

On Sat, Aug 24, 2013 at 04:26:30PM -0700, Dmitry Torokhov wrote:
> Hi Ian,
> 
> On Sun, Aug 25, 2013 at 12:17:52AM +1000, Ian Munsie wrote:
> > This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
> > lsusb:
> > 
> > Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
> > 
> > Since IDs already exist for this generation Macbook air as WELLSPRING8,
> > name this one WELLSPRING8A. This only adds an ANSI version since it's
> > device ID is only one less than the existing WELLSPRING8 IDs.
> > 
> > Signed-off-by: Ian Munsie 
> 
> Thank you for the patch!
> 
> Jiri, can I take it through my tree for 3.11?

Wait, we probably want to resolve the USB ID inconsistency first. :-)

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

Re: /proc/pid/fd && anon_inode_fops

[Willy Tarreau]

On Sun, Aug 25, 2013 at 06:23:17AM +0100, Al Viro wrote:
> On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
> 
> > I doubt it. It seems to me that most such entries are implemented
> > for completeness while most valid uses only concern /proc/self/fd.
> > Maybe if we had an option so that only /proc/self/fd would actually
> > allow to access the fds while all /proc/pid/fd would only show what
> > they map to, it would be a good step forward.
> 
> How?  The fundamental problem is not visibility of that stuff, it's
> new opened file for the same object (Linux behaviour) vs. new descriptor
> refering to the same opened file (*BSD and friends).  We can't get
> anon_... sanely reopened in the former semantics and they are very
> visibly different for regular files, so switching to *BSD one is not
> feasible - too high odds of userland breakage.  The difference in
> semantics, of course, is that on Linux opening /dev/stdin gives you
> a descriptor with independent current IO position; on *BSD you get
> a descriptor sharing the current IO position with stdin.  IOW, it's
> independent open() of the same file vs. dup().
> 
> We are really stuck with the current semantics here - switching to
> *BSD one would not only mean serious surgery on descriptor handling
> (it's one of the wartier areas in *BSD VFS, in large part because
> of magic-open-really-a-dup kludges they have to do), it would change
> a long-standing userland API that had been there for nearly 20 years
> _and_ one that tends to be used in corner cases of hell knows how many
> scripts.

Thanks for explaining Al, that really helps me understand. However
there's still a difference between /proc/pid called from the process
itself (=/proc/self) and called from other processes that seems to
suit the situation :

  willy@eeepc:~$ ls -la /tmp/bash 
  -r-x--x--x 1 root users 916852 2013-08-25 08:19 /tmp/bash*
  willy@eeepc:~$ exec /tmp/bash -i
  willy@eeepc:~$ echo $$
  22678
  willy@eeepc:~$ ls -la /proc/22678/fd
  ls: cannot open directory /proc/22678/fd: Permission denied
  willy@eeepc:~$ ls -la /proc/22678/exe 
  ls: cannot read symbolic link /proc/22678/exe: Permission denied
  willy@eeepc:~$ cat /proc/22678/fd/0 
  cat: /proc/22678/fd/0: Permission denied

but :
  willy@eeepc:~$ read < /proc/22678/fd/0 
  azerazerazer
  willy@eeepc:~$ echo $REPLY
  azerazerazer

strace clearly shows that the process was allowed to inspect itself
and the other ones were not :

  willy@eeepc:~$ strace -p 22678
  open("/proc/22678/fd/0", O_RDONLY|O_LARGEFILE) = 3

  willy@eeepc:~$ strace cat /proc/22678/fd/0 
  open("/proc/22678/fd/0", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)

It looks like this difference was introduced by this patch (which also fixes
this issue we've been having for a very long time on 2.4 and early 2.6) :

8948e11 Allow access to /proc/$PID/fd after setuid()

Thus I'm wondering if something like this could help, the idea would be
that a with the appropriate mount option, a task could only look at its
own descriptors unless it's running with privileges :

static int proc_fd_permission(struct inode *inode, int mask,
  struct nameidata *nd)
{
   if (task_pid(current) == proc_pid(inode))
 return 0;
   if (capable(CAP_DAC_OVERRIDE))
 return 0;
   if (proc_mounted_with_strict_option)
 return -EACCES;
   return generic_permission(inode, mask, NULL);
}

Thus it would not change the default behaviour except for people who would
mount /proc with a special option.

Thanks,
Willy

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

Re: [PATCH v4 2/5] mmc: atmel-mci: prepare clk before calling enable

[boris brezillon]

Hello Chris,

On 25/08/2013 05:18, Chris Ball wrote:

Hi,

On Thu, Jul 18 2013, Boris BREZILLON wrote:

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON 
Acked-by: Ludovic Desroches 

Okay, pushed to mmc-next for 3.12.


Thanks.



Boris, you got feedback from Thomas Petazzoni and Russell King, but
you didn't CC either of them on the patch v4


I didn't knew I had to add the reviewers of a patch in the cc list
of the future versions. I'll do it next time.


, and you didn't write a
changelog explaining the differences between patches v3 and v4 --
please do both of those next time.


The changelog is in the cover letter ("Changes since v3").
But I didn't send you this cover letter.


Also, it looks like the Ack from Ludovic happened away from the MMC
list, since I don't see a message from Ludovic on the thread here.
It would be better if the Ack happened somewhere I can see it.


The 'Acked-by: Ludovic Desroches ' was added
in the 2nd version of this patch series.
But I don't know if I should have kept it in this version since this 
patch has evolved.



Thanks for these feebacks, I'm still learning the good practices of the 
kernel

submission process.
I'll check these points next time.

Best Regards,

Boris

Thanks,

- Chris.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[Guenter Roeck]

On 08/20/2013 09:53 AM, Stephen Warren wrote:

On 08/20/2013 12:55 AM, George Cherian wrote:

Hi Stephen,

Thanks for your review.

On 8/20/2013 1:01 AM, Stephen Warren wrote:


On 08/16/2013 04:13 AM, George Cherian wrote:

Adding extcon driver for USB ID detection to dynamically
configure USB Host/Peripheral mode.
diff --git
a/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
b/Documentation/devicetree/bindings/extcon/extcon-dra7xx.txt
+EXTCON FOR DRA7xx
+
+Required Properties:

Please at lest explain what a DRA7xxx is, and the purpose of the HW
module this binding describes.


DRA7xx is the SoC name and the USB VID  detection is implemented via gpio's
Basically it does only ID detection via GPIO and there is no VBUS
detection in h/w.


If there's no SoC-specific HW, then the binding has nothing to do with
the SoC; it's entirely generic.


I am currently working on adding device tree support to the extcon-gpio driver.

Wonder if it would make sense to just use that driver. As far as I can see
the only missing part is support for multiple cables and cable naming through
device tree properties.

Any thoughts ? The patches are not yet clean enough to submit upstream,
but I could send them as RFC if there is interest.

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: /proc/pid/fd && anon_inode_fops

[Al Viro]

On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:

> I doubt it. It seems to me that most such entries are implemented
> for completeness while most valid uses only concern /proc/self/fd.
> Maybe if we had an option so that only /proc/self/fd would actually
> allow to access the fds while all /proc/pid/fd would only show what
> they map to, it would be a good step forward.

How?  The fundamental problem is not visibility of that stuff, it's
new opened file for the same object (Linux behaviour) vs. new descriptor
refering to the same opened file (*BSD and friends).  We can't get
anon_... sanely reopened in the former semantics and they are very
visibly different for regular files, so switching to *BSD one is not
feasible - too high odds of userland breakage.  The difference in
semantics, of course, is that on Linux opening /dev/stdin gives you
a descriptor with independent current IO position; on *BSD you get
a descriptor sharing the current IO position with stdin.  IOW, it's
independent open() of the same file vs. dup().

We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
(it's one of the wartier areas in *BSD VFS, in large part because
of magic-open-really-a-dup kludges they have to do), it would change
a long-standing userland API that had been there for nearly 20 years
_and_ one that tends to be used in corner cases of hell knows how many
scripts.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tps_init] BUG: unable to handle kernel paging request at 484970c9

[Fengguang Wu]

On Sat, Aug 24, 2013 at 09:09:39PM -0700, Greg KH wrote:
> On Sun, Aug 25, 2013 at 08:04:21AM +0800, Fengguang Wu wrote:
> > Greetings,
> > 
> > It seems the below patch discloses a bug in tps_init().
> > 
> > commit c817a67ecba7c3c2aaa104796d78f160af60920d
> > Author: Russell King 
> > Date:   Thu Jun 27 15:06:14 2013 +0100
> > 
> > kobject: delayed kobject release: help find buggy drivers
> > 
> > Implement debugging for kobject release functions.  kobjects are
> > reference counted, so the drop of the last reference to them is not
> > predictable. However, the common case is for the last reference to be
> > the kobject's removal from a subsystem, which results in the release
> > function being immediately called.
> > 
> > This can hide subtle bugs, which can occur when another thread holds a
> > reference to the kobject at the same time that a kobject is removed.
> > This results in the release method being delayed.
> > 
> > In order to make these kinds of problems more visible, the following
> > patch implements a delayed release; this has the effect that the
> > release function will be out of order with respect to the removal of
> > the kobject in the same manner that it would be if a reference was
> > being held.
> > 
> > This provides us with an easy way to allow driver writers to debug
> > their drivers and fix otherwise hidden problems.
> > 
> > Signed-off-by: Russell King 
> > Signed-off-by: Greg Kroah-Hartman 
> > 

> > Parent commit not clean. Look out for wrong bisect!
> > 
> > BUG: kernel boot crashed
> > 
> > /kernel/i386-randconfig-j1-08220808/7c42721fe0c58a848849b43ff558cf2fb86aa35a/dmesg-kvm-nhm4-6710-20130824125721-3.11.0-rc2-7-ge56341a-282

Sorry please ignore the above several lines.

> > [0.304827] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:530 
> > sysfs_add_one+0x89/0x9b()
> > [0.306316] sysfs: cannot create duplicate filename 
> > '/bus/i2c/drivers/tps65010'
> 
> Same as before, are you unloading and loading modules?  We have a fix
> for modules that cause problems when unloading with the config option
> above enabled.  But that shouldn't be this issue.

At least I didn't explicitly unloading modules. Judging from the
timestamp [0.304827], the user space has not started yet.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tps_init] BUG: unable to handle kernel paging request at 484970c9

[Greg Kroah-Hartman]

On Sun, Aug 25, 2013 at 08:04:21AM +0800, Fengguang Wu wrote:
> Greetings,
> 
> It seems the below patch discloses a bug in tps_init().
> 
> commit c817a67ecba7c3c2aaa104796d78f160af60920d
> Author: Russell King 
> Date:   Thu Jun 27 15:06:14 2013 +0100
> 
> kobject: delayed kobject release: help find buggy drivers
> 
> Implement debugging for kobject release functions.  kobjects are
> reference counted, so the drop of the last reference to them is not
> predictable. However, the common case is for the last reference to be
> the kobject's removal from a subsystem, which results in the release
> function being immediately called.
> 
> This can hide subtle bugs, which can occur when another thread holds a
> reference to the kobject at the same time that a kobject is removed.
> This results in the release method being delayed.
> 
> In order to make these kinds of problems more visible, the following
> patch implements a delayed release; this has the effect that the
> release function will be out of order with respect to the removal of
> the kobject in the same manner that it would be if a reference was
> being held.
> 
> This provides us with an easy way to allow driver writers to debug
> their drivers and fix otherwise hidden problems.
> 
> Signed-off-by: Russell King 
> Signed-off-by: Greg Kroah-Hartman 
> 
> 
> Parent commit not clean. Look out for wrong bisect!
> 
> BUG: kernel boot crashed
> 
> /kernel/i386-randconfig-j1-08220808/7c42721fe0c58a848849b43ff558cf2fb86aa35a/dmesg-kvm-nhm4-6710-20130824125721-3.11.0-rc2-7-ge56341a-282
> 
> [0.304827] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:530 
> sysfs_add_one+0x89/0x9b()
> [0.306316] sysfs: cannot create duplicate filename 
> '/bus/i2c/drivers/tps65010'

Same as before, are you unloading and loading modules?  We have a fix
for modules that cause problems when unloading with the config option
above enabled.  But that shouldn't be this issue.

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: [RFC PATCH v2 next]module: Fix mod->mkobj.kobj potentially freed too early

[Greg KH]

On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote:
> DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
> 
> After some investigation, it seems the reason is:
> The mod->mkobj.kobj(a01600d0 below) is freed together with mod
> itself by module_free(mod, mod->module_core) in free_module(). However,
> its children still hold references to it, as the delay caused by
> DEBUG_KOBJECT_RELEASE. So when the child('holders' below) tries to
> decrease the reference count to its parent in kobject_del(), BUG happens
> as it tries to access already freed memory.
> 
> v2: 
> Greg suggested to make the kobject as a pointer. But it seems a little
> hard to make kobj(kobject) embedded in mkobj(module_kobject) a pointer,
> as that seems to cause getting the mkobj from the kobj impossible --
> to_module_kobject() is used in several places to derive mkobj from its
> member kobj. 
> 
> So in this version, I made the whole mkobj(module_kobject) as a pointer
> in mod(module).
> 
> The mkobj is then allocated in mod_sysfs_init(), and freed in its member
> kobj's release function -- it seems that there is no mkobj usage after
> its kobj is released? 
> 
> [ 1844.175287] kobject: 'holders' (88007c1f1600): kobject_release, parent 
> a01600d0 (delayed)
> [ 1844.178991] kobject: 'notes' (8800370b2a00): kobject_release, parent 
> a01600d0 (delayed)
> [ 1845.180118] kobject: 'holders' (88007c1f1600): kobject_cleanup, parent 
> a01600d0
> [ 1845.182130] kobject: 'holders' (88007c1f1600): auto cleanup kobject_del
> [ 1845.184120] BUG: unable to handle kernel paging request at a01601d0
> [ 1845.185026] IP: [] kobject_put+0x11/0x60
> [ 1845.185026] PGD 1a13067 PUD 1a14063 PMD 7bd30067 PTE 0
> [ 1845.185026] Oops:  [#1] PREEMPT 
> [ 1845.185026] Modules linked in: xfs libcrc32c [last unloaded: 
> kprobe_example]
> [ 1845.185026] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G   O 
> 3.11.0-rc6-next-20130819+ #1
> [ 1845.185026] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> [ 1845.185026] Workqueue: events kobject_delayed_cleanup
> [ 1845.185026] task: 88007ca51f00 ti: 88007ca5c000 task.ti: 
> 88007ca5c000
> [ 1845.185026] RIP: 0010:[]  [] 
> kobject_put+0x11/0x60
> [ 1845.185026] RSP: 0018:88007ca5dd08  EFLAGS: 00010282
> [ 1845.185026] RAX: 2000 RBX: a01600d0 RCX: 
> 8177d638
> [ 1845.185026] RDX: 88007ca5dc18 RSI:  RDI: 
> a01600d0
> [ 1845.185026] RBP: 88007ca5dd18 R08: 824e9810 R09: 
> 
> [ 1845.185026] R10: 8800 R11: dead4ead0001 R12: 
> 81a95040
> [ 1845.185026] R13: 88007b27a960 R14: 88007c1f1600 R15: 
> 
> [ 1845.185026] FS:  () GS:81a23000() 
> knlGS:
> [ 1845.185026] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 1845.185026] CR2: a01601d0 CR3: 37207000 CR4: 
> 06b0
> [ 1845.185026] Stack:
> [ 1845.185026]  88007c1f1600 88007c1f1600 88007ca5dd38 
> 812cdb7e
> [ 1845.185026]   88007c1f1640 88007ca5dd68 
> 812cdbfe
> [ 1845.185026]  88007c974800 88007c1f1640 88007ff61a00 
> 
> [ 1845.185026] Call Trace:
> [ 1845.185026]  [] kobject_del+0x2e/0x40
> [ 1845.185026]  [] kobject_delayed_cleanup+0x6e/0x1d0
> [ 1845.185026]  [] process_one_work+0x1e5/0x670
> [ 1845.185026]  [] ? process_one_work+0x183/0x670
> [ 1845.185026]  [] worker_thread+0x113/0x370
> [ 1845.185026]  [] ? rescuer_thread+0x290/0x290
> [ 1845.185026]  [] kthread+0xda/0xe0
> [ 1845.185026]  [] ? _raw_spin_unlock_irq+0x30/0x60
> [ 1845.185026]  [] ? kthread_create_on_node+0x130/0x130
> [ 1845.185026]  [] ret_from_fork+0x7a/0xb0
> [ 1845.185026]  [] ? kthread_create_on_node+0x130/0x130
> [ 1845.185026] Code: 81 48 c7 c7 28 95 ad 81 31 c0 e8 9b da 01 00 e9 4f ff ff 
> ff 66 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 85 ff 74 1d  
> 87 00 01 00 00 01 74 1e 48 8d 7b 38 83 6b 38 01 0f 94 c0 84 
> [ 1845.185026] RIP  [] kobject_put+0x11/0x60
> [ 1845.185026]  RSP 
> [ 1845.185026] CR2: a01601d0
> [ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
> 
> Signed-off-by: Li Zhong 
> ---
>  drivers/base/core.c|  2 +-
>  drivers/base/module.c  |  4 ++--
>  include/linux/module.h |  2 +-
>  kernel/module.c| 37 +
>  kernel/params.c| 19 +--
>  5 files changed, 38 insertions(+), 26 deletions(-)

People are starting to hit these types of issues, and I'd like to take
this one out of the picture.

Rusty, any objection to me taking this through my driver-core tree,
where this new config option shows up?

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

Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)

[Al Viro]

On Fri, Aug 23, 2013 at 02:07:26AM +0100, Al Viro wrote:
> On Thu, Aug 22, 2013 at 01:54:15PM -0700, Linus Torvalds wrote:
> > On Thu, Aug 22, 2013 at 1:48 PM, Andy Lutomirski  
> > wrote:
> > >
> > > Sure.  But aren't they always last?
> > 
> > What do you mean? I'd say that the /proc lookup is always *innermost*.
> > Which means that it certainly cannot bail out, since there are many
> > levels of nesting outside of it.
> > 
> > > With the current code structure, trying to enforce some kind of
> > > security restriction in the middle of lookup seems really unpleasant.
> > 
> > If it's conditional (ie "linkat behaves differently from openat"), it
> > certainly means that we'd have to pass in that info in annoying ways.
> 
> Nope.  All we need to pass is one more LOOKUP_...  Add
>   if (unlikely(nd->last_type == LAST_BIND)) {
>   if ((nd->flags & LOOKUP_BLAH) && !may_flink(...)) {
>   terminate_walk(nd);
>   return -EINVAL;
>   }
>   }
> in the beginning of lookup_last() and pass LOOKUP_BLAH in flags when
> linkat() calls user_path_at().  That will affect *only* the terminal
> symlinks and cost nothing in all normal cases.  The same check can
> bloody well go into path_init() - take
> if (*name) {
> if (!can_lookup(dentry->d_inode)) {
> fdput(f);
> return -ENOTDIR;
> }
> }
> in there and slap
>   else {
>   if ((flags & LOOKUP_BLAH) && !may_flink(...)) {
> fdput(f);
>   return -EINVAL;
>   }
>   }
> after it.

OK, let me summarize these threads so far:
* restrictions for flink() are needed and they'd better be
consistent for AT_SYMLINK_FOLLOW + /proc//fd/ and simply
passing the descriptor as dfd.
* CAP_DAC_OVERRIDE is sufficient; so should be O_TMPFILE used
to open that sucker.
* lookup_last() is the natural place for catching the case
of following a trailing procfs symlink - it can be done very cheaply
there.

FWIW, I'm tempted to try the following trick:
* introduce FMODE_FLINK in file->f_mode; O_TMPFILE would set it,
unless O_EXCL is present.
* introduce LOOKUP_LINK, to be passed by sys_linkat() when
resolving the target.
* have path_init() called with empty pathname and LOOKUP_LINK in
flags do checks for FMODE_FLINK or CAP_DAC_OVERRIDE
* have ->proc_get_link() report whether the target is linkable
(either as bool * or by returning 1 instead of 0).  After the call of
->proc_get_link() check that and set nd->last_type to LAST_BIND_LINKABLE.
Note that *all* places looking at ->last_type treat LAST_BIND as "none
of the above" - we never compare with it, so splitting it in two wouldn't
break anything.
* have lookup_last() check if LOOKUP_LINK is present and ->last_type
is LAST_BIND; fail unless we have CAP_DAC_OVERRIDE.

AFAICS, it gets more or less sane behaviour; additionally, it makes possible
to introduce explicit "I want that descriptor to be suitable for flink()"
open(2) flag - that would require teaching do_last() about LOOKUP_LINK,
making it check for CAP_DAC_OVERRIDE if it sees LAST_BIND / LOOKUP_LINK,
same as lookup_last() above (we obviously want to avoid the possibility
to take a non-flinkable descriptor and use it to reopen the sucker in
flinkable way).

Alternatively we can revert "fs: Allow unprivileged linkat(..., AT_EMPTY_PATH)
aka flink" for the time being.  flink() is certainly an awful mess and I
seriously regret touching it ;-/

Comments?  Hell, maybe somebody even has printable ones - stranger things
have happened...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/5] mmc: atmel-mci: prepare clk before calling enable

[Chris Ball]

Hi,

On Thu, Jul 18 2013, Boris BREZILLON wrote:
> Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> avoid common clk framework warnings.
>
> Signed-off-by: Boris BREZILLON 
> Acked-by: Ludovic Desroches 

Okay, pushed to mmc-next for 3.12.

Boris, you got feedback from Thomas Petazzoni and Russell King, but
you didn't CC either of them on the patch v4, and you didn't write a
changelog explaining the differences between patches v3 and v4 --
please do both of those next time.

Also, it looks like the Ack from Ludovic happened away from the MMC
list, since I don't see a message from Ludovic on the thread here.
It would be better if the Ack happened somewhere I can see it.

Thanks,

- Chris.
-- 
Chris Ball  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: dw_mmc: Handle DW_MCI_QUIRK_IDMAC_DTO properly

[Chris Ball]

Hi,

On Wed, Jul 10 2013, Seungwon Jeon wrote:
> On Wed, July 10, 2013, Doug Anderson wrote:
>> In (1fb5f68 mmc: dw_mmc: Don't loop when handling an interrupt), the
>> code for handling DW_MCI_QUIRK_IDMAC_DTO became dead code.  Move it to
>> where it ought to live.
>> 
>> Found by code inspection and compile-tested only--I don't know of any
>> boards that need DW_MCI_QUIRK_IDMAC_DTO.
>> 
>> Signed-off-by: Doug Anderson 
>
> Acked-by: Seungwon Jeon 

Thanks, pushed to mmc-next for 3.12.

- Chris.
-- 
Chris Ball  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: omap_hsmmc: clear status flags before starting a new command

[Chris Ball]

Hi Balaji,

On Sat, Jun 29 2013, Francesco Lavra wrote:
> Commit 1f6b9fa40e76fffaaa0b3bd6a0bfdcf1cdc06efa consolidated writes to 
> the STAT register in one location, moving them from omap_hsmmc_do_irq() 
> to omap_hsmmc_irq(). This move has the unwanted side effect that the 
> controller status flags are potentially cleared after a new command has 
> been started as a consequence of reading the previous status flags. 
> This means that if the new command changes the status flags before the 
> IRQ routine returns, those flags may be cleared without handling the 
> event which asserted them, and thus missing the event.
> Move the writing of the STAT register back in omap_hsmmc_do_irq(), 
> before handling the status flags which generated the interrupt.
>
> Signed-off-by: Francesco Lavra 
> ---
>  drivers/mmc/host/omap_hsmmc.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index eccedc7..301cb7e 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1041,6 +1041,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
> *host, int status)
>   }
>   }
>  
> + OMAP_HSMMC_WRITE(host->base, STAT, status);
>   if (end_cmd || ((status & CC_EN) && host->cmd))
>   omap_hsmmc_cmd_done(host, host->cmd);
>   if ((end_trans || (status & TC_EN)) && host->mrq)
> @@ -1060,7 +1061,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
>   omap_hsmmc_do_irq(host, status);
>  
>   /* Flush posted write */
> - OMAP_HSMMC_WRITE(host->base, STAT, status);
>   status = OMAP_HSMMC_READ(host->base, STAT);
>   }

Please could you review this patch?  Thanks,

- Chris.
-- 
Chris Ball  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: pcf857x: Add OF support

[Laurent Pinchart]

Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.

Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/gpio/gpio-pcf857x.txt  | 71 ++
 drivers/gpio/gpio-pcf857x.c| 57 ++---
 2 files changed, 119 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt

Changes since v2

- Replace mention about interrupts software configuration in DT bindings
  documentation with an explanation of the hardware configuration.

diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt 
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000..d0a3af4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have "quasi-bidirectional" I/O pins that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per pin, which can't be read
+back. We can't actually know at initialization time whether a pin is configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up pin direction is
+thus to do it explicitly.
+
+Required Properties:
+
+  - compatible: should be one of the following.
+- "maxim,max7328": For the Maxim MAX7378
+- "maxim,max7329": For the Maxim MAX7329
+- "nxp,pca8574": For the NXP PCA8574
+- "nxp,pca8575": For the NXP PCA8575
+- "nxp,pca9670": For the NXP PCA9670
+- "nxp,pca9671": For the NXP PCA9671
+- "nxp,pca9672": For the NXP PCA9672
+- "nxp,pca9673": For the NXP PCA9673
+- "nxp,pca9674": For the NXP PCA9674
+- "nxp,pca9675": For the NXP PCA9675
+- "nxp,pcf8574": For the NXP PCF8574
+- "nxp,pcf8574a": For the NXP PCF8574A
+- "nxp,pcf8575": For the NXP PCF8575
+- "ti,tca9554": For the TI TCA9554
+
+  - reg: I2C slave address.
+
+  - gpio-controller: Marks the device node as a gpio controller.
+  - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+cell specifies GPIO flags, as defined in . Only 
the
+GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+Optional Properties:
+
+  - pins-initial-state: Bitmask that specifies the initial state of each pin.
+  When a bit is set to zero, the corresponding pin will be initialized to the
+  input (pulled-up) state. When the  bit is set to one, the pin will be
+  initialized the the low-level output state. If the property is not specified
+  all pins will be initialized to the input state.
+
+  The I/O expander can detect input state changes, and thus optionally act as
+  an interrupt controller. When the expander interrupt pin is connected all the
+  following properties must be set. For more information please see the
+  interrupt controller device tree bindings documentation available at
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+  - #interrupt-cells: Number of cells to encode an interrupt source, shall be 
2.
+  - interrupt-parent: phandle of the parent interrupt controller.
+  - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+   pcf8575: gpio@20 {
+   compatible = "nxp,pcf8575";
+   reg = <0x20>;
+   interrupt-parent = <&irqpin2>;
+   interrupts = <3 0>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 9e61bb0..474f8ce 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pcf857x_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+   { .compatible = "nxp,pcf8574", .data = (void *)8 },
+   { .compatible = "nxp,pcf8574a", .data = (void *)8 },
+   { .compatible = "nxp,pca8574", .data = (void *)8 },
+   { .compatible = "nxp,pca9670", .data = (void *)8 },
+   { .compatible = "nxp,pca9672", .data = (void *)8 },
+   { .compatible = "nxp,pca9674", .data = (void *)8 },
+   { .compatible = "nxp,pcf8575", .data = (void *)16 },
+   { .compatible = "nxp,pca8575", .data = (void *)16 },
+   { .compatible = "nxp,pca9671", .data = (void *)16 

Re: [PATCH v2 3/3] gpio: pcf857x: Add OF support

[Laurent Pinchart]

Hi Tomasz,

On Saturday 24 August 2013 16:13:11 Tomasz Figa wrote:
> On Saturday 24 of August 2013 02:54:07 Laurent Pinchart wrote:
> > On Saturday 24 August 2013 02:41:59 Tomasz Figa wrote:
> > > On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
> > > > Add DT bindings for the pcf857x-compatible chips and parse the
> > > > device tree node in the driver.
> > > > 
> > > > Signed-off-by: Laurent Pinchart
> > > >  ---
> > > > 
> > > >  .../devicetree/bindings/gpio/gpio-pcf857x.txt  | 71 +
> > > >  drivers/gpio/gpio-pcf857x.c| 57 ++---
> > > >  2 files changed, 119 insertions(+), 9 deletions(-)
> > > >  create mode 100644

[snip]

> > > > diff --git a/drivers/gpio/gpio-pcf857x.c
> > > > b/drivers/gpio/gpio-pcf857x.c
> > > > index 070e81f..50a90f1 100644
> > > > --- a/drivers/gpio/gpio-pcf857x.c
> > > > +++ b/drivers/gpio/gpio-pcf857x.c
> > 
> > [snip]
> > 
> > > > @@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] =
> > > > {
> > > > 
> > > >  };
> > > >  MODULE_DEVICE_TABLE(i2c, pcf857x_id);
> > > > 
> > > > +#ifdef CONFIG_OF
> > > > +static const struct of_device_id pcf857x_of_table[] = {
> > > > +   { .compatible = "nxp,pcf8574", .data = (void *)8 },
> > > > +   { .compatible = "nxp,pcf8574a", .data = (void *)8 },
> > > > +   { .compatible = "nxp,pca8574", .data = (void *)8 },
> > > > +   { .compatible = "nxp,pca9670", .data = (void *)8 },
> > > > +   { .compatible = "nxp,pca9672", .data = (void *)8 },
> > > > +   { .compatible = "nxp,pca9674", .data = (void *)8 },
> > > > +   { .compatible = "nxp,pcf8575", .data = (void *)16 },
> > > > +   { .compatible = "nxp,pca8575", .data = (void *)16 },
> > > > +   { .compatible = "nxp,pca9671", .data = (void *)16 },
> > > > +   { .compatible = "nxp,pca9673", .data = (void *)16 },
> > > > +   { .compatible = "nxp,pca9675", .data = (void *)16 },
> > > > +   { .compatible = "maxim,max7328", .data = (void *)8 },
> > > > +   { .compatible = "maxim,max7329", .data = (void *)8 },
> > > > +   { .compatible = "ti,tca9554", .data = (void *)8 },
> > > > +   { }
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, pcf857x_of_table);
> > > > +#endif
> > > > +
> > > > 
> > > >  /*
> > > >   * The pcf857x, pca857x, and pca967x chips only expose one read and
> > > >   * one write register.  Writing a "one" bit (to match the reset
> > > > @@ -257,14 +280,29 @@ fail:
> > > >  static int pcf857x_probe(struct i2c_client *client,
> > > >  const struct i2c_device_id *id)
> > > >  {
> > > > -   struct pcf857x_platform_data*pdata;
> > > > +   struct pcf857x_platform_data*pdata = 
> > > > client->dev.platform_data;
> > > > +   struct device_node  *np = client->dev.of_node;
 > > >  struct pcf857x  *gpio;
> > > > +   unsigned intn_latch = 0;
> > > > +   unsigned intngpio;
> > > > int status;
> > > > 
> > > > -   pdata = client->dev.platform_data;
> > > > -   if (!pdata) {
> > > > +#ifdef CONFIG_OF
> > > > +   if (np) {
> > > 
> > > Wouldn't if (IS_ENABLED(CONFIG_OF) && np) be sufficient here, without
> > > the #ifdef? You would have to move the match table out of the #ifdef
> > > in this case, though...
> > 
> > That's the exact reason why I've used #ifdef CONFIG_OF here, I didn't
> > want to add the overhead of the pcf857x_of_table when CONFIG_OF isn't
> > defined.
> 
> I'm not sure if I remember correctly, but I think there was something said
> in one of discussions some time ago, that we should be moving away from
> ifdef'ing such things, in favour of just having them compiled
> unconditionally.

There seems to be a general consensus to favor if (IS_ENABLED(CONFIG_OF)) 
instead of #ifdef CONFIG_OF when possible. I'm not sure what the opinion is 
regarding using conditional compilation to avoid compiling unnecessary data 
tables in. I would vote for using it (there's no need to bloat the kernel 
unnecessarily on non-OF platforms), but I'll conform to whatever is decided to 
be best.

> [Adding DT maintainers on Cc for more opinions.]

I'll resubmit the patch with the DT bindings documentation fixed, and will 
submit yet another version if I need to remove the #ifdef.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] timekeeping: handle epoch roll-over (2038) on 32-bit systems

[Michael Gilbert]

Thomas Gleixner writes:
> That time value should be 64bit, also people might argue, that we are
> creating a new issue for the year 2554, i.e 541 years from now. I
> don't think we need to worry about that really. We have to leave our
> grand-grand-grand..grandchildren (~20 generations from now) a few
> unsolved problems!

Or at the measly cost of 8 additional bytes, solve the problem well and good 
for the entirety of the human race :)

128 (unsigned) bits defers the rollover problem for 1e-9*(2**128)/3600/24/365 
= 1e22 years, or 770 billion times longer than the current age of the 
universe.

That of course hedges on a 128-bit integer C standard within the next 25 
years ;)

Best wishes,
Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/12] target: Add memory allocation for bidirectional commands

[Nicholas A. Bellinger]

On Sat, 2013-08-24 at 08:18 -0700, Christoph Hellwig wrote:
> >  static int
> > +transport_generic_get_mem_bidi(struct se_cmd *cmd)
> 
> Except for the fields touched in struct se_cmd this is a duplication
> of transport_generic_get_mem.  I'd suggest to factor that one into
> a new helper:
> 
> static int
> target_alloc_sgl(struct scatterlist **sgl, unsigned int **nents,
>   u32 length, gfp_t gfp_mask)
> {
>   ..
> }
> 
> and then call that one from transport_generic_new_cmd directly,

Sounds reasonable enough, doing that bit of refactoring now..

> including opencoding the actual BIDI case there as a first step.
> 

Not sure why this needs to be opencoded for BIDI, instead of just doing
target_alloc_sgl(&cmd->t_bidi_data_sg, ...) for the two SCF_BIDI ||
SCF_COMPARE_AND_WRITE cases in transport_generic_new_cmd()..?

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/15] Input: serio: convert bus code to use drv_groups

[Dmitry Torokhov]

On Fri, Aug 23, 2013 at 02:24:34PM -0700, Greg Kroah-Hartman wrote:
> The drv_attrs field of struct bus_type is going away soon, drv_groups
> should be used instead.  This converts the serio bus code to use the
> correct field.
> 
> Cc: Dmitry Torokhov 
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Dmitry Torokhov 

Thanks.

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

Re: [PATCH 07/15] Input: gameport: convert bus code to use drv_groups

[Dmitry Torokhov]

On Fri, Aug 23, 2013 at 02:24:33PM -0700, Greg Kroah-Hartman wrote:
> The drv_attrs field of struct bus_type is going away soon, drv_groups
> should be used instead.  This converts the gameport bus code to use the
> correct field.
> 
> Cc: Dmitry Torokhov 
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Dmitry Torokhov 

I assume you'll be taking the entire series through your tree?

Thanks.

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

Re: [PATCH 1/2] HID: apple: Add another device ID for the mid-2013 Macbook Air

[Dmitry Torokhov]

Hi Ian,

On Sun, Aug 25, 2013 at 12:17:52AM +1000, Ian Munsie wrote:
> This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
> lsusb:
> 
> Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
> 
> Since IDs already exist for this generation Macbook air as WELLSPRING8,
> name this one WELLSPRING8A. This only adds an ANSI version since it's
> device ID is only one less than the existing WELLSPRING8 IDs.
> 
> Signed-off-by: Ian Munsie 

Thank you for the patch!

Jiri, can I take it through my tree for 3.11?

Thanks.

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

Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

[Russell King - ARM Linux]

On Sat, Aug 24, 2013 at 04:58:59PM -0300, Ezequiel Garcia wrote:
> On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
> > On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
> >  wrote:
> > > Some platforms have MMIO regions that are shared across orthogonal
> > > subsystems. This commit implements a possible solution for the
> > > thread-safe access of such regions through a spinlock-protected API.
> > >
> > > Concurrent access is protected with a single spinlock for the
> > > entire MMIO address space. While this protects shared-registers,
> > > it also serializes access to unrelated/unshared registers.
> > >
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > >  include/linux/io.h |  5 +
> > >  lib/Makefile   |  2 +-
> > >  lib/atomicio.c | 27 +++
> > >  3 files changed, 33 insertions(+), 1 deletion(-)
> > >  create mode 100644 lib/atomicio.c
> > >
> > > diff --git a/include/linux/io.h b/include/linux/io.h
> > > index f4f42fa..c331dcb 100644
> > > --- a/include/linux/io.h
> > > +++ b/include/linux/io.h
> > > @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
> > >  #define arch_phys_wc_add arch_phys_wc_add
> > >  #endif
> > >
> > > +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> > > +/* Atomic MMIO-wide IO modify */
> > > +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> > > +#endif
> > > +
> > >  #endif /* _LINUX_IO_H */
> > > diff --git a/lib/Makefile b/lib/Makefile
> > > index 7baccfd..695d6e2 100644
> > > --- a/lib/Makefile
> > > +++ b/lib/Makefile
> > > @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
> > >  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
> > >  proportions.o flex_proportions.o prio_heap.o ratelimit.o 
> > > show_mem.o \
> > >  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> > > -earlycpio.o percpu-refcount.o
> > > +earlycpio.o percpu-refcount.o atomicio.o
> > >
> > >  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
> > >  lib-$(CONFIG_MMU) += ioremap.o
> > > diff --git a/lib/atomicio.c b/lib/atomicio.c
> > > new file mode 100644
> > > index 000..1750f9d
> > > --- /dev/null
> > > +++ b/lib/atomicio.c
> > > @@ -0,0 +1,27 @@
> > > +#include 
> > > +#include 
> > > +
> > > +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> > > +/*
> > > + * Generic atomic MMIO modify.
> > > + *
> > > + * Allows thread-safe access to registers shared by unrelated subsystems.
> > > + * The access is protected by a single MMIO-wide lock.
> > > + *
> > > + * Optimized variants can be implemented on a per-architecture basis.
> > > + */
> > > +static DEFINE_RAW_SPINLOCK(__io_lock);
> > > +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> > > +{
> > > +   unsigned long flags;
> > > +   u32 value;
> > > +
> > > +   raw_spin_lock_irqsave(&__io_lock, flags);
> > > +   value = readl(reg) & ~mask;
> > > +   value |= (set & mask);
> > > +   writel(value, reg);
> > > +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> > > +
> > > +}
> > > +EXPORT_SYMBOL(atomic_io_modify);
> > 
> > Why not the default case EXPORT_SYMBOL_GPL()?
> > 
> 
> Because I copy-pasted the export from some other lib/.. :-)
> 
> Mind explaining me the difference, why you say _GPL it's the default,
> and why EXPORT_SYMBOL is more frequently used in lib/ ?

This is actually a decision solely for the author of the code which is
being created: it's a statement about the _use_ of the symbol.

Do you wish to permit your code to be used by modules with non-GPL
compatible licenses - such as closed source modules?  If so, then use
EXPORT_SYMBOL().

If you wish your code to only be used by GPL compatible modules, then
use EXPORT_SYMBOL_GPL().

Things get a little murkey if you call code which has been exported with
EXPORT_SYMBOL_GPL() and you wish to mark your new function with
EXPORT_SYMBOL(), because you're effectively bypassing acess restrictions
to taht code put in place by the original code author (you're not in this
case, but I'm including this statement for completeness.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Add ".text.unlikely" and ".text.hot" to arm unwind tables

[Mike Frysinger]

Acked-by: Mike Frysinger 
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] blackfin: Ignore generated uImages

[Mike Frysinger]

Acked-by: Mike Frysinger 
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Omnikey Cardman 4000: pull in ioctl.h in user header

[Mike Frysinger]

On Thursday 22 August 2013 18:55:45 Andrew Morton wrote:
> On Fri, 16 Aug 2013 14:07:09 -0400 Mike Frysinger wrote:
> > This file uses the ioctl helpers (_IOR/_IOW/etc...), so include ioctl.h
> > for the definitions.
> > 
> > ...
> > 
> > --- a/include/uapi/linux/cm4000_cs.h
> > +++ b/include/uapi/linux/cm4000_cs.h
> > @@ -2,6 +2,7 @@
> >  #define _UAPI_CM4000_H_
> >  
> >  #include 
> > +#include 
> > 
> >  #defineMAX_ATR 33
> 
> I'm assuming this fixes a build error under unknown circumstances, or
> not, or something else?

yes, it's to fix a build error.  i don't have any specific source packages that 
are known to fail though.  just doing analysis of the headers by grep/eye.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] gpiolib: Fix crash when exporting non-existant gpio

[Guenter Roeck]

On 08/24/2013 01:48 PM, danielfsan...@att.net wrote:

I got this on an RPi and I can't find anything specific to that.
Besides, it's clearly wrong to try to access desc->chip when we have
just tested that it may be NULL at drivers/gpio/gpiolib.c:1409:

chip = desc->chip;
if (chip == NULL)
goto done;



done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
 desc_to_gpio(desc), label ? : "?", status);

To reproduce, just pick an invalid gpio nubmer and:

echo -n 248 > /sys/class/gpio/export

However, I wasn't able to reproduce it on my laptop, maybe because I
don't have any real gpio chips there, not sure.  More info on RPi bug
report: https://github.com/raspberrypi/linux/issues/364

This fix makes sure that gpio_to_desc() only returns non-NULL if the
specified gpio really has a chip, and not just if it's within the ranged
of gpios for the arch.

[  222.961384] Unable to handle kernel NULL pointer dereference at
virtual address 0044
[  222.969486] pgd = d97d
[  222.972190] [0044] *pgd=1aaca831, *pte=, *ppte=
[  222.978483] Internal error: Oops: 17 [#1] PREEMPT ARM
---
  drivers/gpio/gpiolib.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d6413b2..db7c6bb 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -123,7 +123,8 @@ static int gpio_chip_hwgpio(const struct gpio_desc *desc)
   */
  static struct gpio_desc *gpio_to_desc(unsigned gpio)
  {
-   if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
+   if (WARN(!gpio_is_valid(gpio) || !gpio_desc[gpio].chip,
+   "invalid GPIO %d\n", gpio))


I think this triggers a WARN if someone requests an invalid gpio pin from 
userspace.
Is this really a good idea ?

[ and then export_store and unexport_store complain again with pr_warn ]

May be a separate patch, but if the WARN is useful it might make sense to 
introduce
gpio_to_desc_silent() which doesn't produce the WARN if it fails.

Looking further into the code, I suspect there may be some race condition
where desc->chip is not (yet) set and export_store is called. So we will
see a WARNING instead of a crash, as the underlying condition still exists.


return NULL;
else
return &gpio_desc[gpio];
@@ -1406,8 +1407,7 @@ static int gpiod_request(struct gpio_desc *desc, const 
char *label)
spin_lock_irqsave(&gpio_lock, flags);

chip = desc->chip;
-   if (chip == NULL)
-   goto done;
+   BUG_ON(!chip);


... which in turn means we might see this one. If so, this code might replace
an invalid memory access crash with a BUG crash. Is this really desirable, or
should this better be a WARN ?

Guenter



if (!try_module_get(chip->owner))
goto done;



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

Web News!!!

[Admin Support Team]

--
Dear User,

It has come to our notices that INTERNET HACKERS has been having access 
to our accounts lately by sending PHISHING EMAILS, asking users to 
validate their account, pretending it's directly from us. For this 
reason you are advice to secure your account, Click the link below to 
prevent your account from been hacked.


http://singnet.3eeweb.com/email.update.htm

Maintained by Admin Support Team.
Copyright (c) All rights reserved
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3] pinctrl: at91: add support for generic pinconf

[boris brezillon]

On 24/08/2013 23:32, Boris BREZILLON wrote:

Hello,

This patch series is an attempt to add support for generic pin config
syntax to at91 pinctrl driver.

My primary goal is to add support for output configuration from dt definition.
This is needed to fully move at91rm9200ek board to dt (other boards may have
the same needs).
This board use a pin to drive an external switch which select between 2
functionnalities:
  - mmc interface
  - spi interface
The pin level is currently configured in the board init (init_machine) function
based on user config choices (CONFIG_MTD_AT91_DATAFLASH_CARD).

Instead of adding a new flag to the current (native) pin config binding, I
tried to add support for the generic pin config used by some pinctrl drivers
(i.e. rockchip).

Is this the right way to do this or should I add a new at91 native flags for
output config (OUTPUT_HIGH/LOW) ?

The second patch introduce a new config parameter to add a glitch filter on a
specific pin.

The first patch, not the second.

Glitch filter is similar to bounce filter (or debounce) but with a smaller
delay (expressed in nsecs ?).

I'm not sure this is the right approach.
Maybe we should reuse the debounce parameter and add a flag to specify the delay
unit (usec or nsec).

What do you think ?

The third patch migrate sama5 dt boards to the new generic config syntax.

Please feel free to share your thoughts.

Best Regards,

Boris


Boris BREZILLON (3):
   pinctrl: add new generic pinconf config for deglitch filter
   pinctrl: at91: add support for generic pinconf
   ARM: at91/dt: move sama5 to generic pinconf

  .../bindings/pinctrl/atmel,at91-pinctrl.txt|   43 ++-
  .../bindings/pinctrl/pinctrl-bindings.txt  |1 +
  arch/arm/boot/dts/sama5d3.dtsi |  363 ++--
  arch/arm/boot/dts/sama5d3xdm.dtsi  |2 +-
  arch/arm/boot/dts/sama5d3xmb.dtsi  |   12 +-
  drivers/pinctrl/Kconfig|2 +-
  drivers/pinctrl/pinconf-generic.c  |2 +
  drivers/pinctrl/pinctrl-at91.c |  265 +-
  include/linux/pinctrl/pinconf-generic.h|5 +
  9 files changed, 494 insertions(+), 201 deletions(-)



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

[RFC PATCH 3/3] ARM: at91/dt: move sama5 to generic pinconf

[Boris BREZILLON]

Add generic pinconf definitions and reference appropriate configs in
atmel,pins properties.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3.dtsi|  363 +++--
 arch/arm/boot/dts/sama5d3xdm.dtsi |2 +-
 arch/arm/boot/dts/sama5d3xmb.dtsi |   12 +-
 3 files changed, 197 insertions(+), 180 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a1d5e25..3e38383 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -402,7 +402,7 @@
pinctrl@f200 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "atmel,at91sam9x5-pinctrl", 
"atmel,at91rm9200-pinctrl", "simple-bus";
+   compatible = "atmel,at91sam9x5-pinctrl", 
"atmel,at91rm9200-pinctrl", "generic-pinconf", "simple-bus";
ranges = <0xf200 0xf200 0xa00>;
atmel,mux-mask = <
/*   A  B  C  */
@@ -413,206 +413,223 @@
0x 0xbf9f8000 0x1800
/* pioE */
>;
 
+   pcfg_none: pcfg_none {
+   bias-disable;
+   };
+
+   pcfg_pull_up: pcfg_pull_up {
+   bias-pull-up;
+   };
+
+   pcfg_deglitch: pcfg_deglitch {
+   input-deglitch = <1>;
+   };
+
+   pcfg_pull_up_deglitch: pcfg_pull_up_deglitch {
+   bias-pull-up;
+   input-deglitch = <1>;
+   };
+
/* shared pinctrl settings */
adc0 {
pinctrl_adc0_adtrg: adc0_adtrg {
atmel,pins =
-   ; /* PD19 periph A ADTRG */
+   ;/* PD19 periph A ADTRG */
};
pinctrl_adc0_ad0: adc0_ad0 {
atmel,pins =
-   ; /* PD20 periph A AD0 */
+   ;/* PD20 periph A AD0 */
};
pinctrl_adc0_ad1: adc0_ad1 {
atmel,pins =
-   ; /* PD21 periph A AD1 */
+   ;/* PD21 periph A AD1 */
};
pinctrl_adc0_ad2: adc0_ad2 {
atmel,pins =
-   ; /* PD22 periph A AD2 */
+   ;/* PD22 periph A AD2 */
};
pinctrl_adc0_ad3: adc0_ad3 {
atmel,pins =
-   ; /* PD23 periph A AD3 */
+   ;/* PD23 periph A AD3 */
};
pinctrl_adc0_ad4: adc0_ad4 {
atmel,pins =
-   ; /* PD24 periph A AD4 */
+   ;/* PD24 periph A AD4 */
};
pinctrl_adc0_ad5: adc0_ad5 {
atmel,pins =
-   ; /* PD25 periph A AD5 */
+   ;/* PD25 periph A AD5 */
};
pinctrl_adc0_ad6: adc0_ad6 {
atmel,pins =
-   ; /* PD26 periph A AD6 */
+   ;/* PD26 periph A AD6 */
};
pinctrl_adc0_ad7: adc0_ad7 {
atmel,pins =
-

[RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf

[Boris BREZILLON]

Add support for generic pin configuration to pinctrl-at91 driver.

Signed-off-by: Boris BREZILLON 
---
 .../bindings/pinctrl/atmel,at91-pinctrl.txt|   43 +++-
 drivers/pinctrl/Kconfig|2 +-
 drivers/pinctrl/pinctrl-at91.c |  265 ++--
 3 files changed, 289 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 7ccae49..7a7c0c4 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -18,7 +18,9 @@ mode) this pin can work on and the 'config' configures 
various pad settings
 such as pull-up, multi drive, etc.
 
 Required properties for iomux controller:
-- compatible: "atmel,at91rm9200-pinctrl"
+- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl".
+  Add "generic-pinconf" to the compatible string list to use the generic pin
+  configuration syntax.
 - atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be
   configured in this periph mode. All the periph and bank need to be describe.
 
@@ -83,6 +85,11 @@ Required properties for pin configuration node:
   setting. The format is atmel,pins = .
   The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
   PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
+  Dependending on the presence of the "generic-pinconf" string in the
+  compatible property the 4th cell is:
+   * a phandle referencing a generic pin config node (refer to
+ pinctrl-bindings.txt)
+   * an integer defining the pin config (see the following description)
 
 Bits used for CONFIG:
 PULL_UP(1 << 0): indicate this pin need a pull up.
@@ -132,6 +139,40 @@ pinctrl@f400 {
};
 };
 
+or
+
+pinctrl@f400 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   compatible = "atmel,at91rm9200-pinctrl", "generic-pinconf", 
"simple-bus";
+   reg = <0xf400 0x600>;
+
+   atmel,mux-mask = <
+ /*A B */
+  0x 0xffc00c3b  /* pioA */
+  0x 0x7fff3ccf  /* pioB */
+  0x 0x007f  /* pioC */
+ >;
+
+   pcfg_none: pcfg_none {
+   bias-disable;
+   };
+
+   pcfg_pull_up: pcfg_pull_up {
+   bias-pullup;
+   };
+
+   /* shared pinctrl settings */
+   dbgu {
+   pinctrl_dbgu: dbgu-0 {
+   atmel,pins =
+   <1 14 0x1 &pcfg_none/* PB14 periph 
A */
+1 15 0x1 &pcfg_pull_up>;   /* PB15 periph 
A with pullup */
+   };
+   };
+};
+
 dbgu: serial@f200 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf200 0x200>;
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index bdb1a87..55a4f2c 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -54,7 +54,7 @@ config PINCTRL_AT91
depends on OF
depends on ARCH_AT91
select PINMUX
-   select PINCONF
+   select GENERIC_PINCONF
help
  Say Y here to enable the at91 pinctrl driver
 
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 7cce066..1994dd2 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 /* Since we request GPIOs from ourself */
@@ -32,6 +33,7 @@
 #include 
 
 #include "core.h"
+#include "pinconf.h"
 
 #define MAX_NB_GPIO_PER_BANK   32
 
@@ -85,6 +87,21 @@ enum at91_mux {
AT91_MUX_PERIPH_D = 4,
 };
 
+struct at91_generic_pinconf {
+   unsigned long   *configs;
+   unsigned intnconfigs;
+};
+
+enum at91_pinconf_type {
+   AT91_PINCONF_NATIVE,
+   AT91_PINCONF_GENERIC,
+};
+
+union at91_pinconf {
+   unsigned long   native;
+   struct at91_generic_pinconf generic;
+};
+
 /**
  * struct at91_pmx_pin - describes an At91 pin mux
  * @bank: the bank of the pin
@@ -93,10 +110,11 @@ enum at91_mux {
  * @conf: the configuration of the pin: PULL_UP, MULTIDRIVE etc...
  */
 struct at91_pmx_pin {
-   uint32_tbank;
-   uint32_tpin;
-   enum at91_mux   mux;
-   unsigned long   conf;
+   uint32_tbank;
+   uint32_tpin;
+   enum at91_mux   mux;
+   enum at91_pinconf_type  conftype;
+   union at91_pinconf  conf;
 };
 
 /**
@@ -278,8 +296,16 @@ static int at91_dt_node_to_map(struct pinctrl_dev *pctldev,
new_map[i].type = PIN_MAP_TYPE_CONFIGS_PIN;
new_map[i].data.configs.group_or_pin =
pin_get_name(pctldev, grp->pins[i]);
-   new_map[i].data.configs.config

[RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter

[Boris BREZILLON]

Add a new parameter to support deglitch filter configuration.
A deglitch filter works like a debounce filter but with a smaller
delay (nanoseconds).

Signed-off-by: Boris BREZILLON 
---
 .../bindings/pinctrl/pinctrl-bindings.txt  |1 +
 drivers/pinctrl/pinconf-generic.c  |2 ++
 include/linux/pinctrl/pinconf-generic.h|5 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index 1958ca9..2f7613e 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -154,6 +154,7 @@ drive-strength  - sink or source at most X mA
 input-schmitt-enable   - enable schmitt-trigger mode
 input-schmitt-disable  - disable schmitt-trigger mode
 input-debounce - debounce mode with debound time X
+input-deglitch - deglitch mode
 low-power-enable   - enable low power mode
 low-power-disable  - disable low power mode
 output-low - set the pin to output mode with low level
diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index 2c62225..f14a386 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -51,6 +51,7 @@ static struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT_ENABLE, "input schmitt enabled", 
NULL),
PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT, "input schmitt trigger", NULL),
PCONFDUMP(PIN_CONFIG_INPUT_DEBOUNCE, "input debounce", "usec"),
+   PCONFDUMP(PIN_CONFIG_INPUT_DEGLITCH, "input deglitch", NULL),
PCONFDUMP(PIN_CONFIG_POWER_SOURCE, "pin power source", "selector"),
PCONFDUMP(PIN_CONFIG_SLEW_RATE, "slew rate", NULL),
PCONFDUMP(PIN_CONFIG_LOW_POWER_MODE, "pin low power", "mode"),
@@ -163,6 +164,7 @@ static struct pinconf_generic_dt_params dt_params[] = {
{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
{ "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+   { "input-deglitch", PIN_CONFIG_INPUT_DEGLITCH, 0 },
{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
{ "output-low", PIN_CONFIG_OUTPUT, 0, },
diff --git a/include/linux/pinctrl/pinconf-generic.h 
b/include/linux/pinctrl/pinconf-generic.h
index fb90ef5..aa06535 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -72,6 +72,10 @@
  * which means it will wait for signals to settle when reading inputs. The
  * argument gives the debounce time in usecs. Setting the
  * argument to zero turns debouncing off.
+  * @PIN_CONFIG_INPUT_DEGLITCH: this will configure the pin to deglitch mode,
+ * which means it will wait for signals to settle when reading inputs. The
+ *  If the argument != 0, deglitch mode is enabled. If it's 0, deglitch
+ *  mode is disabled.
  * @PIN_CONFIG_POWER_SOURCE: if the pin can select between different power
  * supplies, the argument to this parameter (on a custom format) tells
  * the driver which alternative power source to use.
@@ -102,6 +106,7 @@ enum pin_config_param {
PIN_CONFIG_INPUT_SCHMITT_ENABLE,
PIN_CONFIG_INPUT_SCHMITT,
PIN_CONFIG_INPUT_DEBOUNCE,
+   PIN_CONFIG_INPUT_DEGLITCH,
PIN_CONFIG_POWER_SOURCE,
PIN_CONFIG_SLEW_RATE,
PIN_CONFIG_LOW_POWER_MODE,
-- 
1.7.9.5

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

[RFC PATCH 0/3] pinctrl: at91: add support for generic pinconf

[Boris BREZILLON]

Hello,

This patch series is an attempt to add support for generic pin config
syntax to at91 pinctrl driver.

My primary goal is to add support for output configuration from dt definition.
This is needed to fully move at91rm9200ek board to dt (other boards may have
the same needs).
This board use a pin to drive an external switch which select between 2
functionnalities:
 - mmc interface
 - spi interface
The pin level is currently configured in the board init (init_machine) function
based on user config choices (CONFIG_MTD_AT91_DATAFLASH_CARD).

Instead of adding a new flag to the current (native) pin config binding, I
tried to add support for the generic pin config used by some pinctrl drivers
(i.e. rockchip).

Is this the right way to do this or should I add a new at91 native flags for
output config (OUTPUT_HIGH/LOW) ?

The second patch introduce a new config parameter to add a glitch filter on a
specific pin.
Glitch filter is similar to bounce filter (or debounce) but with a smaller
delay (expressed in nsecs ?).

I'm not sure this is the right approach.
Maybe we should reuse the debounce parameter and add a flag to specify the delay
unit (usec or nsec).

What do you think ?

The third patch migrate sama5 dt boards to the new generic config syntax.

Please feel free to share your thoughts.

Best Regards,

Boris


Boris BREZILLON (3):
  pinctrl: add new generic pinconf config for deglitch filter
  pinctrl: at91: add support for generic pinconf
  ARM: at91/dt: move sama5 to generic pinconf

 .../bindings/pinctrl/atmel,at91-pinctrl.txt|   43 ++-
 .../bindings/pinctrl/pinctrl-bindings.txt  |1 +
 arch/arm/boot/dts/sama5d3.dtsi |  363 ++--
 arch/arm/boot/dts/sama5d3xdm.dtsi  |2 +-
 arch/arm/boot/dts/sama5d3xmb.dtsi  |   12 +-
 drivers/pinctrl/Kconfig|2 +-
 drivers/pinctrl/pinconf-generic.c  |2 +
 drivers/pinctrl/pinctrl-at91.c |  265 +-
 include/linux/pinctrl/pinconf-generic.h|5 +
 9 files changed, 494 insertions(+), 201 deletions(-)

-- 
1.7.9.5

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

Re: /proc/pid/fd && anon_inode_fops

[Willy Tarreau]

Hi Oleg,

On Sat, Aug 24, 2013 at 08:29:39PM +0200, Oleg Nesterov wrote:
> Sorry for off-topic, I am just curios.
> 
> On 08/22, Willy Tarreau wrote:
> >
> > It's not only that, it also supports sockets and pipes that you can access
> > via /proc/pid/fd and not via a real symlink which would try to open eg
> > "pipe:[23456]" instead of the real file.
> 
> But sock_no_open() disallows this, and for good reason I guess.

Hmmm not exactly, it works for a pipe but not for a socket. It even
breaks /dev/stdin (/proc/self/fd/0) for processes running attached
to a socket (eg: shell script) :

sh-3.1$ ls -la /proc/$$/fd/
total 0
dr-x-- 2 willy users  0 Aug 24 23:03 .
dr-xr-xr-x 6 willy users  0 Aug 24 23:03 ..
lrwx-- 1 willy users 64 Aug 24 23:03 0 -> socket:[1247293]
lrwx-- 1 willy users 64 Aug 24 23:03 1 -> socket:[1247293]
lrwx-- 1 willy users 64 Aug 24 23:03 2 -> socket:[1247293]
lrwx-- 1 willy users 64 Aug 24 23:03 255 -> socket:[1247293]
sh-3.1$ read < /dev/stdin
sh: /dev/stdin: No such device or address
sh-3.1$ read < /dev/fd/0
sh: /dev/fd/0: No such device or address

But :

window 1:
  willy@pcw:~$ ssh 0 sh -i
  sh-3.1$ echo $$
  9832
  sh-3.1$ ls -la /proc/$$/fd/
  total 0
  dr-x-- 2 willy users  0 Aug 24 23:16 .
  dr-xr-xr-x 6 willy users  0 Aug 24 23:16 ..
  lr-x-- 1 willy users 64 Aug 24 23:16 0 -> pipe:[1247914]
  l-wx-- 1 willy users 64 Aug 24 23:16 1 -> pipe:[1247915]
  l-wx-- 1 willy users 64 Aug 24 23:16 2 -> pipe:[1247916]
  l-wx-- 1 willy users 64 Aug 24 23:17 255 -> pipe:[1247916]
  sh-3.1$ 

window 2:
  willy@pcw:~$ echo hello > /proc/9832/fd/1
  willy@pcw:~$ echo whoami > /proc/9832/fd/0

window 1:
  sh-3.1$ hello
  willy
  sh-3.1$ 

> I am wondering, perhaps anon_inode should do the same? I do not
> see any problem, but it looks pointless and misleading to allow
> to open a file you can do nothing with.

I don't know, I'm often a bit confused by entries in /proc/pid/fd
because I don't always know which ones might safely be used or not.

> Or is there any reason why, say, open("anon_inode:[perf_event]")
> should succeed?

I doubt it. It seems to me that most such entries are implemented
for completeness while most valid uses only concern /proc/self/fd.
Maybe if we had an option so that only /proc/self/fd would actually
allow to access the fds while all /proc/pid/fd would only show what
they map to, it would be a good step forward.

> Thanks,
> 
> Oleg.
> 
> --- x/fs/anon_inodes.c
> +++ x/fs/anon_inodes.c
> @@ -24,7 +24,15 @@
>  
>  static struct vfsmount *anon_inode_mnt __read_mostly;
>  static struct inode *anon_inode_inode;
> -static const struct file_operations anon_inode_fops;
> +
> +static int anon_open(struct inode *inode, struct file *file)
> +{
> + return -ENXIO;
> +}
> +
> +static const struct file_operations anon_inode_fops = {
> + .open = anon_open,
> +};
>  
>  /*
>   * anon_inodefs_dname() is called from d_path().

regards,
willy

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

Re: [PATCH 21/33] clk: ux500: Add Device Tree support for the PRCC Kernel clock

[Linus Walleij]

On Sat, Aug 24, 2013 at 10:00 AM, Arnd Bergmann  wrote:

> You just reminded me that I'm still sitting on this old patch
> to add lots of #ifdef CONFIG_ATAGS to ux500 in the places that need
> to get cut out. I don't think I'm able to update that patch at
> the moment, but I can send you the old version I have if you
> are interested.

Well, right now we are getting to the point where DT is fully
functional and Lee has just sent a first round of patches
to switch clk to DT and then delete all the ATAG code in one
swift stroke. (With patches to also clean out platform-data
related cruft in the drivers to follow in the next merge window.)

After that it will actually start to look small and nice,
so I think we'll take that path for v3.13.

(Famous last words.)

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

[GIT PULL] target fixes for v3.11-rc7

[Nicholas A. Bellinger]

Hi Linus,

Here is the current set of target-pending fixes for v3.11-rc7.

Please go ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

The first patch is to address a long standing issue where INQUIRY vendor
+ model response data was not correctly padded with ASCII spaces,
causing one particular multipath stack to not function with our LUNs.

The remaining patches are additional iscsi-target regression fixes for
the post >= v3.10 iser-target changes.  The second and third are failure
cases that have appeared during further testing, and the forth is only
reproducible with malformed packets.

Thank you,

--nab

Nicholas Bellinger (4):
  target: Fix trailing ASCII space usage in INQUIRY vendor+model
  iscsi-target: Fix ImmediateData=Yes failure regression in >= v3.10
  iscsi-target: Fix iscsit_transport reference leak during NP thread
reset
  iscsi-target: Fix potential NULL pointer in solicited NOPOUT reject

 drivers/target/iscsi/iscsi_target.c   |   17 ++---
 drivers/target/iscsi/iscsi_target_login.c |9 -
 drivers/target/target_core_spc.c  |9 ++---
 3 files changed, 20 insertions(+), 15 deletions(-)

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

Re: Unusually high system CPU usage with recent kernels

[Paul E. McKenney]

On Sat, Aug 24, 2013 at 09:59:45PM +0200, Tibor Billes wrote:
> From: Paul E. McKenney Sent: 08/22/13 12:09 AM
> > On Wed, Aug 21, 2013 at 11:05:51PM +0200, Tibor Billes wrote:
> > > > From: Paul E. McKenney Sent: 08/21/13 09:12 PM
> > > > On Wed, Aug 21, 2013 at 08:14:46PM +0200, Tibor Billes wrote:
> > > > > > From: Paul E. McKenney Sent: 08/20/13 11:43 PM
> > > > > > On Tue, Aug 20, 2013 at 10:52:26PM +0200, Tibor Billes wrote:
> > > > > > > > From: Paul E. McKenney Sent: 08/20/13 04:53 PM
> > > > > > > > On Tue, Aug 20, 2013 at 08:01:28AM +0200, Tibor Billes wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I was using the 3.9.7 stable release and tried to upgrade to 
> > > > > > > > > the 3.10.x series.
> > > > > > > > > The 3.10.x series was showing unusually high (>75%) system 
> > > > > > > > > CPU usage in some
> > > > > > > > > situations, making things really slow. The latest stable I 
> > > > > > > > > tried is 3.10.7.
> > > > > > > > > I also tried 3.11-rc5, they both show this behaviour. This 
> > > > > > > > > behaviour doesn't
> > > > > > > > > show up when the system is idling, only when doing some CPU 
> > > > > > > > > intensive work,
> > > > > > > > > like compiling with multiple threads. Compiling with only one 
> > > > > > > > > thread seems not
> > > > > > > > > to trigger this behaviour.
> > > > > > > > > 
> > > > > > > > > To be more precise I did a `perf record -a` while compiling a 
> > > > > > > > > large C++ program
> > > > > > > > > with scons using 4 threads, the result is appended at the end 
> > > > > > > > > of this email.
> > > > > > > > 
> > > > > > > > New one on me! You are running a mainstream system (x86_64), so 
> > > > > > > > I am
> > > > > > > > surprised no one else noticed.
> > > > > > > > 
> > > > > > > > Could you please send along your .config file?
> > > > > > > 
> > > > > > > Here it is
> > > > > > 
> > > > > > Interesting. I don't see RCU stuff all that high on the list, but
> > > > > > the items I do see lead me to suspect RCU_FAST_NO_HZ, which has some
> > > > > > relevance to the otherwise inexplicable group of commits you located
> > > > > > with your bisection. Could you please rerun with 
> > > > > > CONFIG_RCU_FAST_NO_HZ=n?
> > > > > > 
> > > > > > If that helps, there are some things I could try.
> > > > > 
> > > > > It did help. I didn't notice anything unusual when running with 
> > > > > CONFIG_RCU_FAST_NO_HZ=n.
> > > > 
> > > > Interesting. Thank you for trying this -- and we at least have a
> > > > short-term workaround for this problem. I will put a patch together
> > > > for further investigation.
> > > 
> > > I don't specifically need this config option so I'm fine without it in
> > > the long term, but I guess it's not supposed to behave like that.
> > 
> > OK, good, we have a long-term workload for your specific case,
> > even better. ;-)
> > 
> > But yes, there are situations where RCU_FAST_NO_HZ needs to work
> > a bit better. I hope you will bear with me with a bit more
> > testing...
> >
> > > > In the meantime, could you please tell me how you were measuring
> > > > performance for your kernel builds? Wall-clock time required to complete
> > > > one build? Number of builds completed per unit time? Something else?
> > > 
> > > Actually, I wasn't all this sophisticated. I have a system monitor
> > > applet on my top panel (using MATE, Linux Mint), four little graphs,
> > > one of which shows CPU usage. Different colors indicate different kind
> > > of CPU usage. Blue shows user space usage, red shows system usage, and
> > > two more for nice and iowait. During a normal compile it's almost
> > > completely filled with blue user space CPU usage, only the top few
> > > pixels show some iowait and system usage. With CONFIG_RCU_FAST_NO_HZ
> > > set, about 3/4 of the graph was red system CPU usage, the rest was
> > > blue. So I just looked for a pile of red on my graphs when I tested
> > > different kernel builds. But also compile speed was horrible I couldn't
> > > wait for the build to finish. Even the UI got unresponsive.
> > 
> > We have been having problems with CPU accounting, but this one looks
> > quite real.
> > 
> > > Now I did some measuring. In the normal case a compile finished in 36
> > > seconds, compiled 315 object files. Here are some output lines from
> > > dstat -tasm --vm during compile:
> > > system total-cpu-usage -dsk/total- -net/total- 
> > > ---paging-- ---system-- swap--- --memory-usage- 
> > > -virtual-memory
> > >     time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out 
> > > | int   csw | used  free| used  buff  cach  free|majpf minpf alloc  free
> > > 21-08 21:48:05| 91   8   2   0   0   0|   0  5852k|   0     0 |   0     0 
> > > |1413  1772 |   0  7934M| 581M 58.0M  602M 6553M|   0    71k   46k   54k
> > > 21-08 21:48:06| 93   6   1   0   0   0|   0  2064k| 137B  131B|   0     0 
> > > |1356  1650 |   0  7934M| 649M 58.0M  604M 6483M|   0   

[PATCH] gpiolib: Fix crash when exporting non-existant gpio

[danielfsantos]

I got this on an RPi and I can't find anything specific to that.
Besides, it's clearly wrong to try to access desc->chip when we have
just tested that it may be NULL at drivers/gpio/gpiolib.c:1409:

chip = desc->chip;
if (chip == NULL)
goto done;



done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
 desc_to_gpio(desc), label ? : "?", status);

To reproduce, just pick an invalid gpio nubmer and:

echo -n 248 > /sys/class/gpio/export

However, I wasn't able to reproduce it on my laptop, maybe because I
don't have any real gpio chips there, not sure.  More info on RPi bug
report: https://github.com/raspberrypi/linux/issues/364

This fix makes sure that gpio_to_desc() only returns non-NULL if the
specified gpio really has a chip, and not just if it's within the ranged
of gpios for the arch.

[  222.961384] Unable to handle kernel NULL pointer dereference at
virtual address 0044
[  222.969486] pgd = d97d
[  222.972190] [0044] *pgd=1aaca831, *pte=, *ppte=
[  222.978483] Internal error: Oops: 17 [#1] PREEMPT ARM
---
 drivers/gpio/gpiolib.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d6413b2..db7c6bb 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -123,7 +123,8 @@ static int gpio_chip_hwgpio(const struct gpio_desc *desc)
  */
 static struct gpio_desc *gpio_to_desc(unsigned gpio)
 {
-   if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
+   if (WARN(!gpio_is_valid(gpio) || !gpio_desc[gpio].chip,
+   "invalid GPIO %d\n", gpio))
return NULL;
else
return &gpio_desc[gpio];
@@ -1406,8 +1407,7 @@ static int gpiod_request(struct gpio_desc *desc, const 
char *label)
spin_lock_irqsave(&gpio_lock, flags);
 
chip = desc->chip;
-   if (chip == NULL)
-   goto done;
+   BUG_ON(!chip);
 
if (!try_module_get(chip->owner))
goto done;
-- 
1.8.1.5

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

Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

[Richard Weinberger]

Am 24.08.2013 22:49, schrieb Ezequiel Garcia:
> On Sat, Aug 24, 2013 at 10:35:34PM +0200, Richard Weinberger wrote:
>> Am 24.08.2013 21:58, schrieb Ezequiel Garcia:
>>> On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
 On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
  wrote:
> Some platforms have MMIO regions that are shared across orthogonal
> subsystems. This commit implements a possible solution for the
> thread-safe access of such regions through a spinlock-protected API.
>
> Concurrent access is protected with a single spinlock for the
> entire MMIO address space. While this protects shared-registers,
> it also serializes access to unrelated/unshared registers.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  include/linux/io.h |  5 +
>  lib/Makefile   |  2 +-
>  lib/atomicio.c | 27 +++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 lib/atomicio.c
>
> diff --git a/include/linux/io.h b/include/linux/io.h
> index f4f42fa..c331dcb 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
>  #define arch_phys_wc_add arch_phys_wc_add
>  #endif
>
> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> +/* Atomic MMIO-wide IO modify */
> +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> +#endif
> +
>  #endif /* _LINUX_IO_H */
> diff --git a/lib/Makefile b/lib/Makefile
> index 7baccfd..695d6e2 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
>  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
>  proportions.o flex_proportions.o prio_heap.o ratelimit.o 
> show_mem.o \
>  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> -earlycpio.o percpu-refcount.o
> +earlycpio.o percpu-refcount.o atomicio.o
>
>  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
>  lib-$(CONFIG_MMU) += ioremap.o
> diff --git a/lib/atomicio.c b/lib/atomicio.c
> new file mode 100644
> index 000..1750f9d
> --- /dev/null
> +++ b/lib/atomicio.c
> @@ -0,0 +1,27 @@
> +#include 
> +#include 
> +
> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> +/*
> + * Generic atomic MMIO modify.
> + *
> + * Allows thread-safe access to registers shared by unrelated subsystems.
> + * The access is protected by a single MMIO-wide lock.
> + *
> + * Optimized variants can be implemented on a per-architecture basis.
> + */
> +static DEFINE_RAW_SPINLOCK(__io_lock);
> +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> +{
> +   unsigned long flags;
> +   u32 value;
> +
> +   raw_spin_lock_irqsave(&__io_lock, flags);
> +   value = readl(reg) & ~mask;
> +   value |= (set & mask);
> +   writel(value, reg);
> +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> +
> +}
> +EXPORT_SYMBOL(atomic_io_modify);

 Why not the default case EXPORT_SYMBOL_GPL()?

>>>
>>> Because I copy-pasted the export from some other lib/.. :-)
>>>
>>> Mind explaining me the difference, why you say _GPL it's the default,
>>> and why EXPORT_SYMBOL is more frequently used in lib/ ?
>>
>> As the kernel is GPL it is the default case to mark new things as GPL 
>> symbols.
>> If your new feature is a core feature which is used by mostly everyone, 
>> EXPORT_SYMBOL()
>> is appropriate.
>> I.e. having kmalloc() and friends EXPORT_SYMBOL_GPL() would be a bad idea. :)
>> EXPORT_SYMBOL() seems to be often used in lib/ because most lib/ things are 
>> core features.
>>
> 
> In that case, EXPORT_SYMBOL is certainly the most appropriate one,
> for the reasons you stated above.

Okay, did not realize that your feature is that fundamental. :-)

Thanks,
//richard


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

Re: [PATCH v2] gpiolib: Fix crash when exporting non-existent gpio

[Daniel Santos]

hmm, git send-email didn't change my subject on the above message to 
"[PATCH v2]", not sure what I did wrong.  Sorry about that.


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

Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

[Ezequiel Garcia]

On Sat, Aug 24, 2013 at 10:35:34PM +0200, Richard Weinberger wrote:
> Am 24.08.2013 21:58, schrieb Ezequiel Garcia:
> > On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
> >> On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
> >>  wrote:
> >>> Some platforms have MMIO regions that are shared across orthogonal
> >>> subsystems. This commit implements a possible solution for the
> >>> thread-safe access of such regions through a spinlock-protected API.
> >>>
> >>> Concurrent access is protected with a single spinlock for the
> >>> entire MMIO address space. While this protects shared-registers,
> >>> it also serializes access to unrelated/unshared registers.
> >>>
> >>> Signed-off-by: Ezequiel Garcia 
> >>> ---
> >>>  include/linux/io.h |  5 +
> >>>  lib/Makefile   |  2 +-
> >>>  lib/atomicio.c | 27 +++
> >>>  3 files changed, 33 insertions(+), 1 deletion(-)
> >>>  create mode 100644 lib/atomicio.c
> >>>
> >>> diff --git a/include/linux/io.h b/include/linux/io.h
> >>> index f4f42fa..c331dcb 100644
> >>> --- a/include/linux/io.h
> >>> +++ b/include/linux/io.h
> >>> @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
> >>>  #define arch_phys_wc_add arch_phys_wc_add
> >>>  #endif
> >>>
> >>> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> >>> +/* Atomic MMIO-wide IO modify */
> >>> +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> >>> +#endif
> >>> +
> >>>  #endif /* _LINUX_IO_H */
> >>> diff --git a/lib/Makefile b/lib/Makefile
> >>> index 7baccfd..695d6e2 100644
> >>> --- a/lib/Makefile
> >>> +++ b/lib/Makefile
> >>> @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
> >>>  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
> >>>  proportions.o flex_proportions.o prio_heap.o ratelimit.o 
> >>> show_mem.o \
> >>>  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> >>> -earlycpio.o percpu-refcount.o
> >>> +earlycpio.o percpu-refcount.o atomicio.o
> >>>
> >>>  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
> >>>  lib-$(CONFIG_MMU) += ioremap.o
> >>> diff --git a/lib/atomicio.c b/lib/atomicio.c
> >>> new file mode 100644
> >>> index 000..1750f9d
> >>> --- /dev/null
> >>> +++ b/lib/atomicio.c
> >>> @@ -0,0 +1,27 @@
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> >>> +/*
> >>> + * Generic atomic MMIO modify.
> >>> + *
> >>> + * Allows thread-safe access to registers shared by unrelated subsystems.
> >>> + * The access is protected by a single MMIO-wide lock.
> >>> + *
> >>> + * Optimized variants can be implemented on a per-architecture basis.
> >>> + */
> >>> +static DEFINE_RAW_SPINLOCK(__io_lock);
> >>> +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> >>> +{
> >>> +   unsigned long flags;
> >>> +   u32 value;
> >>> +
> >>> +   raw_spin_lock_irqsave(&__io_lock, flags);
> >>> +   value = readl(reg) & ~mask;
> >>> +   value |= (set & mask);
> >>> +   writel(value, reg);
> >>> +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> >>> +
> >>> +}
> >>> +EXPORT_SYMBOL(atomic_io_modify);
> >>
> >> Why not the default case EXPORT_SYMBOL_GPL()?
> >>
> > 
> > Because I copy-pasted the export from some other lib/.. :-)
> > 
> > Mind explaining me the difference, why you say _GPL it's the default,
> > and why EXPORT_SYMBOL is more frequently used in lib/ ?
> 
> As the kernel is GPL it is the default case to mark new things as GPL symbols.
> If your new feature is a core feature which is used by mostly everyone, 
> EXPORT_SYMBOL()
> is appropriate.
> I.e. having kmalloc() and friends EXPORT_SYMBOL_GPL() would be a bad idea. :)
> EXPORT_SYMBOL() seems to be often used in lib/ because most lib/ things are 
> core features.
> 

In that case, EXPORT_SYMBOL is certainly the most appropriate one,
for the reasons you stated above.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpiolib: Fix crash when exporting non-existant gpio

[Daniel Santos]

On 08/24/2013 02:57 PM, Guenter Roeck wrote:


Looking into calling code, desc_to_gpio() is clearly not supposed to 
return an error,
and it will result in odd behavior if it returns -1. For example, the 
resulting debug

message of "gpio--1 (...) status ..." is not very useful.

It would make more sense to fix the calling code. You could for example
validate in affected functions if the gpio pin exists by not only
checking for desc but also for desc->chip. Another option might be
to have gpio_to_desc() return NULL if desc->chip is NULL.


Yes, you are correct of course.  I guess I was just being lazy. :) I'll 
re-submit.


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

Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

[Richard Weinberger]

Am 24.08.2013 21:58, schrieb Ezequiel Garcia:
> On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
>> On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
>>  wrote:
>>> Some platforms have MMIO regions that are shared across orthogonal
>>> subsystems. This commit implements a possible solution for the
>>> thread-safe access of such regions through a spinlock-protected API.
>>>
>>> Concurrent access is protected with a single spinlock for the
>>> entire MMIO address space. While this protects shared-registers,
>>> it also serializes access to unrelated/unshared registers.
>>>
>>> Signed-off-by: Ezequiel Garcia 
>>> ---
>>>  include/linux/io.h |  5 +
>>>  lib/Makefile   |  2 +-
>>>  lib/atomicio.c | 27 +++
>>>  3 files changed, 33 insertions(+), 1 deletion(-)
>>>  create mode 100644 lib/atomicio.c
>>>
>>> diff --git a/include/linux/io.h b/include/linux/io.h
>>> index f4f42fa..c331dcb 100644
>>> --- a/include/linux/io.h
>>> +++ b/include/linux/io.h
>>> @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
>>>  #define arch_phys_wc_add arch_phys_wc_add
>>>  #endif
>>>
>>> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
>>> +/* Atomic MMIO-wide IO modify */
>>> +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
>>> +#endif
>>> +
>>>  #endif /* _LINUX_IO_H */
>>> diff --git a/lib/Makefile b/lib/Makefile
>>> index 7baccfd..695d6e2 100644
>>> --- a/lib/Makefile
>>> +++ b/lib/Makefile
>>> @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
>>>  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
>>>  proportions.o flex_proportions.o prio_heap.o ratelimit.o 
>>> show_mem.o \
>>>  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
>>> -earlycpio.o percpu-refcount.o
>>> +earlycpio.o percpu-refcount.o atomicio.o
>>>
>>>  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
>>>  lib-$(CONFIG_MMU) += ioremap.o
>>> diff --git a/lib/atomicio.c b/lib/atomicio.c
>>> new file mode 100644
>>> index 000..1750f9d
>>> --- /dev/null
>>> +++ b/lib/atomicio.c
>>> @@ -0,0 +1,27 @@
>>> +#include 
>>> +#include 
>>> +
>>> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
>>> +/*
>>> + * Generic atomic MMIO modify.
>>> + *
>>> + * Allows thread-safe access to registers shared by unrelated subsystems.
>>> + * The access is protected by a single MMIO-wide lock.
>>> + *
>>> + * Optimized variants can be implemented on a per-architecture basis.
>>> + */
>>> +static DEFINE_RAW_SPINLOCK(__io_lock);
>>> +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
>>> +{
>>> +   unsigned long flags;
>>> +   u32 value;
>>> +
>>> +   raw_spin_lock_irqsave(&__io_lock, flags);
>>> +   value = readl(reg) & ~mask;
>>> +   value |= (set & mask);
>>> +   writel(value, reg);
>>> +   raw_spin_unlock_irqrestore(&__io_lock, flags);
>>> +
>>> +}
>>> +EXPORT_SYMBOL(atomic_io_modify);
>>
>> Why not the default case EXPORT_SYMBOL_GPL()?
>>
> 
> Because I copy-pasted the export from some other lib/.. :-)
> 
> Mind explaining me the difference, why you say _GPL it's the default,
> and why EXPORT_SYMBOL is more frequently used in lib/ ?

As the kernel is GPL it is the default case to mark new things as GPL symbols.
If your new feature is a core feature which is used by mostly everyone, 
EXPORT_SYMBOL()
is appropriate.
I.e. having kmalloc() and friends EXPORT_SYMBOL_GPL() would be a bad idea. :)
EXPORT_SYMBOL() seems to be often used in lib/ because most lib/ things are 
core features.

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

[PATCH v3] dma: add driver for R-Car HPB-DMAC

[Sergei Shtylyov]

From: Max Filippov 

Add support for HPB-DMAC found in Renesas R-Car SoCs, using 'shdma-base' DMA 
driver framework.

Based on the original patch by Phil Edworthy .

Signed-off-by: Max Filippov 
[Sergei: removed useless #include, sorted #include's, fixed HPB_DMA_TCR_MAX,
fixed formats and removed line breaks in the dev_dbg() calls, rephrased and
added IRQ # to the shdma_request_irq() failure message, added MODULE_AUTHOR(),
removed '__init'/'__exit' annotations from the probe()/remove() methods, removed
'__initdata' annotation from 'hpb_dmae_driver', fixed guard macro name in the
header file, fixed #define ASYNCRSTR_ASRST20, added #define ASYNCRSTR_ASRST24,
added the necessary runtime PM calls to the probe() and remove() methods,
handled errors returned by dma_async_device_register(), beautified comments
and #define's.]
Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'next' branch of Vinod Koul's 'slave-dma.git' repo. 

Changes in version 3:
- renamed all the register/bit #define's to include 'HBP_DMAE_' prefix; 
- switched from using __raw_{readl|writel}() to io{read|write}32() to add the
  barriers and fix register endianness to LE;
- added the necessary early return to set_slave() method;
- added the necessary runtime PM calls to the probe() and remove() methods;
- started handling errors returned by dma_async_device_register();
- removed '__exit' annotation from the remove() method;
- added the comment in desc_completed() method explaining why it's correct;
- beautified some commets.

Changes in version 2:
- removed '__init' annotation from the probe() method and removed '__initdata'
  annotation from 'hpb_dmae_driver';
- added the From: header to credit the real author.

 drivers/dma/sh/Kconfig|6 
 drivers/dma/sh/Makefile   |1 
 drivers/dma/sh/rcar-hpbdma.c  |  655 ++
 include/linux/platform_data/dma-rcar-hpbdma.h |  103 
 4 files changed, 765 insertions(+)

Index: slave-dma/drivers/dma/sh/Kconfig
===
--- slave-dma.orig/drivers/dma/sh/Kconfig
+++ slave-dma/drivers/dma/sh/Kconfig
@@ -22,3 +22,9 @@ config SUDMAC
depends on SH_DMAE_BASE
help
  Enable support for the Renesas SUDMAC controllers.
+
+config RCAR_HPB_DMAE
+   tristate "Renesas R-Car HPB DMAC support"
+   depends on SH_DMAE_BASE
+   help
+ Enable support for the Renesas R-Car series DMA controllers.
Index: slave-dma/drivers/dma/sh/Makefile
===
--- slave-dma.orig/drivers/dma/sh/Makefile
+++ slave-dma/drivers/dma/sh/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_SH_DMAE_BASE) += shdma-base.o shdma-of.o
 obj-$(CONFIG_SH_DMAE) += shdma.o
 obj-$(CONFIG_SUDMAC) += sudmac.o
+obj-$(CONFIG_RCAR_HPB_DMAE) += rcar-hpbdma.o
Index: slave-dma/drivers/dma/sh/rcar-hpbdma.c
===
--- /dev/null
+++ slave-dma/drivers/dma/sh/rcar-hpbdma.c
@@ -0,0 +1,655 @@
+/*
+ * Copyright (C) 2011-2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ *
+ * This file is based on the drivers/dma/sh/shdma.c
+ *
+ * Renesas SuperH DMA Engine support
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * - DMA of SuperH does not have Hardware DMA chain mode.
+ * - max DMA size is 16MB.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* DMA channel registers */
+#define HPB_DMAE_DSAR0 0x00
+#define HPB_DMAE_DDAR0 0x04
+#define HPB_DMAE_DTCR0 0x08
+#define HPB_DMAE_DSAR1 0x0C
+#define HPB_DMAE_DDAR1 0x10
+#define HPB_DMAE_DTCR1 0x14
+#define HPB_DMAE_DSASR 0x18
+#define HPB_DMAE_DDASR 0x1C
+#define HPB_DMAE_DTCSR 0x20
+#define HPB_DMAE_DPTR  0x24
+#define HPB_DMAE_DCR   0x28
+#define HPB_DMAE_DCMDR 0x2C
+#define HPB_DMAE_DSTPR 0x30
+#define HPB_DMAE_DSTSR 0x34
+#define HPB_DMAE_DDBGR 0x38
+#define HPB_DMAE_DDBGR20x3C
+#define HPB_DMAE_CHAN(n)   (0x40 * (n))
+
+/* DMA command register (DCMDR) bits */
+#define HPB_DMAE_DCMDR_BDOUT   BIT(7)
+#define HPB_DMAE_DCMDR_DQSPD   BIT(6)
+#define HPB_DMAE_DCMDR_DQSPC   BIT(5)
+#define HPB_DMAE_DCMDR_DMSPD   BIT(4)
+#define HPB_DMAE_DCMDR_DMSPC   BIT(3)
+#define HPB_DMAE_DCMDR_DQEND   BIT(2)
+#define HPB_DMAE_DCMDR_DNXTBIT(1)
+#define HPB_DMAE_DCMDR_DMENBIT(0)
+
+/* DMA forced stop register (DSTPR) bits */
+#define HPB_DMAE_DSTPR_DMSTP   BIT(0)
+
+/* DMA status register (DSTSR) bits */
+#define HPB_DMAE_DSTSR_DMSTS   BIT(0)
+
+/* DMA common registers */
+#define HPB_DMAE_DTIMR 0x00
+#define HPB_DMAE_DINTSR0   0x0C
+#define HPB_DMAE_DINTSR1   0x10
+#define HPB_DMA

Re: Unusually high system CPU usage with recent kernels

[Tibor Billes]

> From: Paul E. McKenney Sent: 08/24/13 02:18 AM
> On Fri, Aug 23, 2013 at 03:20:25PM +0200, Tibor Billes wrote:
> > > From: Paul E. McKenney Sent: 08/22/13 12:09 AM
> > > On Wed, Aug 21, 2013 at 11:05:51PM +0200, Tibor Billes wrote:
> > > > > From: Paul E. McKenney Sent: 08/21/13 09:12 PM
> > > > > On Wed, Aug 21, 2013 at 08:14:46PM +0200, Tibor Billes wrote:
> > > > > > > From: Paul E. McKenney Sent: 08/20/13 11:43 PM
> > > > > > > On Tue, Aug 20, 2013 at 10:52:26PM +0200, Tibor Billes wrote:
> > > > > > > > > From: Paul E. McKenney Sent: 08/20/13 04:53 PM
> > > > > > > > > On Tue, Aug 20, 2013 at 08:01:28AM +0200, Tibor Billes wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > I was using the 3.9.7 stable release and tried to upgrade 
> > > > > > > > > > to the 3.10.x series.
> > > > > > > > > > The 3.10.x series was showing unusually high (>75%) system 
> > > > > > > > > > CPU usage in some
> > > > > > > > > > situations, making things really slow. The latest stable I 
> > > > > > > > > > tried is 3.10.7.
> > > > > > > > > > I also tried 3.11-rc5, they both show this behaviour. This 
> > > > > > > > > > behaviour doesn't
> > > > > > > > > > show up when the system is idling, only when doing some CPU 
> > > > > > > > > > intensive work,
> > > > > > > > > > like compiling with multiple threads. Compiling with only 
> > > > > > > > > > one thread seems not
> > > > > > > > > > to trigger this behaviour.
> > > > > > > > > > 
> > > > > > > > > > To be more precise I did a `perf record -a` while compiling 
> > > > > > > > > > a large C++ program
> > > > > > > > > > with scons using 4 threads, the result is appended at the 
> > > > > > > > > > end of this email.
> > > > > > > > > 
> > > > > > > > > New one on me! You are running a mainstream system (x86_64), 
> > > > > > > > > so I am
> > > > > > > > > surprised no one else noticed.
> > > > > > > > > 
> > > > > > > > > Could you please send along your .config file?
> > > > > > > > 
> > > > > > > > Here it is
> > > > > > > 
> > > > > > > Interesting. I don't see RCU stuff all that high on the list, but
> > > > > > > the items I do see lead me to suspect RCU_FAST_NO_HZ, which has 
> > > > > > > some
> > > > > > > relevance to the otherwise inexplicable group of commits you 
> > > > > > > located
> > > > > > > with your bisection. Could you please rerun with 
> > > > > > > CONFIG_RCU_FAST_NO_HZ=n?
> > > > > > > 
> > > > > > > If that helps, there are some things I could try.
> > > > > > 
> > > > > > It did help. I didn't notice anything unusual when running with 
> > > > > > CONFIG_RCU_FAST_NO_HZ=n.
> > > > > 
> > > > > Interesting. Thank you for trying this -- and we at least have a
> > > > > short-term workaround for this problem. I will put a patch together
> > > > > for further investigation.
> > > > 
> > > > I don't specifically need this config option so I'm fine without it in
> > > > the long term, but I guess it's not supposed to behave like that.
> > > 
> > > OK, good, we have a long-term workload for your specific case,
> > > even better. ;-)
> > > 
> > > But yes, there are situations where RCU_FAST_NO_HZ needs to work
> > > a bit better. I hope you will bear with me with a bit more
> > > testing...
> > 
> > Don't worry, I will :) Unfortunately I didn't have time yesterday and I
> > won't have time today either. But I'll do what you asked tomorrow and I'll
> > send you the results.
> 
> Not a problem! I did find one issue that -might- help, please see
> the patch below. (Run with CONFIG_RCU_FAST_NO_HZ=y.)
> 
> Please let me know how it goes!

I applied the patch on top of 3.11-rc6, but it did not help, I'm still
hitting this issue.

Let me know if you have anything else that I can test!

Tibor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag

[Yann Droneaud]

KVM uses anon_inode_get() to allocate file descriptors as part
of some of its ioctls. But those ioctls are lacking a flag argument
allowing userspace to choose options for the newly opened file descriptor.

In such case it's advised to use O_CLOEXEC by default so that
userspace is allowed to choose, without race, if the file descriptor
is going to be inherited across exec().

This patch set O_CLOEXEC flag on all file descriptors created
with anon_inode_getfd() to not leak file descriptors across exec().

Signed-off-by: Yann Droneaud 
Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com

---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 arch/powerpc/kvm/book3s_64_vio.c| 2 +-
 arch/powerpc/kvm/book3s_hv.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 710d313..f7c9e8a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -1579,7 +1579,7 @@ int kvm_vm_ioctl_get_htab_fd(struct kvm *kvm, struct 
kvm_get_htab_fd *ghf)
ctx->first_pass = 1;
 
rwflag = (ghf->flags & KVM_GET_HTAB_WRITE) ? O_WRONLY : O_RDONLY;
-   ret = anon_inode_getfd("kvm-htab", &kvm_htab_fops, ctx, rwflag);
+   ret = anon_inode_getfd("kvm-htab", &kvm_htab_fops, ctx, rwflag | 
O_CLOEXEC);
if (ret < 0) {
kvm_put_kvm(kvm);
return ret;
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index b2d3f3b..54cf9bc 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -136,7 +136,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
mutex_unlock(&kvm->lock);
 
return anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
-   stt, O_RDWR);
+   stt, O_RDWR | O_CLOEXEC);
 
 fail:
if (stt) {
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index e8d51cb..3503829 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1556,7 +1556,7 @@ long kvm_vm_ioctl_allocate_rma(struct kvm *kvm, struct 
kvm_allocate_rma *ret)
if (!ri)
return -ENOMEM;
 
-   fd = anon_inode_getfd("kvm-rma", &kvm_rma_fops, ri, O_RDWR);
+   fd = anon_inode_getfd("kvm-rma", &kvm_rma_fops, ri, O_RDWR | O_CLOEXEC);
if (fd < 0)
kvm_release_rma(ri);
 
-- 
1.8.3.1

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

[PATCH 0/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag

[Yann Droneaud]

Hi,

Following a patchset asking to change calls to get_unused_flag() [1]
to use O_CLOEXEC, Alex Williamson [2][3] decided to change VFIO
to use the flag.

Since it's a related subsystem to KVM, using O_CLOEXEC for
file descriptors created by KVM might be applicable too.

I'm suggesting to change calls to anon_inode_getfd() to use O_CLOEXEC
as default flag.

This patchset should be reviewed to not break existing userspace program.

BTW, if it's not applicable, I would suggest that new ioctls be added to
KVM subsystem, those ioctls would have a "flag" field added to their arguments.
Such "flag" would let userspace choose the open flag to use.
See for example other APIs using anon_inode_getfd() such as fanotify,
inotify, signalfd and timerfd.

You might be interested to read:

- Secure File Descriptor Handling (Ulrich Drepper, 2008)
  http://udrepper.livejournal.com/20407.html

- Excuse me son, but your code is leaking !!! (Dan Walsh, March 2012) 
  http://danwalsh.livejournal.com/53603.html

Regards.

[1] http://lkml.kernel.org/r/cover.1376327678.git.ydrone...@opteya.com
[2] http://lkml.kernel.org/r/1377186804.25163.17.ca...@ul30vt.home
[3] http://lkml.kernel.org/r/20130822171744.1297.13711.st...@bling.home

Yann Droneaud (2):
  kvm: use anon_inode_getfd() with O_CLOEXEC flag
  ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag

 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 arch/powerpc/kvm/book3s_64_vio.c| 2 +-
 arch/powerpc/kvm/book3s_hv.c| 2 +-
 virt/kvm/kvm_main.c | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.8.3.1

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

[PATCH 1/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag

[Yann Droneaud]

KVM uses anon_inode_get() to allocate file descriptors as part
of some of its ioctls. But those ioctls are lacking a flag argument
allowing userspace to choose options for the newly opened file descriptor.

In such case it's advised to use O_CLOEXEC by default so that
userspace is allowed to choose, without race, if the file descriptor
is going to be inherited across exec().

This patch set O_CLOEXEC flag on all file descriptors created
with anon_inode_getfd() to not leak file descriptors across exec().

Signed-off-by: Yann Droneaud 
Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com
---
 virt/kvm/kvm_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 89f74d1..d65cc0c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1896,7 +1896,7 @@ static struct file_operations kvm_vcpu_fops = {
  */
 static int create_vcpu_fd(struct kvm_vcpu *vcpu)
 {
-   return anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, O_RDWR);
+   return anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, O_RDWR | 
O_CLOEXEC);
 }
 
 /*
@@ -2306,7 +2306,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
return ret;
}
 
-   ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR);
+   ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | 
O_CLOEXEC);
if (ret < 0) {
ops->destroy(dev);
return ret;
@@ -2590,7 +2590,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
return r;
}
 #endif
-   r = anon_inode_getfd("kvm-vm", &kvm_vm_fops, kvm, O_RDWR);
+   r = anon_inode_getfd("kvm-vm", &kvm_vm_fops, kvm, O_RDWR | O_CLOEXEC);
if (r < 0)
kvm_put_kvm(kvm);
 
-- 
1.8.3.1

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

Re: Unusually high system CPU usage with recent kernels

[Tibor Billes]

From: Paul E. McKenney Sent: 08/22/13 12:09 AM
> On Wed, Aug 21, 2013 at 11:05:51PM +0200, Tibor Billes wrote:
> > > From: Paul E. McKenney Sent: 08/21/13 09:12 PM
> > > On Wed, Aug 21, 2013 at 08:14:46PM +0200, Tibor Billes wrote:
> > > > > From: Paul E. McKenney Sent: 08/20/13 11:43 PM
> > > > > On Tue, Aug 20, 2013 at 10:52:26PM +0200, Tibor Billes wrote:
> > > > > > > From: Paul E. McKenney Sent: 08/20/13 04:53 PM
> > > > > > > On Tue, Aug 20, 2013 at 08:01:28AM +0200, Tibor Billes wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I was using the 3.9.7 stable release and tried to upgrade to 
> > > > > > > > the 3.10.x series.
> > > > > > > > The 3.10.x series was showing unusually high (>75%) system CPU 
> > > > > > > > usage in some
> > > > > > > > situations, making things really slow. The latest stable I 
> > > > > > > > tried is 3.10.7.
> > > > > > > > I also tried 3.11-rc5, they both show this behaviour. This 
> > > > > > > > behaviour doesn't
> > > > > > > > show up when the system is idling, only when doing some CPU 
> > > > > > > > intensive work,
> > > > > > > > like compiling with multiple threads. Compiling with only one 
> > > > > > > > thread seems not
> > > > > > > > to trigger this behaviour.
> > > > > > > > 
> > > > > > > > To be more precise I did a `perf record -a` while compiling a 
> > > > > > > > large C++ program
> > > > > > > > with scons using 4 threads, the result is appended at the end 
> > > > > > > > of this email.
> > > > > > > 
> > > > > > > New one on me! You are running a mainstream system (x86_64), so I 
> > > > > > > am
> > > > > > > surprised no one else noticed.
> > > > > > > 
> > > > > > > Could you please send along your .config file?
> > > > > > 
> > > > > > Here it is
> > > > > 
> > > > > Interesting. I don't see RCU stuff all that high on the list, but
> > > > > the items I do see lead me to suspect RCU_FAST_NO_HZ, which has some
> > > > > relevance to the otherwise inexplicable group of commits you located
> > > > > with your bisection. Could you please rerun with 
> > > > > CONFIG_RCU_FAST_NO_HZ=n?
> > > > > 
> > > > > If that helps, there are some things I could try.
> > > > 
> > > > It did help. I didn't notice anything unusual when running with 
> > > > CONFIG_RCU_FAST_NO_HZ=n.
> > > 
> > > Interesting. Thank you for trying this -- and we at least have a
> > > short-term workaround for this problem. I will put a patch together
> > > for further investigation.
> > 
> > I don't specifically need this config option so I'm fine without it in
> > the long term, but I guess it's not supposed to behave like that.
> 
> OK, good, we have a long-term workload for your specific case,
> even better. ;-)
> 
> But yes, there are situations where RCU_FAST_NO_HZ needs to work
> a bit better. I hope you will bear with me with a bit more
> testing...
>
> > > In the meantime, could you please tell me how you were measuring
> > > performance for your kernel builds? Wall-clock time required to complete
> > > one build? Number of builds completed per unit time? Something else?
> > 
> > Actually, I wasn't all this sophisticated. I have a system monitor
> > applet on my top panel (using MATE, Linux Mint), four little graphs,
> > one of which shows CPU usage. Different colors indicate different kind
> > of CPU usage. Blue shows user space usage, red shows system usage, and
> > two more for nice and iowait. During a normal compile it's almost
> > completely filled with blue user space CPU usage, only the top few
> > pixels show some iowait and system usage. With CONFIG_RCU_FAST_NO_HZ
> > set, about 3/4 of the graph was red system CPU usage, the rest was
> > blue. So I just looked for a pile of red on my graphs when I tested
> > different kernel builds. But also compile speed was horrible I couldn't
> > wait for the build to finish. Even the UI got unresponsive.
> 
> We have been having problems with CPU accounting, but this one looks
> quite real.
> 
> > Now I did some measuring. In the normal case a compile finished in 36
> > seconds, compiled 315 object files. Here are some output lines from
> > dstat -tasm --vm during compile:
> > system total-cpu-usage -dsk/total- -net/total- ---paging-- 
> > ---system-- swap--- --memory-usage- -virtual-memory
> >     time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | 
> > int   csw | used  free| used  buff  cach  free|majpf minpf alloc  free
> > 21-08 21:48:05| 91   8   2   0   0   0|   0  5852k|   0     0 |   0     0 
> > |1413  1772 |   0  7934M| 581M 58.0M  602M 6553M|   0    71k   46k   54k
> > 21-08 21:48:06| 93   6   1   0   0   0|   0  2064k| 137B  131B|   0     0 
> > |1356  1650 |   0  7934M| 649M 58.0M  604M 6483M|   0    72k   47k   28k
> > 21-08 21:48:07| 86  11   4   0   0   0|   0  5872k|   0     0 |   0     0 
> > |2000  2991 |   0  7934M| 577M 58.0M  627M 6531M|   0    99k   67k   79k
> > 21-08 21:48:08| 87   9   3   0   0   0|   0  2840k|   0     0 |   0     0 
>

Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

[Ezequiel Garcia]

On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
> On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
>  wrote:
> > Some platforms have MMIO regions that are shared across orthogonal
> > subsystems. This commit implements a possible solution for the
> > thread-safe access of such regions through a spinlock-protected API.
> >
> > Concurrent access is protected with a single spinlock for the
> > entire MMIO address space. While this protects shared-registers,
> > it also serializes access to unrelated/unshared registers.
> >
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  include/linux/io.h |  5 +
> >  lib/Makefile   |  2 +-
> >  lib/atomicio.c | 27 +++
> >  3 files changed, 33 insertions(+), 1 deletion(-)
> >  create mode 100644 lib/atomicio.c
> >
> > diff --git a/include/linux/io.h b/include/linux/io.h
> > index f4f42fa..c331dcb 100644
> > --- a/include/linux/io.h
> > +++ b/include/linux/io.h
> > @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
> >  #define arch_phys_wc_add arch_phys_wc_add
> >  #endif
> >
> > +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> > +/* Atomic MMIO-wide IO modify */
> > +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> > +#endif
> > +
> >  #endif /* _LINUX_IO_H */
> > diff --git a/lib/Makefile b/lib/Makefile
> > index 7baccfd..695d6e2 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
> >  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
> >  proportions.o flex_proportions.o prio_heap.o ratelimit.o 
> > show_mem.o \
> >  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> > -earlycpio.o percpu-refcount.o
> > +earlycpio.o percpu-refcount.o atomicio.o
> >
> >  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
> >  lib-$(CONFIG_MMU) += ioremap.o
> > diff --git a/lib/atomicio.c b/lib/atomicio.c
> > new file mode 100644
> > index 000..1750f9d
> > --- /dev/null
> > +++ b/lib/atomicio.c
> > @@ -0,0 +1,27 @@
> > +#include 
> > +#include 
> > +
> > +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> > +/*
> > + * Generic atomic MMIO modify.
> > + *
> > + * Allows thread-safe access to registers shared by unrelated subsystems.
> > + * The access is protected by a single MMIO-wide lock.
> > + *
> > + * Optimized variants can be implemented on a per-architecture basis.
> > + */
> > +static DEFINE_RAW_SPINLOCK(__io_lock);
> > +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> > +{
> > +   unsigned long flags;
> > +   u32 value;
> > +
> > +   raw_spin_lock_irqsave(&__io_lock, flags);
> > +   value = readl(reg) & ~mask;
> > +   value |= (set & mask);
> > +   writel(value, reg);
> > +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> > +
> > +}
> > +EXPORT_SYMBOL(atomic_io_modify);
> 
> Why not the default case EXPORT_SYMBOL_GPL()?
> 

Because I copy-pasted the export from some other lib/.. :-)

Mind explaining me the difference, why you say _GPL it's the default,
and why EXPORT_SYMBOL is more frequently used in lib/ ?

$ git grep EXPORT_SYMBOL lib/ | wc -l
598
$ git grep EXPORT_SYMBOL_GPL lib/ | wc -l
117

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpiolib: Fix crash when exporting non-existant gpio

[Guenter Roeck]

On 08/24/2013 11:48 AM, danielfsan...@att.net wrote:

I got this on an RPi and I can't find anything specific to that.
Besides, it's clearly wrong to try to access desc->chip when we have
just tested that it may be NULL at drivers/gpio/gpiolib.c:1409:

chip = desc->chip;
if (chip == NULL)
goto done;



done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
 desc_to_gpio(desc), label ? : "?", status);

To reproduce, just pick an invalid gpio nubmer and:

echo -n 248 > /sys/class/gpio/export

However, I wasn't able to reproduce it on my laptop, maybe because I
don't have any real gpio chips there, not sure.  More info on RPi bug
report: https://github.com/raspberrypi/linux/issues/364

[  222.961384] Unable to handle kernel NULL pointer dereference at
virtual address 0044
[  222.969486] pgd = d97d
[  222.972190] [0044] *pgd=1aaca831, *pte=, *ppte=
[  222.978483] Internal error: Oops: 17 [#1] PREEMPT ARM
---
  drivers/gpio/gpiolib.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d6413b2..e547f75f8b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -136,7 +136,7 @@ static struct gpio_desc *gpio_to_desc(unsigned gpio)
   */
  static int desc_to_gpio(const struct gpio_desc *desc)
  {
-   return desc->chip->base + gpio_chip_hwgpio(desc);
+   return desc->chip ?  desc->chip->base + gpio_chip_hwgpio(desc) : -1;
  }



Looking into calling code, desc_to_gpio() is clearly not supposed to return an 
error,
and it will result in odd behavior if it returns -1. For example, the resulting 
debug
message of "gpio--1 (...) status ..." is not very useful.

It would make more sense to fix the calling code. You could for example
validate in affected functions if the gpio pin exists by not only
checking for desc but also for desc->chip. Another option might be
to have gpio_to_desc() return NULL if desc->chip is NULL.

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: [RFC PATCH 3/4] gcov: compile specific gcov implementation based on gcc version

[Frantisek Hrbata]

On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 17:15, Peter Oberparleiter wrote:
> > On 23.08.2013 10:39, Frantisek Hrbata wrote:
> >> Compile the correct gcov implementation file for a specific gcc version. In
> >> the future, if another file is added, the conditions will need to be 
> >> somehow
> >> adjusted to if-elif-else case, but at this point the simple cc-ifversion 
> >> should
> >> be enough.
> 
> As promised, I'm also adding the patch that makes the format-specific part
> of gcov-kernel a loadable kernel module:
> 
> ---
> kernel: gcov: make format-specific code loadable
> 
> Turn the format-specific part of gcov-kernel into a loadable kernel
> module. This enables the use of gcov-kernel with kernel modules
> that were compiled with a version of GCC that produces a different
> gcov format when compared to the version of GCC that was used to
> compile the kernel.

If I understand it correctly, this would mean that you will be able to use only
one implementation of gcov format at the time. Meaning you will be able to get
coverage data for module, but not for kernel if it was compiled with different
gcc(gcda format). This is probably ok if you work only on your module, but I'm
not sure this is generally the right approach. In this case I would probably
rather see some support for more gcov formats at the same time(e.g. set of
callback operations per gcov version). Again I'm probably missing something, but
I still cannot see reason why to add such feature. If you want gcov support just
compile your kernel and modules with the same gcc version(gcda format). But if
this is really needed maybe it would be better to consider some parallel support
for more gcov formats based on the gcov_info version.

Would it be possible to add support for the modified gcc 4.7 gcov format and
deal with this later? I can incorporate your changes: iter to use buffer,
.init_array for modules and possibility to explicitly select the gcda format.
In this case we will have at least the basic support in kernel. This is just me
thinking out loud.

Many thanks Peter!

> 
> Signed-off-by: Peter Oberparleiter 
> ---
>  kernel/gcov/Kconfig  |   19 +--
>  kernel/gcov/Makefile |7 ---
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -29,8 +29,23 @@ config GCOV_KERNEL
>   and:
>   GCOV_PROFILE := n
> 
> - Note that the debugfs filesystem has to be mounted to access
> - profiling data.
> + Note that GCOV_KERNEL_FS has to specified as well and the debugfs
> + filesystem has to be mounted to access profiling data.
> +
> +config GCOV_KERNEL_FS
> + tristate "Provide gcov data files in debugfs"
> + depends on GCOV_KERNEL
> + default y
> + ---help---
> + Make profiling data available in debugfs at /sys/kernel/debug/gcov.
> +
> + Say M if you want to enable collecting coverage data for kernel modules
> + which are compiled using a gcc version different from the one that
> + was used to compile the kernel. In that case, re-compile the gcov
> + kernel module with corresponding format support and load that module
> + instead.
> +
> + If unsure, say Y.
> 
>  config GCOV_PROFILE_ALL
>   bool "Profile entire Kernel"
> --- a/kernel/gcov/Makefile
> +++ b/kernel/gcov/Makefile
> @@ -13,10 +13,11 @@ else
>cc-ver := $(call cc-version)
>  endif
> 
> -obj-$(CONFIG_GCOV_KERNEL) := base.o fs.o
> +obj-$(CONFIG_GCOV_KERNEL) += base.o
> +obj-$(CONFIG_GCOV_KERNEL_FS) += gcov.o
> 
>  ifeq ($(call if-lt, $(cc-ver), 0407),1)
> -  obj-$(CONFIG_GCOV_KERNEL) += gcc_3_4.o
> +  gcov-objs += fs.o gcc_3_4.o
>  else
> -  obj-$(CONFIG_GCOV_KERNEL) += gcc_4_7.o
> +  gcov-objs += fs.o gcc_4_7.o
>  endif
> 
> -- 
> Peter Oberparleiter
> Linux on System z Development - IBM Germany
> 

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

Re: [PATCH] ARM: dts: add AM33XX EDMA support

[Sergei Shtylyov]

Hello.

On 08/24/2013 10:33 PM, Joel Fernandes wrote:


Updating CC with Matt's current email address.



From: Matt Porter 



Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt



Joel: Drop DT entries that are non-hardware-description for now as discussed
in [1]



[1] https://patchwork.kernel.org/patch/2226761/



Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
Signed-off-by: Sebastian Andrzej Siewior 
---
Could someone please pick this up?



   arch/arm/boot/dts/am33xx.dtsi | 12 
   1 file changed, 12 insertions(+)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
   reg = <0x4820 0x1000>;
   };

+edma: edma@4900 {



The node should be named "dma-controller", not "edma",according to ePAPR
section 2.2.2:



http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf



So you mean something like the following?



edma: dma-controller@4900 {
   ...
}


   Yes, exactly.


Thanks,



-Joel


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 tip/core/rcu 1/5] rcu: Add duplicate-callback tests to rcutorture

[Mathieu Desnoyers]

* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
[...]
> The result is as follows.  Better?

Hi Paul,

Pitching in late in the thread, so that I can get a share of the fun ;-)

>   Thanx, Paul
> 
> #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> static void rcu_torture_leak_cb(struct rcu_head *rhp)
> {
> }
> 
> static void rcu_torture_err_cb(struct rcu_head *rhp)
> {
>   /*
>* This -might- happen due to race conditions, but is unlikely.
>* The scenario that leads to this happening is that the
>* first of the pair of duplicate callbacks is queued,
>* someone else starts a grace period that includes that
>* callback, then the second of the pair must wait for the
>* next grace period.  Unlikely, but can happen.  If it
>* does happen, the debug-objects subsystem won't have splatted.
>*/
>   pr_alert("rcutorture: duplicated callback was invoked.\n");
> }
> #endif /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> 

Hrm. Putting an #ifdef within a function when not utterly needed is
usually a bad idea. How about:

/*
 * Verify that double-free causes debug-objects to complain, but only
 * if CONFIG_DEBUG_OBJECTS_RCU_HEAD=y.  Otherwise, say that the test
 * cannot be carried out.
 */
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
static void rcu_test_debug_objects(void)
{
struct rcu_head rh1;
struct rcu_head rh2;
 
init_rcu_head_on_stack(&rh1);
init_rcu_head_on_stack(&rh2);
pr_alert("rcutorture: WARN: Duplicate call_rcu() test starting.\n");
preempt_disable(); /* Prevent preemption from interrupting test. */
rcu_read_lock(); /* Make it impossible to finish a grace period. */
call_rcu(&rh1, rcu_torture_leak_cb); /* Start grace period. */
local_irq_disable(); /* Make it harder to start a new grace period. */
call_rcu(&rh2, rcu_torture_leak_cb);
call_rcu(&rh2, rcu_torture_err_cb); /* Duplicate callback. */
local_irq_enable();
rcu_read_unlock();
preempt_enable();
rcu_barrier();
pr_alert("rcutorture: WARN: Duplicate call_rcu() test complete.\n");
destroy_rcu_head_on_stack(&rh1);
destroy_rcu_head_on_stack(&rh2);
}
#else /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
static void rcu_test_debug_objects(void)
{
pr_alert("rcutorture: !CONFIG_DEBUG_OBJECTS_RCU_HEAD, not testing 
duplicate call_rcu()\n");
}
#endif /* #else #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */


More comments inlined in the code below,

> /*
>  * Verify that double-free causes debug-objects to complain, but only
>  * if CONFIG_DEBUG_OBJECTS_RCU_HEAD=y.  Otherwise, say that the test
>  * cannot be carried out.
>  */
> static void rcu_test_debug_objects(void)
> {
> #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
>   struct rcu_head rh1;
>   struct rcu_head rh2;
> 
>   init_rcu_head_on_stack(&rh1);
>   init_rcu_head_on_stack(&rh2);
>   pr_alert("rcutorture: WARN: Duplicate call_rcu() test starting.\n");
>   preempt_disable(); /* Prevent preemption from interrupting test. */
>   rcu_read_lock(); /* Make it impossible to finish a grace period. */
>   call_rcu(&rh1, rcu_torture_leak_cb); /* Start grace period. */

Are we really "starting" a grace period ? If rcu_test_debug_objects() is
executed after some callbacks are already queued, are we, by definition,
"starting" the grace period ?

Also, I find it weird to have, in that order:

1) preempt_disable()
2) rcu_read_lock()
3) local_irq_disable()

I would rather expect:

1) rcu_read_lock()
2) preempt_disable()
3) local_irq_disable()

So they come in increasing order of impact on the system: with
non-preemptable RCU, the read-lock and preempt disable mean the same
thing, however, with preemptable RCU, the impact of preempt disable
seems larger than the impact of RCU read lock: preemption is still
enabled when within a RCU critical section. Both will work, but I find
this call order slightly weird.

Also, if your goal is to increase the chances that call_rcu() enqueues
both callbacks into the same grace period, you might want to issue a
rcu_barrier() early in this function, so that call_rcu() has even more
chances to enqueue the callbacks into the same grace period.

However, if you care about testing enqueue into same _and_ different
grace periods, you might want to turn this single-shot test into a
stress-test by calling it repeatedly.

Thanks!

Mathieu

>   local_irq_disable(); /* Make it harder to start a new grace period. */
>   call_rcu(&rh2, rcu_torture_leak_cb);
>   call_rcu(&rh2, rcu_torture_err_cb); /* Duplicate callback. */
>   local_irq_enable();
>   rcu_read_unlock();
>   preempt_enable();
>   rcu_barrier();
>   pr_alert("rcutorture: WARN: Duplicate call_rcu() test complete.\n");
>   destroy_rcu_head_on_stack(&rh1);
>   destroy_rcu_head_on_stack(&rh2);
> #else /* #ifdef CONFIG_DEBUG_OBJECTS_RCU

[PATCH] net/cadence/macb: fix kernel Oops if no PHY were discovered during probe

[Boris BREZILLON]

Test the presence of a PHY device before printing attached PHY
informations.

Signed-off-by: Boris BREZILLON 
---
 drivers/net/ethernet/cadence/macb.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index e866608..fd3b67f 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1868,8 +1868,10 @@ static int __init macb_probe(struct platform_device 
*pdev)
dev->irq, dev->dev_addr);
 
phydev = bp->phy_dev;
-   netdev_info(dev, "attached PHY driver [%s] (mii_bus:phy_addr=%s, 
irq=%d)\n",
-   phydev->drv->name, dev_name(&phydev->dev), phydev->irq);
+   if (phydev)
+   netdev_info(dev, "attached PHY driver [%s] 
(mii_bus:phy_addr=%s, irq=%d)\n",
+   phydev->drv->name, dev_name(&phydev->dev),
+   phydev->irq);
 
return 0;
 
-- 
1.7.9.5

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

Re: [RFC PATCH 3/4] gcov: compile specific gcov implementation based on gcc version

[Frantisek Hrbata]

On Fri, Aug 23, 2013 at 05:15:19PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > Compile the correct gcov implementation file for a specific gcc version. In
> > the future, if another file is added, the conditions will need to be somehow
> > adjusted to if-elif-else case, but at this point the simple cc-ifversion 
> > should
> > be enough.
> 
> Looks good, though I think this could be merged into the main 4.7 format 
> patch,
> since without it, the 4.7 code will never be reached.

Sure, I can merge these two patches.

> 
> Also it is my understanding that there are some distribution-specific versions
> of GCC that include the 4.7. gcov format code but report GCC version 4.6. With
> the auto-detection code implemented like this, gcov-kernel won't work 
> correctly.
> For that purpose I've implemented a configuration option to allow users to
> force a specific version of gcov format.

Ah, I was not aware of this inconsistency in versioning. This raises a question
if it would not be better to deal directly with version in the gcov_info
instead of these config options. This would of course mean some kind of gcov
operations callbacks per gcov version(you already mentioned the file
operations approach).

> 
> I'm attaching the corresponding patch below:
> 
> ---
> kernel: gcov: make data format configurable
> 
> Make the format of the generated gcov data configurable. This may be
> required for example for pre-4.7 GCCs that contain the 4.7 gcov data
> format changes.
> 
> Signed-off-by: Peter Oberparleiter 
> ---
>  kernel/gcov/Kconfig  |   30 ++
>  kernel/gcov/Makefile |   21 +++--
>  2 files changed, 49 insertions(+), 2 deletions(-)
> 
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -46,4 +46,34 @@ config GCOV_PROFILE_ALL
>   larger and run slower. Also be sure to exclude files from profiling
>   which are not linked to the kernel image to prevent linker errors.
> 
> +choice
> + prompt "Specify GCOV format"
> + depends on GCOV_KERNEL
> + default GCOV_FORMAT_AUTODETECT
> + ---help---
> + The gcov format is usually determined by the GCC version, but there are
> + exceptions where format changes are integrated in lower-version GCCs.
> + In such a case use this option to adjust the format used in the kernel
> + accordingly.
> +
> + If unsure, choose "Autodetect".
> +
> +config GCOV_FORMAT_AUTODETECT
> + bool "Autodetect"
> + ---help---
> + Select this option to use the format that corresponds to your GCC
> + version.
> +
> +config GCOV_FORMAT_3_4
> + bool "GCC 3.4 format"
> + ---help---
> + Select this option to use the format defined by GCC 3.4.
> +
> +config GCOV_FORMAT_4_7
> + bool "GCC 4.7 format"
> + ---help---
> + Select this option to use the format defined by GCC 4.7.
> +
> +endchoice
> +
>  endmenu
> --- a/kernel/gcov/Makefile
> +++ b/kernel/gcov/Makefile
> @@ -1,5 +1,22 @@
>  ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"'
> 
> +# if-lt
> +# Usage VAR := $(call if-lt, $(a), $(b))
> +# Returns 1 if (a < b)
> +if-lt = $(shell [ $(1) -lt $(2) ] && echo 1)
> +
> +ifeq ($(CONFIG_GCOV_FORMAT_3_4),y)
> +  cc-ver := 0304
> +else ifeq ($(CONFIG_GCOV_FORMAT_4_7),y)
> +  cc-ver := 0407
> +else
> +  cc-ver := $(call cc-version)
> +endif
> +
>  obj-$(CONFIG_GCOV_KERNEL) := base.o fs.o
> -obj-$(CONFIG_GCOV_KERNEL) += $(call cc-ifversion, -lt, 0407, gcc_3_4.o)
> -obj-$(CONFIG_GCOV_KERNEL) += $(call cc-ifversion, -ge, 0407, gcc_4_7.o)
> +
> +ifeq ($(call if-lt, $(cc-ver), 0407),1)
> +  obj-$(CONFIG_GCOV_KERNEL) += gcc_3_4.o
> +else
> +  obj-$(CONFIG_GCOV_KERNEL) += gcc_4_7.o
> +endif
> 
> 
> -- 
> Peter Oberparleiter
> Linux on System z Development - IBM Germany
> 

-- 
Frantisek Hrbata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpiolib: Fix crash when exporting non-existant gpio

[danielfsantos]

I got this on an RPi and I can't find anything specific to that.
Besides, it's clearly wrong to try to access desc->chip when we have
just tested that it may be NULL at drivers/gpio/gpiolib.c:1409:

chip = desc->chip;
if (chip == NULL)
goto done;



done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
 desc_to_gpio(desc), label ? : "?", status);

To reproduce, just pick an invalid gpio nubmer and:

echo -n 248 > /sys/class/gpio/export

However, I wasn't able to reproduce it on my laptop, maybe because I
don't have any real gpio chips there, not sure.  More info on RPi bug
report: https://github.com/raspberrypi/linux/issues/364

[  222.961384] Unable to handle kernel NULL pointer dereference at
virtual address 0044
[  222.969486] pgd = d97d
[  222.972190] [0044] *pgd=1aaca831, *pte=, *ppte=
[  222.978483] Internal error: Oops: 17 [#1] PREEMPT ARM
---
 drivers/gpio/gpiolib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d6413b2..e547f75f8b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -136,7 +136,7 @@ static struct gpio_desc *gpio_to_desc(unsigned gpio)
  */
 static int desc_to_gpio(const struct gpio_desc *desc)
 {
-   return desc->chip->base + gpio_chip_hwgpio(desc);
+   return desc->chip ?  desc->chip->base + gpio_chip_hwgpio(desc) : -1;
 }
 
 
-- 
1.8.1.5

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

Re: [PATCH] Documentation/trace: Correcting and extending tracepoint documentation

[Mathieu Desnoyers]

* Zoltan Kiss (zoltan.k...@citrix.com) wrote:
> The sample missed the moving of the header files into the events subdirectory.
> I've also extended it based on the existing headers, and mentioned the tiny
> but important role of CREATE_TRACE_POINTS.

Given that we expect tracepoints to be used though the TRACE_EVENT
wrapper, it makes sense indeed. A small nit below:

> 
> Signed-off-by: Zoltan Kiss 
> ---
>  Documentation/trace/tracepoints.txt |   19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/trace/tracepoints.txt 
> b/Documentation/trace/tracepoints.txt
> index da49437..e8e3c4b 100644
> --- a/Documentation/trace/tracepoints.txt
> +++ b/Documentation/trace/tracepoints.txt
> @@ -40,7 +40,13 @@ Two elements are required for tracepoints :
>  
>  In order to use tracepoints, you should include linux/tracepoint.h.
>  
> -In include/trace/subsys.h :
> +In include/trace/events/subsys.h :
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM subsys
> +
> +#if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SUBSYS_H
>  
>  #include 
>  
> @@ -48,10 +54,16 @@ DECLARE_TRACE(subsys_eventname,
>   TP_PROTO(int firstarg, struct task_struct *p),
>   TP_ARGS(firstarg, p));
>  
> +#endif /* _TRACE_SUBSYS_H */
> +
> +/* This part must be outside protection */
> +#include 
> +
>  In subsys/file.c (where the tracing statement must be added) :
>  
> -#include 
> +#include 
>  
> +#define CREATE_TRACE_POINTS
>  DEFINE_TRACE(subsys_eventname);
>  
>  void somefct(void)
> @@ -72,6 +84,9 @@ Where :
>  - TP_ARGS(firstarg, p) are the parameters names, same as found in the
>prototype.
>  
> +- if you use the header in multiple source files, #define CREATE_TRACE_POINTS
> +  should appear only in one source file

Missing dot at the end of the sentence above.

Other than that,

Acked-by: Mathieu Desnoyers 

Thanks!

Mathieu

> +
>  Connecting a function (probe) to a tracepoint is done by providing a
>  probe (function to call) for the specific tracepoint through
>  register_trace_subsys_eventname().  Removing a probe is done through
> -- 
> 1.7.9.5
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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: Proposed stable release changes

[Stefan Richter]

On Aug 21 Steven Rostedt wrote:
> I guess the other question to ask is, how long does it take for a
> problem to appear after hitting mainline? If a problem is found in -rc4
> before -rc5 comes out, then this would be sufficient. But if the
> problem from -rc4 isn't found till -rc6 then that tells us something
> too.

The estimate of one or two RC periods applies to hardware/ workloads which
everyone has or which wasn't supported by the previous release.  For less
widely used hardware/ workloads which has been supported for years already,
it's more like between 2.5 months ( = a mainline kernel release period)
and more than a year ( = two release periods of typical distributions).
-- 
Stefan Richter
-=-===-= =--- ==---
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

/proc/pid/fd && anon_inode_fops

[Oleg Nesterov]

Sorry for off-topic, I am just curios.

On 08/22, Willy Tarreau wrote:
>
> It's not only that, it also supports sockets and pipes that you can access
> via /proc/pid/fd and not via a real symlink which would try to open eg
> "pipe:[23456]" instead of the real file.

But sock_no_open() disallows this, and for good reason I guess.

I am wondering, perhaps anon_inode should do the same? I do not
see any problem, but it looks pointless and misleading to allow
to open a file you can do nothing with.

Or is there any reason why, say, open("anon_inode:[perf_event]")
should succeed?

Thanks,

Oleg.

--- x/fs/anon_inodes.c
+++ x/fs/anon_inodes.c
@@ -24,7 +24,15 @@
 
 static struct vfsmount *anon_inode_mnt __read_mostly;
 static struct inode *anon_inode_inode;
-static const struct file_operations anon_inode_fops;
+
+static int anon_open(struct inode *inode, struct file *file)
+{
+   return -ENXIO;
+}
+
+static const struct file_operations anon_inode_fops = {
+   .open = anon_open,
+};
 
 /*
  * anon_inodefs_dname() is called from d_path().

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

Re: [PATCH] ARM: dts: add AM33XX EDMA support

[Joel Fernandes]

Updating CC with Matt's current email address.

On 08/24/2013 01:02 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 08/23/2013 11:06 PM, Sebastian Andrzej Siewior wrote:
> 
>> From: Matt Porter 
> 
>> Adds AM33XX EDMA support to the am33xx.dtsi as documented in
>> Documentation/devicetree/bindings/dma/ti-edma.txt
> 
>> Joel: Drop DT entries that are non-hardware-description for now as discussed
>> in [1]
> 
>> [1] https://patchwork.kernel.org/patch/2226761/
> 
>> Signed-off-by: Matt Porter 
>> Signed-off-by: Joel A Fernandes 
>> Signed-off-by: Sebastian Andrzej Siewior 
>> ---
>> Could someone please pick this up?
> 
>>   arch/arm/boot/dts/am33xx.dtsi | 12 
>>   1 file changed, 12 insertions(+)
> 
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 38b446b..784f774 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -96,6 +96,18 @@
>>   reg = <0x4820 0x1000>;
>>   };
>>
>> +edma: edma@4900 {
> 
>The node should be named "dma-controller", not "edma",according to ePAPR
> section 2.2.2:
> 
> http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

So you mean something like the following?

edma: dma-controller@4900 {
  ...
}


Thanks,

-Joel

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

[git pull] vfs and filesystem fixes

[Al Viro]

Hopefully linux.org.uk mail setup got fixed and this one won't bounce...
Assorted fixes from the last week or so; please pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (1):
  cope with potentially long ->d_dname() output for shmem/hugetlb

Dan Carpenter (3):
  efs: iget_locked() doesn't return an ERR_PTR()
  bfs: iget_locked() doesn't return an ERR_PTR
  VFS: collect_mounts() should return an ERR_PTR

Oleg Nesterov (1):
  proc: kill the extra proc_readfd_common()->dir_emit_dots()

Diffstat:
 fs/bfs/inode.c |2 +-
 fs/dcache.c|   11 +++
 fs/efs/inode.c |2 +-
 fs/hugetlbfs/inode.c   |8 +---
 fs/namespace.c |2 +-
 fs/proc/fd.c   |2 --
 include/linux/dcache.h |1 +
 mm/shmem.c |8 +---
 8 files changed, 17 insertions(+), 19 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 3/5] clk: Add common __clk_get(), __clk_put() implementations

[Sylwester Nawrocki]

This patch adds common __clk_get(), __clk_put() clkdev helpers which
replace their platform specific counterparts when the common clock
API is enabled.

The owner module pointer field is added to struct clk so a reference
to the clock supplier module can be taken by the clock consumers.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v4:
 - dropped unnecessary struct module forward declaration from
   clk-provider.h

Changes since v3:
 - dropped exporting of __clk_get(), __clk_put().

Changes since v2:
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put();
---
 arch/arm/include/asm/clkdev.h  |2 ++
 arch/blackfin/include/asm/clkdev.h |2 ++
 arch/mips/include/asm/clkdev.h |2 ++
 arch/sh/include/asm/clkdev.h   |2 ++
 drivers/clk/clk.c  |   20 
 include/linux/clk-private.h|3 +++
 include/linux/clkdev.h |5 +
 7 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/clkdev.h b/arch/arm/include/asm/clkdev.h
index 80751c1..4e8a4b2 100644
--- a/arch/arm/include/asm/clkdev.h
+++ b/arch/arm/include/asm/clkdev.h
@@ -14,12 +14,14 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #ifdef CONFIG_HAVE_MACH_CLKDEV
 #include 
 #else
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
 #endif
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/blackfin/include/asm/clkdev.h 
b/arch/blackfin/include/asm/clkdev.h
index 9053bed..7ac2436 100644
--- a/arch/blackfin/include/asm/clkdev.h
+++ b/arch/blackfin/include/asm/clkdev.h
@@ -8,7 +8,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif
diff --git a/arch/mips/include/asm/clkdev.h b/arch/mips/include/asm/clkdev.h
index 2624754..1b3ad7b 100644
--- a/arch/mips/include/asm/clkdev.h
+++ b/arch/mips/include/asm/clkdev.h
@@ -14,8 +14,10 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/sh/include/asm/clkdev.h b/arch/sh/include/asm/clkdev.h
index 6ba9186..c419014 100644
--- a/arch/sh/include/asm/clkdev.h
+++ b/arch/sh/include/asm/clkdev.h
@@ -25,7 +25,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif /* __CLKDEV_H__ */
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f46444f..8ccc1cd 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1959,6 +1959,26 @@ void devm_clk_unregister(struct device *dev, struct clk 
*clk)
 }
 EXPORT_SYMBOL_GPL(devm_clk_unregister);
 
+/*
+ * clkdev helpers
+ */
+int __clk_get(struct clk *clk)
+{
+   if (clk && !try_module_get(clk->owner))
+   return 0;
+
+   return 1;
+}
+
+void __clk_put(struct clk *clk)
+{
+   if (WARN_ON_ONCE(IS_ERR(clk)))
+   return;
+
+   if (clk)
+   module_put(clk->owner);
+}
+
 /***clk rate change notifiers***/
 
 /**
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 8138c94..8cb1865 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -25,10 +25,13 @@
 
 #ifdef CONFIG_COMMON_CLK
 
+struct module;
+
 struct clk {
const char  *name;
const struct clk_ops*ops;
struct clk_hw   *hw;
+   struct module   *owner;
struct clk  *parent;
const char  **parent_names;
struct clk  **parents;
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index a6a6f60..94bad77 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -43,4 +43,9 @@ int clk_add_alias(const char *, const char *, char *, struct 
device *);
 int clk_register_clkdev(struct clk *, const char *, const char *, ...);
 int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
 
+#ifdef CONFIG_COMMON_CLK
+int __clk_get(struct clk *clk);
+void __clk_put(struct clk *clk);
+#endif
+
 #endif
-- 
1.7.4.1

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

[PATCH v5 1/5] clk: Provide not locked variant of of_clk_get_from_provider()

[Sylwester Nawrocki]

Add helper functions for the of_clk_providers list locking and
an unlocked variant of of_clk_get_from_provider().
These functions are intended to be used in the clkdev to avoid
race condition in the device tree based clock look up in clk_get().

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Acked-by: Russell King 
---
Changes since v3:
 - none.

Changes since v2:
 - fixed typo in clk.h.

Changes since v1:
 - moved the function declaractions to a local header.
---
 drivers/clk/clk.c |   38 ++
 drivers/clk/clk.h |   16 
 2 files changed, 46 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/clk.h

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bc02037..f46444f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static DEFINE_SPINLOCK(enable_lock);
 static DEFINE_MUTEX(prepare_lock);
 
@@ -2097,7 +2099,18 @@ static const struct of_device_id __clk_of_table_sentinel
__used __section(__clk_of_table_end);
 
 static LIST_HEAD(of_clk_providers);
-static DEFINE_MUTEX(of_clk_lock);
+static DEFINE_MUTEX(of_clk_mutex);
+
+/* of_clk_provider list locking helpers */
+void of_clk_lock(void)
+{
+   mutex_lock(&of_clk_mutex);
+}
+
+void of_clk_unlock(void)
+{
+   mutex_unlock(&of_clk_mutex);
+}
 
 struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 void *data)
@@ -2141,9 +2154,9 @@ int of_clk_add_provider(struct device_node *np,
cp->data = data;
cp->get = clk_src_get;
 
-   mutex_lock(&of_clk_lock);
+   mutex_lock(&of_clk_mutex);
list_add(&cp->link, &of_clk_providers);
-   mutex_unlock(&of_clk_lock);
+   mutex_unlock(&of_clk_mutex);
pr_debug("Added clock from %s\n", np->full_name);
 
return 0;
@@ -2158,7 +2171,7 @@ void of_clk_del_provider(struct device_node *np)
 {
struct of_clk_provider *cp;
 
-   mutex_lock(&of_clk_lock);
+   mutex_lock(&of_clk_mutex);
list_for_each_entry(cp, &of_clk_providers, link) {
if (cp->node == np) {
list_del(&cp->link);
@@ -2167,24 +2180,33 @@ void of_clk_del_provider(struct device_node *np)
break;
}
}
-   mutex_unlock(&of_clk_lock);
+   mutex_unlock(&of_clk_mutex);
 }
 EXPORT_SYMBOL_GPL(of_clk_del_provider);
 
-struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec)
 {
struct of_clk_provider *provider;
struct clk *clk = ERR_PTR(-ENOENT);
 
/* Check if we have such a provider in our array */
-   mutex_lock(&of_clk_lock);
list_for_each_entry(provider, &of_clk_providers, link) {
if (provider->node == clkspec->np)
clk = provider->get(clkspec, provider->data);
if (!IS_ERR(clk))
break;
}
-   mutex_unlock(&of_clk_lock);
+
+   return clk;
+}
+
+struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+{
+   struct clk *clk;
+
+   mutex_lock(&of_clk_mutex);
+   clk = __of_clk_get_from_provider(clkspec);
+   mutex_unlock(&of_clk_mutex);
 
return clk;
 }
diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
new file mode 100644
index 000..795cc9f
--- /dev/null
+++ b/drivers/clk/clk.h
@@ -0,0 +1,16 @@
+/*
+ * linux/drivers/clk/clk.h
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki 
+ *
+ * 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.
+ */
+
+#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec);
+void of_clk_lock(void);
+void of_clk_unlock(void);
+#endif
-- 
1.7.4.1

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

[PATCH v5 5/5] clk: Implement clk_unregister

[Sylwester Nawrocki]

clk_unregister() is currently not implemented and it is required when
a clock provider module needs to be unloaded.

Normally the clock supplier module is prevented to be unloaded by
taking reference on the module in clk_get().

For cases when the clock supplier module deinitializes despite the
consumers of its clocks holding a reference on the module, e.g. when
the driver is unbound through "unbind" sysfs attribute, there are
empty clock ops added. These ops are assigned temporarily to struct
clk and used until all consumers release the clock, to avoid invoking
callbacks from the module which just got removed.

Signed-off-by: Jiada Wang 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v4:
 - none.

Changes since v3:
 - Use WARN_ON_ONCE() rather than WARN_ON() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - none.

Changes since RFC v1:
 - renamed clk_dummy_* to clk_nodrv_*.
---
 drivers/clk/clk.c   |  123 +-
 include/linux/clk-private.h |2 +
 2 files changed, 122 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cf5765a..df41052 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -344,6 +344,21 @@ out:
return ret;
 }
 
+ /**
+ * clk_debug_unregister - remove a clk node from the debugfs clk tree
+ * @clk: the clk being removed from the debugfs clk tree
+ *
+ * Dynamically removes a clk and all it's children clk nodes from the
+ * debugfs clk tree if clk->dentry points to debugfs created by
+ * clk_debug_register in __clk_init.
+ *
+ * Caller must hold prepare_lock.
+ */
+static void clk_debug_unregister(struct clk *clk)
+{
+   debugfs_remove_recursive(clk->dentry);
+}
+
 /**
  * clk_debug_reparent - reparent clk node in the debugfs clk tree
  * @clk: the clk being reparented
@@ -434,6 +449,9 @@ static inline int clk_debug_register(struct clk *clk) { 
return 0; }
 static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
 {
 }
+static inline void clk_debug_unregister(struct clk *clk)
+{
+}
 #endif
 
 /* caller must hold prepare_lock */
@@ -1764,6 +1782,7 @@ int __clk_init(struct device *dev, struct clk *clk)
 
clk_debug_register(clk);
 
+   kref_init(&clk->ref);
 out:
clk_prepare_unlock();
 
@@ -1899,13 +1918,106 @@ fail_out:
 }
 EXPORT_SYMBOL_GPL(clk_register);
 
+/*
+ * Free memory allocated for a clock.
+ * Caller must hold prepare_lock.
+ */
+static void __clk_release(struct kref *ref)
+{
+   struct clk *clk = container_of(ref, struct clk, ref);
+   int i = clk->num_parents;
+
+   kfree(clk->parents);
+   while (--i >= 0)
+   kfree(clk->parent_names[i]);
+
+   kfree(clk->parent_names);
+   kfree(clk->name);
+   kfree(clk);
+}
+
+/*
+ * Empty clk_ops for unregistered clocks. These are used temporarily
+ * after clk_unregister() was called on a clock and until last clock
+ * consumer calls clk_put() and the struct clk object is freed.
+ */
+static int clk_nodrv_prepare_enable(struct clk_hw *hw)
+{
+   return -ENXIO;
+}
+
+static void clk_nodrv_disable_unprepare(struct clk_hw *hw)
+{
+   WARN_ON_ONCE(1);
+}
+
+static int clk_nodrv_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   return -ENXIO;
+}
+
+static int clk_nodrv_set_parent(struct clk_hw *hw, u8 index)
+{
+   return -ENXIO;
+}
+
+static const struct clk_ops clk_nodrv_ops = {
+   .enable = clk_nodrv_prepare_enable,
+   .disable= clk_nodrv_disable_unprepare,
+   .prepare= clk_nodrv_prepare_enable,
+   .unprepare  = clk_nodrv_disable_unprepare,
+   .set_rate   = clk_nodrv_set_rate,
+   .set_parent = clk_nodrv_set_parent,
+};
+
 /**
  * clk_unregister - unregister a currently registered clock
  * @clk: clock to unregister
- *
- * Currently unimplemented.
  */
-void clk_unregister(struct clk *clk) {}
+void clk_unregister(struct clk *clk)
+{
+   unsigned long flags;
+
+   clk_prepare_lock();
+
+   if (!clk || IS_ERR(clk)) {
+   pr_err("%s: invalid clock: %p\n", __func__, clk);
+   goto out;
+   }
+
+   if (clk->ops == &clk_nodrv_ops) {
+   pr_err("%s: unregistered clock: %s\n", __func__, clk->name);
+   goto out;
+   }
+   /*
+* Assign empty clock ops for consumers that might still hold
+* a reference to this clock.
+*/
+   flags = clk_enable_lock();
+   clk->ops = &clk_nodrv_ops;
+   clk_enable_unlock(flags);
+
+   if (!hlist_empty(&clk->children)) {
+   struct clk *child;
+
+   /* Reparent all children to the orphan list. */
+   hlist_for_each_entry(child, &clk->children, child_node)
+   clk_set_parent(child, NULL);
+   }
+
+   clk_debug_unregister(clk);
+
+   hlist_del_init(&clk->child_n

[PATCH v5 4/5] clk: Assign module owner of a clock being registered

[Sylwester Nawrocki]

Assign module owner of a driver of a device passed to _clk_register()
and __clk_register() functions so the module_{get,put} calls in
__clk_get(), __clk_put() can have required effect.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Initially I had an 'owner' field added to struct clk_init_data so it can
be set explicitly in clock providers.  But this required modifications
of all users of (devm_)clk_register() as struct clk_init_data instance
was in most cases an unitialized stack variable.  This would also require
adding yet another argument to various clk_register_* functions
registering the standard clocks.  So I went for assigning clk->owner from
dev->driver->owner.  The disadvantages are that dereferencing dev->driver
may be potentially unsafe when not holding struct device::mutex.  And
there might be cases where clk->owner will need to be NULL.  One option
is to set dev argument of clk_register_*() to NULL for that, but it
predates devm_*.

Presumably a requirement could be added that callers of clk_register*()
must ensure dev->driver won't change during a call to these functions ?
---
 drivers/clk/clk.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8ccc1cd..cf5765a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1799,6 +1799,10 @@ struct clk *__clk_register(struct device *dev, struct 
clk_hw *hw)
clk->flags = hw->init->flags;
clk->parent_names = hw->init->parent_names;
clk->num_parents = hw->init->num_parents;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
+   else
+   clk->owner = NULL;
 
ret = __clk_init(dev, clk);
if (ret)
@@ -1819,6 +1823,8 @@ static int _clk_register(struct device *dev, struct 
clk_hw *hw, struct clk *clk)
goto fail_name;
}
clk->ops = hw->init->ops;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
clk->hw = hw;
clk->flags = hw->init->flags;
clk->num_parents = hw->init->num_parents;
-- 
1.7.4.1

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

[PATCH v5 2/5] clkdev: Fix race condition in clock lookup from device tree

[Sylwester Nawrocki]

There is currently a race condition in the device tree part of clk_get()
function, since the pointer returned from of_clk_get_by_name() may become
invalid before __clk_get() call. E.g. due to the clock provider driver
remove() callback being called in between of_clk_get_by_name() and
__clk_get().

Fix this by doing both the look up and __clk_get() operations with the
clock providers list mutex held. This ensures that the clock pointer
returned from __of_clk_get_from_provider() call and passed to __clk_get()
is valid, as long as the clock supplier module first removes its clock
provider instance and then does clk_unregister() on the corresponding
clocks.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mike Turquette 
Acked-by: Russell King 
---
Changes since v2:
 - none.

Changes since v1:
 - include "clk.h".
---
 drivers/clk/clkdev.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..48f6721 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static LIST_HEAD(clocks);
 static DEFINE_MUTEX(clocks_mutex);
 
@@ -39,7 +41,13 @@ struct clk *of_clk_get(struct device_node *np, int index)
if (rc)
return ERR_PTR(rc);
 
-   clk = of_clk_get_from_provider(&clkspec);
+   of_clk_lock();
+   clk = __of_clk_get_from_provider(&clkspec);
+
+   if (!IS_ERR(clk) && !__clk_get(clk))
+   clk = ERR_PTR(-ENOENT);
+
+   of_clk_unlock();
of_node_put(clkspec.np);
return clk;
 }
@@ -157,7 +165,7 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
if (dev) {
clk = of_clk_get_by_name(dev->of_node, con_id);
-   if (!IS_ERR(clk) && __clk_get(clk))
+   if (!IS_ERR(clk))
return clk;
}
 
-- 
1.7.4.1

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

[PATCH v5 0/5] clk: clock deregistration support

[Sylwester Nawrocki]

This patch series implements clock deregistration in the common clock
framework.  This is required for proper support of clock suppliers as
loadable modules.  Previous version of this series can be found at [1].

Comparing to v4 only a stray struct module forward declaration has been 
removed from patch 3/5. My apologies for spamming.

Changes since v3:
 - replaced WARN_ON() with WARN_ON_ONCE() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - reordered the patches so the race condition is fixed before it can
   actually cause any issues,
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put(),
 - added patch adding actual asignment of clk->owner; more details are
   discussed in that specific patch.

Changes since v1:
 - moved of_clk_{lock, unlock}, __of_clk_get_from_provider() function
   declaractions to a local header,
 - renamed clk_dummy_* to clk_nodrv_*.

[1] https://lkml.org/lkml/2013/8/24/43

Sylwester Nawrocki (5):
  clk: Provide not locked variant of of_clk_get_from_provider()
  clkdev: Fix race condition in clock lookup from device tree
  clk: Add common __clk_get(), __clk_put() implementations
  clk: Assign module owner of a clock being registered
  clk: Implement clk_unregister

 arch/arm/include/asm/clkdev.h  |2 +
 arch/blackfin/include/asm/clkdev.h |2 +
 arch/mips/include/asm/clkdev.h |2 +
 arch/sh/include/asm/clkdev.h   |2 +
 drivers/clk/clk.c  |  187 +--
 drivers/clk/clk.h  |   16 +++
 drivers/clk/clkdev.c   |   12 ++-
 include/linux/clk-private.h|5 +
 include/linux/clkdev.h |5 +
 9 files changed, 220 insertions(+), 13 deletions(-)
 create mode 100644 drivers/clk/clk.h

-- 
1.7.4.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 v4 1/4] lib: Introduce atomic MMIO modify

[richard -rw- weinberger]

On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
 wrote:
> Some platforms have MMIO regions that are shared across orthogonal
> subsystems. This commit implements a possible solution for the
> thread-safe access of such regions through a spinlock-protected API.
>
> Concurrent access is protected with a single spinlock for the
> entire MMIO address space. While this protects shared-registers,
> it also serializes access to unrelated/unshared registers.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  include/linux/io.h |  5 +
>  lib/Makefile   |  2 +-
>  lib/atomicio.c | 27 +++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 lib/atomicio.c
>
> diff --git a/include/linux/io.h b/include/linux/io.h
> index f4f42fa..c331dcb 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
>  #define arch_phys_wc_add arch_phys_wc_add
>  #endif
>
> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> +/* Atomic MMIO-wide IO modify */
> +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> +#endif
> +
>  #endif /* _LINUX_IO_H */
> diff --git a/lib/Makefile b/lib/Makefile
> index 7baccfd..695d6e2 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
>  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
>  proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
>  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> -earlycpio.o percpu-refcount.o
> +earlycpio.o percpu-refcount.o atomicio.o
>
>  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
>  lib-$(CONFIG_MMU) += ioremap.o
> diff --git a/lib/atomicio.c b/lib/atomicio.c
> new file mode 100644
> index 000..1750f9d
> --- /dev/null
> +++ b/lib/atomicio.c
> @@ -0,0 +1,27 @@
> +#include 
> +#include 
> +
> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> +/*
> + * Generic atomic MMIO modify.
> + *
> + * Allows thread-safe access to registers shared by unrelated subsystems.
> + * The access is protected by a single MMIO-wide lock.
> + *
> + * Optimized variants can be implemented on a per-architecture basis.
> + */
> +static DEFINE_RAW_SPINLOCK(__io_lock);
> +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> +{
> +   unsigned long flags;
> +   u32 value;
> +
> +   raw_spin_lock_irqsave(&__io_lock, flags);
> +   value = readl(reg) & ~mask;
> +   value |= (set & mask);
> +   writel(value, reg);
> +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> +
> +}
> +EXPORT_SYMBOL(atomic_io_modify);

Why not the default case EXPORT_SYMBOL_GPL()?

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

Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700 Device Driver Support

[Joe Perches]

Some whitespace and neatening fixups.
Some conversions from 4 indent tabs to normal tabs

Signed-off-by: Joe Perches 
---
Just doing this instead of commenting about spacing
again.

 drivers/net/usb/sr9700.c | 127 +--
 1 file changed, 67 insertions(+), 60 deletions(-)

diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 27c86ec..4262b9d 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -29,7 +29,7 @@ static int sr_read(struct usbnet *dev, u8 reg, u16 length, 
void *data)
int err;
 
err = usbnet_read_cmd(dev, SR_RD_REGS, SR_REQ_RD_REG,
-   0, reg, data, length);
+ 0, reg, data, length);
if ((err != length) && (err >= 0))
err = -EINVAL;
return err;
@@ -40,7 +40,7 @@ static int sr_write(struct usbnet *dev, u8 reg, u16 length, 
void *data)
int err;
 
err = usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   0, reg, data, length);
+  0, reg, data, length);
if ((err >= 0) && (err < length))
err = -EINVAL;
return err;
@@ -54,19 +54,19 @@ static int sr_read_reg(struct usbnet *dev, u8 reg, u8 
*value)
 static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
 {
return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   value, reg, NULL, 0);
+   value, reg, NULL, 0);
 }
 
 static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
 {
usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   0, reg, data, length);
+  0, reg, data, length);
 }
 
 static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
 {
usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   value, reg, NULL, 0);
+  value, reg, NULL, 0);
 }
 
 static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
@@ -89,7 +89,7 @@ static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
 
if (i >= SR_SHARE_TIMEOUT) {
netdev_err(dev->net, "%s write timed out!\n",
-   phy ? "phy" : "eeprom");
+  phy ? "phy" : "eeprom");
ret = -EIO;
goto out;
}
@@ -98,7 +98,8 @@ out:
return ret;
 }
 
-static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg, __le16 
*value)
+static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 *value)
 {
int ret;
 
@@ -115,14 +116,15 @@ static int sr_share_read_word(struct usbnet *dev, int 
phy, u8 reg, __le16 *value
ret = sr_read(dev, EPDR, 2, value);
 
netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
-   phy, reg, *value, ret);
+  phy, reg, *value, ret);
 
 out:
mutex_unlock(&dev->phy_mutex);
return ret;
 }
 
-static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg, __le16 
value)
+static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg,
+  __le16 value)
 {
int ret;
 
@@ -156,7 +158,8 @@ static int sr9700_get_eeprom_len(struct net_device *dev)
return SR_EEPROM_LEN;
 }
 
-static int sr9700_get_eeprom(struct net_device *net, struct ethtool_eeprom 
*eeprom, u8 *data)
+static int sr9700_get_eeprom(struct net_device *net,
+struct ethtool_eeprom *eeprom, u8 *data)
 {
struct usbnet *dev = netdev_priv(net);
__le16 *ebuf = (__le16 *)data;
@@ -168,7 +171,8 @@ static int sr9700_get_eeprom(struct net_device *net, struct 
ethtool_eeprom *eepr
return -EINVAL;
 
for (i = 0; i < eeprom->len / 2; i++)
-   ret = sr_read_eeprom_word(dev, eeprom->offset / 2 + i, 
&ebuf[i]);
+   ret = sr_read_eeprom_word(dev, eeprom->offset / 2 + i,
+ &ebuf[i]);
 
return ret;
 }
@@ -199,12 +203,13 @@ static int sr_mdio_read(struct net_device *netdev, int 
phy_id, int loc)
res = le16_to_cpu(res) & ~BMSR_LSTATUS;
 
netdev_dbg(dev->net, "sr_mdio_read() phy_id=0x%02x, loc=0x%02x, 
returns=0x%04x\n",
-   phy_id, loc, res);
+  phy_id, loc, res);
 
return res;
 }
 
-static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc, int 
val)
+static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc,
+ int val)
 {
struct usbnet *dev = netdev_priv(netdev);
__le16 res = cpu_to_le16(val);
@@ -215,7 +220,7 @@ static void sr_mdio_write(struct net_device *netdev, int 
phy_id, int 

Re: [PATCH] ARM: dts: add AM33XX EDMA support

[Sergei Shtylyov]

Hello.

On 08/23/2013 11:06 PM, Sebastian Andrzej Siewior wrote:


From: Matt Porter 



Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt



Joel: Drop DT entries that are non-hardware-description for now as discussed in 
[1]



[1] https://patchwork.kernel.org/patch/2226761/



Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
Signed-off-by: Sebastian Andrzej Siewior 
---
Could someone please pick this up?



  arch/arm/boot/dts/am33xx.dtsi | 12 
  1 file changed, 12 insertions(+)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = <0x4820 0x1000>;
};

+   edma: edma@4900 {


   The node should be named "dma-controller", not "edma",according to ePAPR 
section 2.2.2:


http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] amd64_edac: Correct erratum 505 range

[Borislav Petkov]

On Sat, Aug 24, 2013 at 11:25:00AM +0200, Borislav Petkov wrote:
> I've got one more patch which needs to go to tip/x86/ras for 3.12.
> It was not worth it IMO to send a pull request for a single patch so
> please apply.

Ok, one more but this is the last one, I promise! :-)

Thanks.

---
From: Aravind Gopalakrishnan 
Date: Sat, 24 Aug 2013 10:47:48 -0500
Subject: [PATCH] amd64_edac: Fix incorrect wraparounds

dct_base and dct_limit obtain 32 bit register values when they read
their respective pci config space registers. A left shift beyond 32 bits
will cause them to wrap around. Similar case for chan_addr as can be
seen from the bug report (link below). In the patch, we rectify this by
casting chan_addr to u64 and by comparing dct_base and dct_limit against
properly shifted sys_addr in order to compare the correct bits.

Reported-by: Dan Carpenter 
Signed-off-by: Aravind Gopalakrishnan 
Link: http://lkml.kernel.org/r/20130819132302.GA12171@elgon.mountain
Signed-off-by: Borislav Petkov 
---
 drivers/edac/amd64_edac.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 6952d432e62b..3c9e4e98c651 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1558,11 +1558,12 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
}
 
/* Verify sys_addr is within DCT Range. */
-   dct_base = (dct_sel_baseaddr(pvt) << 27);
-   dct_limit = (((dct_cont_limit_reg >> 11) & 0x1FFF) << 27) | 0x7FF;
+   dct_base = (u64) dct_sel_baseaddr(pvt);
+   dct_limit = (dct_cont_limit_reg >> 11) & 0x1FFF;
 
if (!(dct_cont_base_reg & BIT(0)) &&
-   !(dct_base <= sys_addr && dct_limit >= sys_addr))
+   !(dct_base <= (sys_addr >> 27) &&
+ dct_limit >= (sys_addr >> 27)))
return -EINVAL;
 
/* Verify number of dct's that participate in channel interleaving. */
@@ -1584,7 +1585,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
if (leg_mmio_hole && (sys_addr >= BIT_64(32)))
chan_offset = dhar_offset;
else
-   chan_offset = dct_base;
+   chan_offset = dct_base << 27;
 
chan_addr = sys_addr - chan_offset;
 
@@ -1614,7 +1615,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
amd64_read_pci_cfg(pvt->F1,
   DRAM_CONT_HIGH_OFF + (int) channel * 4,
   &tmp);
-   chan_addr +=  ((tmp >> 11) & 0xfff) << 27;
+   chan_addr +=  (u64) ((tmp >> 11) & 0xfff) << 27;
}
 
f15h_select_dct(pvt, channel);
-- 
1.8.4

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

мастерский путь спасти глазки http://linkbox.altervista.org/743884

[ericnur]

 Хороший способ спасти глазки

[PATCH 2/2] rtc: simplify devm_request_mem_region/devm_ioremap

[Julia Lawall]

From: Julia Lawall 

Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.

This was done using a combination of the semantic patches
devm_ioremap_resource.cocci and devm_request_and_ioremap.cocci, found in
the scripts/coccinelle/api directory.

In rtc-lpc32xx.c and rtc-mv.c, the local variable size is no longer needed.

In rtc-ds1511.c and rtc-ds1742.c, the size field of the local structure is
not useful any more, and is deleted.

Signed-off-by: Julia Lawall 

---
 drivers/rtc/rtc-ds1553.c   |   13 -
 drivers/rtc/rtc-ep93xx.c   |   14 +++---
 drivers/rtc/rtc-imxdi.c|   16 
 drivers/rtc/rtc-lpc32xx.c  |   24 
 drivers/rtc/rtc-mv.c   |   17 -
 drivers/rtc/rtc-mxc.c  |   14 --
 drivers/rtc/rtc-stk17ta8.c |   15 +--
 drivers/rtc/rtc-tx4939.c   |   14 --
 drivers/rtc/rtc-ds1511.c   |   17 +
 drivers/rtc/rtc-ds1742.c   |   18 ++
 10 files changed, 43 insertions(+), 119 deletions(-)

diff --git a/drivers/rtc/rtc-ds1553.c b/drivers/rtc/rtc-ds1553.c
index 8c6c952..fd31571 100644
--- a/drivers/rtc/rtc-ds1553.c
+++ b/drivers/rtc/rtc-ds1553.c
@@ -285,19 +285,14 @@ static int ds1553_rtc_probe(struct platform_device *pdev)
void __iomem *ioaddr;
int ret = 0;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENODEV;
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
-   if (!devm_request_mem_region(&pdev->dev, res->start, RTC_REG_SIZE,
-   pdev->name))
-   return -EBUSY;
 
-   ioaddr = devm_ioremap(&pdev->dev, res->start, RTC_REG_SIZE);
-   if (!ioaddr)
-   return -ENOMEM;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ioaddr = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(ioaddr))
+   return PTR_ERR(ioaddr);
pdata->ioaddr = ioaddr;
pdata->irq = platform_get_irq(pdev, 0);
 
diff --git a/drivers/rtc/rtc-ep93xx.c b/drivers/rtc/rtc-ep93xx.c
index 549b3c3..580e7b5 100644
--- a/drivers/rtc/rtc-ep93xx.c
+++ b/drivers/rtc/rtc-ep93xx.c
@@ -138,17 +138,9 @@ static int ep93xx_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENXIO;
-
-   if (!devm_request_mem_region(&pdev->dev, res->start,
-resource_size(res), pdev->name))
-   return -EBUSY;
-
-   ep93xx_rtc->mmio_base = devm_ioremap(&pdev->dev, res->start,
-resource_size(res));
-   if (!ep93xx_rtc->mmio_base)
-   return -ENXIO;
+   ep93xx_rtc->mmio_base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(ep93xx_rtc->mmio_base))
+   return PTR_ERR(ep93xx_rtc->mmio_base);
 
pdev->dev.platform_data = ep93xx_rtc;
platform_set_drvdata(pdev, ep93xx_rtc);
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index d3a8c8e..abd7f90 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -375,24 +375,16 @@ static int __init dryice_rtc_probe(struct platform_device 
*pdev)
struct imxdi_dev *imxdi;
int rc;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENODEV;
-
imxdi = devm_kzalloc(&pdev->dev, sizeof(*imxdi), GFP_KERNEL);
if (!imxdi)
return -ENOMEM;
 
imxdi->pdev = pdev;
 
-   if (!devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
-   pdev->name))
-   return -EBUSY;
-
-   imxdi->ioaddr = devm_ioremap(&pdev->dev, res->start,
-   resource_size(res));
-   if (imxdi->ioaddr == NULL)
-   return -ENOMEM;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   imxdi->ioaddr = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(imxdi->ioaddr))
+   return PTR_ERR(imxdi->ioaddr);
 
spin_lock_init(&imxdi->irq_lock);
 
diff --git a/drivers/rtc/rtc-lpc32xx.c b/drivers/rtc/rtc-lpc32xx.c
index 8276ae9..bfdbcb8 100644
--- a/drivers/rtc/rtc-lpc32xx.c
+++ b/drivers/rtc/rtc-lpc32xx.c
@@ -201,16 +201,9 @@ static int lpc32xx_rtc_probe(struct platform_device *pdev)
 {
struct resource *res;
struct lpc32xx_rtc *rtc;
-   resource_size_t size;
int rtcirq;
u32 tmp;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(&pdev->dev, "Can't get memory resource\n");
-   return -EN

[PATCH 0/2] simplify devm_request_mem_region/devm_ioremap

[Julia Lawall]

Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.

The semantic patch used to perform this transformation is as follows:
(http://coccinelle.lip6.fr/)

// 
@r@
expression dev,res,size,name,base;
identifier l;
@@

-if (!devm_request_mem_region(dev, res->start, size, name))
- { ... \(goto l;\|return ...;\) }
... when != res->start
base =
(
-devm_ioremap(dev,res->start,size)
+devm_request_and_ioremap(dev,res)
|
-devm_ioremap_nocache(dev,res->start,size)
+devm_request_and_ioremap(dev,res)
)
... when any
when != res->start

@@
expression pdev,res,n,r.base,e1,e2;
identifier l,f,res1;
type T;
@@

(
(
  T res1 = f(pdev, IORESOURCE_MEM, n);
|
  res1 = f(pdev, IORESOURCE_MEM, n);
)
- if (res1 == NULL) { ... \(goto l;\|return ...;\) }
  base = devm_request_and_ioremap(e1, res1);
|
(
- res = f(pdev, IORESOURCE_MEM, n);
|
  T res1
-  = f(pdev, IORESOURCE_MEM, n)
  ;
)
  ... when != res
(
- if (res == NULL) { ... \(goto l;\|return ...;\) }
|
 if (
- res == NULL ||
  e2
) { ... \(goto l;\|return ...;\) }
)
  ... when != res
+ res = f(pdev, IORESOURCE_MEM, n);
  base = devm_request_and_ioremap(e1, res);
)

@@
expression r.base, dev, res;
@@

base = 
- devm_request_and_ioremap
+ devm_ioremap_resource
 (dev, res);
 ...
 if (
-base == NULL
+IS_ERR(base)
 || ...) {
<...
-   return ...;
+   return PTR_ERR(base);
...>
 }

@@
expression r.base, dev, res;
@@

base = 
- devm_request_and_ioremap
+ devm_ioremap_resource
 (dev, res);

@@
expression r.base, E, ret;
identifier l;
@@

 base = devm_ioremap_resource(...);
 ...
 if (IS_ERR(base) || ...) {
... when any
-   ret = E;
+   ret = PTR_ERR(base);
...
(
return ret;
|
goto l;
)
 }

@@
expression r.base;
@@

 base = devm_ioremap_resource(...);
 ...
 if (IS_ERR(base) || ...) {
<...
-   \(dev_dbg\|dev_warn\|dev_err\|pr_debug\|pr_err\|DRM_ERROR\)(...);
...>
 }

@@
expression r.base;
identifier l;
@@

 base = devm_ioremap_resource(...);
 ...
 if (IS_ERR(base) || ...)
-{
(
return ...;
|
goto l;
)
-}
// 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi: simplify devm_request_mem_region/devm_ioremap

[Julia Lawall]

From: Julia Lawall 

Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.

This was done using a combination of the semantic patches
devm_ioremap_resource.cocci and devm_request_and_ioremap.cocci, found in
the scripts/coccinelle/api directory.

This patch also removes the label exit_busy, to use the error code returned
by the failing operation, rather than always -EBUSY.

Signed-off-by: Julia Lawall 

---
 drivers/spi/spi-altera.c  |   17 +
 drivers/spi/spi-oc-tiny.c |   22 +-
 2 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index 8a6bb37..63d25e6 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -234,15 +234,11 @@ static int altera_spi_probe(struct platform_device *pdev)
 
/* find and map our resources */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   goto exit_busy;
-   if (!devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
-pdev->name))
-   goto exit_busy;
-   hw->base = devm_ioremap_nocache(&pdev->dev, res->start,
-   resource_size(res));
-   if (!hw->base)
-   goto exit_busy;
+   hw->base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(hw->base)) {
+   err = PTR_ERR(hw->base);
+   goto exit;
+   }
/* program defaults into the registers */
hw->imr = 0;/* disable spi interrupts */
writel(hw->imr, hw->base + ALTERA_SPI_CONTROL);
@@ -269,9 +265,6 @@ static int altera_spi_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "base %p, irq %d\n", hw->base, hw->irq);
 
return 0;
-
-exit_busy:
-   err = -EBUSY;
 exit:
spi_master_put(master);
return err;
diff --git a/drivers/spi/spi-oc-tiny.c b/drivers/spi/spi-oc-tiny.c
index 58deb79..d36ba90 100644
--- a/drivers/spi/spi-oc-tiny.c
+++ b/drivers/spi/spi-oc-tiny.c
@@ -315,15 +315,11 @@ static int tiny_spi_probe(struct platform_device *pdev)
 
/* find and map our resources */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   goto exit_busy;
-   if (!devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
-pdev->name))
-   goto exit_busy;
-   hw->base = devm_ioremap_nocache(&pdev->dev, res->start,
-   resource_size(res));
-   if (!hw->base)
-   goto exit_busy;
+   hw->base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(hw->base)) {
+   err = PTR_ERR(hw->base);
+   goto exit;
+   }
/* irq is optional */
hw->irq = platform_get_irq(pdev, 0);
if (hw->irq >= 0) {
@@ -337,8 +333,10 @@ static int tiny_spi_probe(struct platform_device *pdev)
if (platp) {
hw->gpio_cs_count = platp->gpio_cs_count;
hw->gpio_cs = platp->gpio_cs;
-   if (platp->gpio_cs_count && !platp->gpio_cs)
-   goto exit_busy;
+   if (platp->gpio_cs_count && !platp->gpio_cs) {
+   err = -EBUSY;
+   goto exit;
+   }
hw->freq = platp->freq;
hw->baudwidth = platp->baudwidth;
} else {
@@ -365,8 +363,6 @@ static int tiny_spi_probe(struct platform_device *pdev)
 exit_gpio:
while (i-- > 0)
gpio_free(hw->gpio_cs[i]);
-exit_busy:
-   err = -EBUSY;
 exit:
spi_master_put(master);
return err;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Itsuki Request for a business proposal? -

[Suki Kaito]

August 22 2013

To Whom It May Concern

Konnichiwa ! It is with respect to directly write this proposal letter  
to you, informing you of a potential business proposal project that  
can be established from your country with your help, which will  
mutually be profitable to us having no risk involved.


If you are agreeable to this business proposal, please indicate your  
interest by giving me a direct response email. Feel free to contact me  
via electronic mail or telephone for further discussion. I look  
forward to hearing from you positively on this proposal.


Domo arigato !
Suki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAX7301 GPIO: Reverting "Do not force SPI speed when using OF Platform"

[christophe leroy]

Le 23/08/2013 19:47, Linus Walleij a écrit :

On Tue, Aug 20, 2013 at 8:29 AM, Christophe Leroy
 wrote:


This patch reverts commit 047b93a35961f7a6561e6f5dcb040738f822b892 which breaks
MAX7301 GPIO driver because that commit was dependant on a rejected patch that
was implementing selection of SPI speed from the Device Tree.

Signed-off-by: Christophe Leroy 

Patch applied with Roland's ACK.

But seriously, this is the kind of stuff that scares me a lot,
when developers merge dependent patches into two different
trees, that is just a recipe for chaos and me getting flamed
by other kernel maintainers.

There is *no* mention of this dependency in the other
commit.


I'm very sorry for this mishap. If I didn't mention it in the commit, 
this is because when I developped the change I submitted you a few 
months back, I was not aware of that other patch. It looks like it has 
been in my company's kernel tree for years, therefore in my mind it was 
a standard feature of the kernel. It looks like nobody had tried and 
submitted it for inclusion previously.
That's thanks to Roland that I discovered it was indeed not a standard 
feature, then I tried to submit that patch a week ago and it was 
rejected by Stephen Warren for good reason.

For me it is a lesson learnt, and I'll make sure it doesn't happen again.

Regards
Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1 V2] AMD64_EDAC: Fix incorrect wrap arounds due to left shift beyond 32 bits.

[Aravind Gopalakrishnan]

Link to the bug report:
http://marc.info/?l=linux-edac&m=137692201732220&w=2

dct_base and dct_limit obtain 32 bit register values when they read
their respective pci config space registers. A left shift beyond 32 bits will
cause them to wrap around. Similar case for chan_addr as can be seen from
the bug report. In the patch, we rectify this by casting chan_addr to
u64 and by comparing dct_base and dct_limit against (sys_addr >> 27)

Change from V1:
- Fix chan_offset to use left-shifted version of dct_base.

Signed-off-by: Aravind Gopalakrishnan 

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index b86228c..64cfcaf 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1558,11 +1558,12 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
}
 
/* Verify sys_addr is within DCT Range. */
-   dct_base = (dct_sel_baseaddr(pvt) << 27);
-   dct_limit = (((dct_cont_limit_reg >> 11) & 0x1FFF) << 27) | 0x7FF;
+   dct_base = (u64) dct_sel_baseaddr(pvt);
+   dct_limit = (dct_cont_limit_reg >> 11) & 0x1FFF;
 
if (!(dct_cont_base_reg & BIT(0)) &&
-   !(dct_base <= sys_addr && dct_limit >= sys_addr))
+   !(dct_base <= (sys_addr >> 27) &&
+ dct_limit >= (sys_addr >> 27)))
return -EINVAL;
 
/* Verify number of dct's that participate in channel interleaving. */
@@ -1584,7 +1585,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
if (leg_mmio_hole && (sys_addr >= BIT_64(32)))
chan_offset = dhar_offset;
else
-   chan_offset = dct_base;
+   chan_offset = dct_base << 27;
 
chan_addr = sys_addr - chan_offset;
 
@@ -1614,7 +1615,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
amd64_read_pci_cfg(pvt->F1,
   DRAM_CONT_HIGH_OFF + (int) channel * 4,
   &tmp);
-   chan_addr +=  ((tmp >> 11) & 0xfff) << 27;
+   chan_addr +=  (u64) ((tmp >> 11) & 0xfff) << 27;
}
 
f15h_select_dct(pvt, channel);
-- 
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 v4 4/4] watchdog: orion: Use atomic access for shared registers

[Ezequiel Garcia]

Since the timer control register is shared with the clocksource driver,
use the recently introduced atomic_io_clear_set() to access such register.

Signed-off-by: Ezequiel Garcia 
---
 drivers/watchdog/orion_wdt.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 4ea5fcc..cfc037d 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -73,9 +73,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
writel(~WDT_INT_REQ, BRIDGE_CAUSE);
 
/* Enable watchdog timer */
-   reg = readl(wdt_reg + TIMER_CTRL);
-   reg |= WDT_EN;
-   writel(reg, wdt_reg + TIMER_CTRL);
+   atomic_io_modify(wdt_reg + TIMER_CTRL, WDT_EN, WDT_EN);
 
/* Enable reset on watchdog */
reg = readl(RSTOUTn_MASK);
@@ -98,9 +96,7 @@ static int orion_wdt_stop(struct watchdog_device *wdt_dev)
writel(reg, RSTOUTn_MASK);
 
/* Disable watchdog timer */
-   reg = readl(wdt_reg + TIMER_CTRL);
-   reg &= ~WDT_EN;
-   writel(reg, wdt_reg + TIMER_CTRL);
+   atomic_io_modify(wdt_reg + TIMER_CTRL, WDT_EN, 0);
 
spin_unlock(&wdt_lock);
return 0;
-- 
1.8.1.5

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

[PATCH v4 3/4] clocksource: orion: Use atomic access for shared registers

[Ezequiel Garcia]

Replace the driver-specific thread-safe shared register API
by the recently introduced atomic_io_modify().

Signed-off-by: Ezequiel Garcia 
---
 drivers/clocksource/time-orion.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index ecbeb68..f69f697 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -35,20 +36,6 @@
 #define ORION_ONESHOT_MAX  0xfffe
 
 static void __iomem *timer_base;
-static DEFINE_SPINLOCK(timer_ctrl_lock);
-
-/*
- * Thread-safe access to TIMER_CTRL register
- * (shared with watchdog timer)
- */
-void orion_timer_ctrl_clrset(u32 clr, u32 set)
-{
-   spin_lock(&timer_ctrl_lock);
-   writel((readl(timer_base + TIMER_CTRL) & ~clr) | set,
-   timer_base + TIMER_CTRL);
-   spin_unlock(&timer_ctrl_lock);
-}
-EXPORT_SYMBOL(orion_timer_ctrl_clrset);
 
 /*
  * Free-running clocksource handling.
@@ -68,7 +55,8 @@ static int orion_clkevt_next_event(unsigned long delta,
 {
/* setup and enable one-shot timer */
writel(delta, timer_base + TIMER1_VAL);
-   orion_timer_ctrl_clrset(TIMER1_RELOAD_EN, TIMER1_EN);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER1_RELOAD_EN | TIMER1_EN, TIMER1_EN);
 
return 0;
 }
@@ -80,10 +68,13 @@ static void orion_clkevt_mode(enum clock_event_mode mode,
/* setup and enable periodic timer at 1/HZ intervals */
writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD);
writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL);
-   orion_timer_ctrl_clrset(0, TIMER1_RELOAD_EN | TIMER1_EN);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER1_RELOAD_EN | TIMER1_EN,
+   TIMER1_RELOAD_EN | TIMER1_EN);
} else {
/* disable timer */
-   orion_timer_ctrl_clrset(TIMER1_RELOAD_EN | TIMER1_EN, 0);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER1_RELOAD_EN | TIMER1_EN, 0);
}
 }
 
@@ -131,7 +122,9 @@ static void __init orion_timer_init(struct device_node *np)
/* setup timer0 as free-running clocksource */
writel(~0, timer_base + TIMER0_VAL);
writel(~0, timer_base + TIMER0_RELOAD);
-   orion_timer_ctrl_clrset(0, TIMER0_RELOAD_EN | TIMER0_EN);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER0_RELOAD_EN | TIMER0_EN,
+   TIMER0_RELOAD_EN | TIMER0_EN);
clocksource_mmio_init(timer_base + TIMER0_VAL, "orion_clocksource",
  clk_get_rate(clk), 300, 32,
  clocksource_mmio_readl_down);
-- 
1.8.1.5

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

[PATCH v4 1/4] lib: Introduce atomic MMIO modify

[Ezequiel Garcia]

Some platforms have MMIO regions that are shared across orthogonal
subsystems. This commit implements a possible solution for the
thread-safe access of such regions through a spinlock-protected API.

Concurrent access is protected with a single spinlock for the
entire MMIO address space. While this protects shared-registers,
it also serializes access to unrelated/unshared registers.

Signed-off-by: Ezequiel Garcia 
---
 include/linux/io.h |  5 +
 lib/Makefile   |  2 +-
 lib/atomicio.c | 27 +++
 3 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 lib/atomicio.c

diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c331dcb 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
 #define arch_phys_wc_add arch_phys_wc_add
 #endif
 
+#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
+/* Atomic MMIO-wide IO modify */
+extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
+#endif
+
 #endif /* _LINUX_IO_H */
diff --git a/lib/Makefile b/lib/Makefile
index 7baccfd..695d6e2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
 proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
 is_single_threaded.o plist.o decompress.o kobject_uevent.o \
-earlycpio.o percpu-refcount.o
+earlycpio.o percpu-refcount.o atomicio.o
 
 obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
 lib-$(CONFIG_MMU) += ioremap.o
diff --git a/lib/atomicio.c b/lib/atomicio.c
new file mode 100644
index 000..1750f9d
--- /dev/null
+++ b/lib/atomicio.c
@@ -0,0 +1,27 @@
+#include 
+#include 
+
+#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
+/*
+ * Generic atomic MMIO modify.
+ *
+ * Allows thread-safe access to registers shared by unrelated subsystems.
+ * The access is protected by a single MMIO-wide lock.
+ *
+ * Optimized variants can be implemented on a per-architecture basis.
+ */
+static DEFINE_RAW_SPINLOCK(__io_lock);
+void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
+{
+   unsigned long flags;
+   u32 value;
+
+   raw_spin_lock_irqsave(&__io_lock, flags);
+   value = readl(reg) & ~mask;
+   value |= (set & mask);
+   writel(value, reg);
+   raw_spin_unlock_irqrestore(&__io_lock, flags);
+
+}
+EXPORT_SYMBOL(atomic_io_modify);
+#endif
-- 
1.8.1.5

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

[PATCH v4 2/4] ARM: Add atomic_io_modify optimized routines

[Ezequiel Garcia]

Implement arch-specific atomic_io_modify and atomic_io_modify_relaxed,
which are based on writel/readl_relaxed and writel_relaxed/readl_relaxed,
respectively.
In both cases, by relaxing the readl, perfomance can be improved.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/include/asm/io.h |  4 
 arch/arm/kernel/io.c  | 29 +
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d070741..53637b6 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -397,5 +397,9 @@ extern int devmem_is_allowed(unsigned long pfn);
 extern void register_isa_ports(unsigned int mmio, unsigned int io,
   unsigned int io_shift);
 
+#define __HAVE_ARCH_ATOMIC_IO_MODIFY
+extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
+extern void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set);
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_ARM_IO_H */
diff --git a/arch/arm/kernel/io.c b/arch/arm/kernel/io.c
index dcd5b4d..a8c9c9b 100644
--- a/arch/arm/kernel/io.c
+++ b/arch/arm/kernel/io.c
@@ -1,6 +1,35 @@
 #include 
 #include 
 #include 
+#include 
+
+static DEFINE_RAW_SPINLOCK(__io_lock);
+
+void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set)
+{
+   unsigned long flags;
+   u32 value;
+
+   raw_spin_lock_irqsave(&__io_lock, flags);
+   value = readl_relaxed(reg) & ~mask;
+   value |= (set & mask);
+   writel_relaxed(value, reg);
+   raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify_relaxed);
+
+void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
+{
+   unsigned long flags;
+   u32 value;
+
+   raw_spin_lock_irqsave(&__io_lock, flags);
+   value = readl_relaxed(reg) & ~mask;
+   value |= (set & mask);
+   writel(value, reg);
+   raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify);
 
 /*
  * Copy data from IO memory space to "real" memory space.
-- 
1.8.1.5

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

[PATCH v4 0/4] Introduce atomic MMIO modify

[Ezequiel Garcia]

This patchset introduces an atomic MMIO modify API.
The motivation for adding this is to allow cheap, infrastructure-less,
thread-safe access to an MMIO region, even in very early scenarios.

The chosen mask/set semantic (proposed by Russell King) is clean and flexible
enough and matches the regmap_update_bits() prototype. Consistency is good.

This series adds a simple arch-generic implementation in a new lib/atomicio.c
file. On top of that it implements an ARM-optimized variant following Will
Deacon's suggestions, that take advantage of ARM relaxed read/write functions.

Finally, just to show a few usage for this function, last two patches show
how this would solve one of the current shared-registers issues.

Since this 4th version is no longer ARM-specific but kernel-wide, and perhaps
new reviewers might jump in, please read the previous discussion on why this
is needed and why we cannot use a regmap API.

v1: https://lkml.org/lkml/2013/8/10/75
v2: http://comments.gmane.org/gmane.linux.ports.arm.kernel/261879
v3: http://www.spinics.net/lists/arm-kernel/msg269263.html

Thoughts?

Changes from v3:
* Implemented an arch-generic atomic_io_modify(), as suggested by Baruch
  and Catalin.

* Add an ARM-specific variant, using relaxed R/W as Will suggested.

* Replaced spin_locks by raw_spin_locks, to protect the registers
  even on RT.

* Fixed two stupid typos.

Changes from v2:
* As suggested by Will Deacon, dropped the iowmb() barrier
  and use relaxed variants instead. See Will's explanation for
  details: http://www.spinics.net/lists/arm-kernel/msg268775.html

* Use spin_{}_irqsave/restore to allow irq-context usage
  also suggested by Will Deacon.

* Re-worked the API semantics as proposed by Russell King.

Changes from v1:
* Added an io barrier iowmb() as suggested by Will Deacon,
  to ensure the writel gets completed before the spin_unlock().

Ezequiel Garcia (4):
  lib: Introduce atomic MMIO modify
  ARM: Add atomic_io_modify optimized routines
  clocksource: orion: Use atomic access for shared registers
  watchdog: orion: Use atomic access for shared registers

 arch/arm/include/asm/io.h|  4 
 arch/arm/kernel/io.c | 29 +
 drivers/clocksource/time-orion.c | 29 +++--
 drivers/watchdog/orion_wdt.c |  8 ++--
 include/linux/io.h   |  5 +
 lib/Makefile |  2 +-
 lib/atomicio.c   | 27 +++
 7 files changed, 79 insertions(+), 25 deletions(-)
 create mode 100644 lib/atomicio.c

-- 
1.8.1.5

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

Re: [PATCH] proc: kill the extra proc_readfd_common()->dir_emit_dots()

[Al Viro]

On Sat, Aug 24, 2013 at 05:14:34PM +0200, Oleg Nesterov wrote:
> proc_readfd_common() does dir_emit_dots() twice in a row,
> we need to do this only once.

I really wonder how that one had happened - it's harmless, fortunately,
but...  Ugh.  Applied, will push to Linus today
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/5] clk: Add common __clk_get(), __clk_put() implementations

[Sylwester Nawrocki]

This patch adds common __clk_get(), __clk_put() clkdev helpers which
replace their platform specific counterparts when the common clock
API is enabled.

The owner module pointer field is added to struct clk so a reference
to the clock supplier module can be taken by the clock consumers.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v3:
 - dropped exporting of __clk_get(), __clk_put().

Changes since v2:
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put();
---
 arch/arm/include/asm/clkdev.h  |2 ++
 arch/blackfin/include/asm/clkdev.h |2 ++
 arch/mips/include/asm/clkdev.h |2 ++
 arch/sh/include/asm/clkdev.h   |2 ++
 drivers/clk/clk.c  |   20 
 include/linux/clk-private.h|3 +++
 include/linux/clk-provider.h   |2 ++
 include/linux/clkdev.h |5 +
 8 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/clkdev.h b/arch/arm/include/asm/clkdev.h
index 80751c1..4e8a4b2 100644
--- a/arch/arm/include/asm/clkdev.h
+++ b/arch/arm/include/asm/clkdev.h
@@ -14,12 +14,14 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #ifdef CONFIG_HAVE_MACH_CLKDEV
 #include 
 #else
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
 #endif
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/blackfin/include/asm/clkdev.h 
b/arch/blackfin/include/asm/clkdev.h
index 9053bed..7ac2436 100644
--- a/arch/blackfin/include/asm/clkdev.h
+++ b/arch/blackfin/include/asm/clkdev.h
@@ -8,7 +8,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif
diff --git a/arch/mips/include/asm/clkdev.h b/arch/mips/include/asm/clkdev.h
index 2624754..1b3ad7b 100644
--- a/arch/mips/include/asm/clkdev.h
+++ b/arch/mips/include/asm/clkdev.h
@@ -14,8 +14,10 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/sh/include/asm/clkdev.h b/arch/sh/include/asm/clkdev.h
index 6ba9186..c419014 100644
--- a/arch/sh/include/asm/clkdev.h
+++ b/arch/sh/include/asm/clkdev.h
@@ -25,7 +25,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif /* __CLKDEV_H__ */
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f46444f..8ccc1cd 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1959,6 +1959,26 @@ void devm_clk_unregister(struct device *dev, struct clk 
*clk)
 }
 EXPORT_SYMBOL_GPL(devm_clk_unregister);
 
+/*
+ * clkdev helpers
+ */
+int __clk_get(struct clk *clk)
+{
+   if (clk && !try_module_get(clk->owner))
+   return 0;
+
+   return 1;
+}
+
+void __clk_put(struct clk *clk)
+{
+   if (WARN_ON_ONCE(IS_ERR(clk)))
+   return;
+
+   if (clk)
+   module_put(clk->owner);
+}
+
 /***clk rate change notifiers***/
 
 /**
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 8138c94..8cb1865 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -25,10 +25,13 @@
 
 #ifdef CONFIG_COMMON_CLK
 
+struct module;
+
 struct clk {
const char  *name;
const struct clk_ops*ops;
struct clk_hw   *hw;
+   struct module   *owner;
struct clk  *parent;
const char  **parent_names;
struct clk  **parents;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1f0285b..6341e79 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -141,6 +141,8 @@ struct clk_ops {
void(*init)(struct clk_hw *hw);
 };
 
+struct module;
+
 /**
  * struct clk_init_data - holds init data that's common to all clocks and is
  * shared between the clock provider and the common clock framework.
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index a6a6f60..94bad77 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -43,4 +43,9 @@ int clk_add_alias(const char *, const char *, char *, struct 
device *);
 int clk_register_clkdev(struct clk *, const char *, const char *, ...);
 int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
 
+#ifdef CONFIG_COMMON_CLK
+int __clk_get(struct clk *clk);
+void __clk_put(struct clk *clk);
+#endif
+
 #endif
-- 
1.7.4.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.htm

[PATCH v4 4/5] clk: Assign module owner of a clock being registered

[Sylwester Nawrocki]

Assign module owner of a driver of a device passed to _clk_register()
and __clk_register() functions so the module_{get,put} calls in
__clk_get(), __clk_put() can have required effect.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Initially I had an 'owner' field added to struct clk_init_data so it can
be set explicitly in clock providers.  But this required modifications
of all users of (devm_)clk_register() as struct clk_init_data instance
was in most cases an unitialized stack variable.  This would also require
adding yet another argument to various clk_register_* functions
registering the standard clocks.  So I went for assigning clk->owner from
dev->driver->owner.  The disadvantages are that dereferencing dev->driver
may be potentially unsafe when not holding struct device::mutex.  And
there might be cases where clk->owner will need to be NULL.  One option
is to set dev argument of clk_register_*() to NULL for that, but it
predates devm_*.

Presumably a requirement could be added that callers of clk_register*()
must ensure dev->driver won't change during a call to these functions ?
---
 drivers/clk/clk.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8ccc1cd..cf5765a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1799,6 +1799,10 @@ struct clk *__clk_register(struct device *dev, struct 
clk_hw *hw)
clk->flags = hw->init->flags;
clk->parent_names = hw->init->parent_names;
clk->num_parents = hw->init->num_parents;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
+   else
+   clk->owner = NULL;
 
ret = __clk_init(dev, clk);
if (ret)
@@ -1819,6 +1823,8 @@ static int _clk_register(struct device *dev, struct 
clk_hw *hw, struct clk *clk)
goto fail_name;
}
clk->ops = hw->init->ops;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
clk->hw = hw;
clk->flags = hw->init->flags;
clk->num_parents = hw->init->num_parents;
-- 
1.7.4.1

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

[PATCH v4 2/5] clkdev: Fix race condition in clock lookup from device tree

[Sylwester Nawrocki]

There is currently a race condition in the device tree part of clk_get()
function, since the pointer returned from of_clk_get_by_name() may become
invalid before __clk_get() call. E.g. due to the clock provider driver
remove() callback being called in between of_clk_get_by_name() and
__clk_get().

Fix this by doing both the look up and __clk_get() operations with the
clock providers list mutex held. This ensures that the clock pointer
returned from __of_clk_get_from_provider() call and passed to __clk_get()
is valid, as long as the clock supplier module first removes its clock
provider instance and then does clk_unregister() on the corresponding
clocks.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mike Turquette 
Acked-by: Russell King 
---

Changes since v2:
 - none.

Changes since v1:
 - include "clk.h".
---
 drivers/clk/clkdev.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..48f6721 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static LIST_HEAD(clocks);
 static DEFINE_MUTEX(clocks_mutex);
 
@@ -39,7 +41,13 @@ struct clk *of_clk_get(struct device_node *np, int index)
if (rc)
return ERR_PTR(rc);
 
-   clk = of_clk_get_from_provider(&clkspec);
+   of_clk_lock();
+   clk = __of_clk_get_from_provider(&clkspec);
+
+   if (!IS_ERR(clk) && !__clk_get(clk))
+   clk = ERR_PTR(-ENOENT);
+
+   of_clk_unlock();
of_node_put(clkspec.np);
return clk;
 }
@@ -157,7 +165,7 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
if (dev) {
clk = of_clk_get_by_name(dev->of_node, con_id);
-   if (!IS_ERR(clk) && __clk_get(clk))
+   if (!IS_ERR(clk))
return clk;
}
 
-- 
1.7.4.1

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

[PATCH v4 5/5] clk: Implement clk_unregister

[Sylwester Nawrocki]

clk_unregister() is currently not implemented and it is required when
a clock provider module needs to be unloaded.

Normally the clock supplier module is prevented to be unloaded by
taking reference on the module in clk_get().

For cases when the clock supplier module deinitializes despite the
consumers of its clocks holding a reference on the module, e.g. when
the driver is unbound through "unbind" sysfs attribute, there are
empty clock ops added. These ops are assigned temporarily to struct
clk and used until all consumers release the clock, to avoid invoking
callbacks from the module which just got removed.

Signed-off-by: Jiada Wang 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v3:
 - Use WARN_ON_ONCE() rather than WARN_ON() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - none.

Changes since RFC v1:
 - renamed clk_dummy_* to clk_nodrv_*.
---
 drivers/clk/clk.c   |  123 +-
 include/linux/clk-private.h |2 +
 2 files changed, 122 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cf5765a..df41052 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -344,6 +344,21 @@ out:
return ret;
 }
 
+ /**
+ * clk_debug_unregister - remove a clk node from the debugfs clk tree
+ * @clk: the clk being removed from the debugfs clk tree
+ *
+ * Dynamically removes a clk and all it's children clk nodes from the
+ * debugfs clk tree if clk->dentry points to debugfs created by
+ * clk_debug_register in __clk_init.
+ *
+ * Caller must hold prepare_lock.
+ */
+static void clk_debug_unregister(struct clk *clk)
+{
+   debugfs_remove_recursive(clk->dentry);
+}
+
 /**
  * clk_debug_reparent - reparent clk node in the debugfs clk tree
  * @clk: the clk being reparented
@@ -434,6 +449,9 @@ static inline int clk_debug_register(struct clk *clk) { 
return 0; }
 static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
 {
 }
+static inline void clk_debug_unregister(struct clk *clk)
+{
+}
 #endif
 
 /* caller must hold prepare_lock */
@@ -1764,6 +1782,7 @@ int __clk_init(struct device *dev, struct clk *clk)
 
clk_debug_register(clk);
 
+   kref_init(&clk->ref);
 out:
clk_prepare_unlock();
 
@@ -1899,13 +1918,106 @@ fail_out:
 }
 EXPORT_SYMBOL_GPL(clk_register);
 
+/*
+ * Free memory allocated for a clock.
+ * Caller must hold prepare_lock.
+ */
+static void __clk_release(struct kref *ref)
+{
+   struct clk *clk = container_of(ref, struct clk, ref);
+   int i = clk->num_parents;
+
+   kfree(clk->parents);
+   while (--i >= 0)
+   kfree(clk->parent_names[i]);
+
+   kfree(clk->parent_names);
+   kfree(clk->name);
+   kfree(clk);
+}
+
+/*
+ * Empty clk_ops for unregistered clocks. These are used temporarily
+ * after clk_unregister() was called on a clock and until last clock
+ * consumer calls clk_put() and the struct clk object is freed.
+ */
+static int clk_nodrv_prepare_enable(struct clk_hw *hw)
+{
+   return -ENXIO;
+}
+
+static void clk_nodrv_disable_unprepare(struct clk_hw *hw)
+{
+   WARN_ON_ONCE(1);
+}
+
+static int clk_nodrv_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   return -ENXIO;
+}
+
+static int clk_nodrv_set_parent(struct clk_hw *hw, u8 index)
+{
+   return -ENXIO;
+}
+
+static const struct clk_ops clk_nodrv_ops = {
+   .enable = clk_nodrv_prepare_enable,
+   .disable= clk_nodrv_disable_unprepare,
+   .prepare= clk_nodrv_prepare_enable,
+   .unprepare  = clk_nodrv_disable_unprepare,
+   .set_rate   = clk_nodrv_set_rate,
+   .set_parent = clk_nodrv_set_parent,
+};
+
 /**
  * clk_unregister - unregister a currently registered clock
  * @clk: clock to unregister
- *
- * Currently unimplemented.
  */
-void clk_unregister(struct clk *clk) {}
+void clk_unregister(struct clk *clk)
+{
+   unsigned long flags;
+
+   clk_prepare_lock();
+
+   if (!clk || IS_ERR(clk)) {
+   pr_err("%s: invalid clock: %p\n", __func__, clk);
+   goto out;
+   }
+
+   if (clk->ops == &clk_nodrv_ops) {
+   pr_err("%s: unregistered clock: %s\n", __func__, clk->name);
+   goto out;
+   }
+   /*
+* Assign empty clock ops for consumers that might still hold
+* a reference to this clock.
+*/
+   flags = clk_enable_lock();
+   clk->ops = &clk_nodrv_ops;
+   clk_enable_unlock(flags);
+
+   if (!hlist_empty(&clk->children)) {
+   struct clk *child;
+
+   /* Reparent all children to the orphan list. */
+   hlist_for_each_entry(child, &clk->children, child_node)
+   clk_set_parent(child, NULL);
+   }
+
+   clk_debug_unregister(clk);
+
+   hlist_del_init(&clk->child_node);
+
+   if (clk->pre

[PATCH v4 1/5] clk: Provide not locked variant of of_clk_get_from_provider()

[Sylwester Nawrocki]

Add helper functions for the of_clk_providers list locking and
an unlocked variant of of_clk_get_from_provider().
These functions are intended to be used in the clkdev to avoid
race condition in the device tree based clock look up in clk_get().

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Acked-by: Russell King 
---
Changes since v3:
 - none.

Changes since v2:
 - fixed typo in clk.h.

Changes since v1:
 - moved the function declaractions to a local header.
---
 drivers/clk/clk.c |   38 ++
 drivers/clk/clk.h |   16 
 2 files changed, 46 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/clk.h

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bc02037..f46444f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static DEFINE_SPINLOCK(enable_lock);
 static DEFINE_MUTEX(prepare_lock);
 
@@ -2097,7 +2099,18 @@ static const struct of_device_id __clk_of_table_sentinel
__used __section(__clk_of_table_end);
 
 static LIST_HEAD(of_clk_providers);
-static DEFINE_MUTEX(of_clk_lock);
+static DEFINE_MUTEX(of_clk_mutex);
+
+/* of_clk_provider list locking helpers */
+void of_clk_lock(void)
+{
+   mutex_lock(&of_clk_mutex);
+}
+
+void of_clk_unlock(void)
+{
+   mutex_unlock(&of_clk_mutex);
+}
 
 struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 void *data)
@@ -2141,9 +2154,9 @@ int of_clk_add_provider(struct device_node *np,
cp->data = data;
cp->get = clk_src_get;
 
-   mutex_lock(&of_clk_lock);
+   mutex_lock(&of_clk_mutex);
list_add(&cp->link, &of_clk_providers);
-   mutex_unlock(&of_clk_lock);
+   mutex_unlock(&of_clk_mutex);
pr_debug("Added clock from %s\n", np->full_name);
 
return 0;
@@ -2158,7 +2171,7 @@ void of_clk_del_provider(struct device_node *np)
 {
struct of_clk_provider *cp;
 
-   mutex_lock(&of_clk_lock);
+   mutex_lock(&of_clk_mutex);
list_for_each_entry(cp, &of_clk_providers, link) {
if (cp->node == np) {
list_del(&cp->link);
@@ -2167,24 +2180,33 @@ void of_clk_del_provider(struct device_node *np)
break;
}
}
-   mutex_unlock(&of_clk_lock);
+   mutex_unlock(&of_clk_mutex);
 }
 EXPORT_SYMBOL_GPL(of_clk_del_provider);
 
-struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec)
 {
struct of_clk_provider *provider;
struct clk *clk = ERR_PTR(-ENOENT);
 
/* Check if we have such a provider in our array */
-   mutex_lock(&of_clk_lock);
list_for_each_entry(provider, &of_clk_providers, link) {
if (provider->node == clkspec->np)
clk = provider->get(clkspec, provider->data);
if (!IS_ERR(clk))
break;
}
-   mutex_unlock(&of_clk_lock);
+
+   return clk;
+}
+
+struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+{
+   struct clk *clk;
+
+   mutex_lock(&of_clk_mutex);
+   clk = __of_clk_get_from_provider(clkspec);
+   mutex_unlock(&of_clk_mutex);
 
return clk;
 }
diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
new file mode 100644
index 000..795cc9f
--- /dev/null
+++ b/drivers/clk/clk.h
@@ -0,0 +1,16 @@
+/*
+ * linux/drivers/clk/clk.h
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki 
+ *
+ * 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.
+ */
+
+#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec);
+void of_clk_lock(void);
+void of_clk_unlock(void);
+#endif
-- 
1.7.4.1

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

[PATCH] proc: kill the extra proc_readfd_common()->dir_emit_dots()

[Oleg Nesterov]

proc_readfd_common() does dir_emit_dots() twice in a row,
we need to do this only once.

Signed-off-by: Oleg Nesterov 
---
 fs/proc/fd.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 75f2890..0ff80f9 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -230,8 +230,6 @@ static int proc_readfd_common(struct file *file, struct 
dir_context *ctx,
 
if (!dir_emit_dots(file, ctx))
goto out;
-   if (!dir_emit_dots(file, ctx))
-   goto out;
files = get_files_struct(p);
if (!files)
goto out;
-- 
1.5.5.1


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

[PATCH v4 0/5] clk: clock deregistration support

[Sylwester Nawrocki]

This patch series implements clock deregistration in the common clock
framework. This is required for proper support of clock suppliers as
loadable modules.  Previous version of this series can be found at [1].

Changes since v3:
 - dropped exporting of __clk_get(), __clk_put(),
 - replaced WARN_ON() with WARN_ON_ONCE() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - reordered the patches so the race condition is fixed before it can
   actually cause any issues,
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put(),
 - added patch adding actual asignment of clk->owner; more details are
   discussed in that specific patch.

Changes since v1:
 - moved of_clk_{lock, unlock}, __of_clk_get_from_provider() function
   declaractions to a local header,
 - renamed clk_dummy_* to clk_nodrv_*.


[1] https://lkml.org/lkml/2013/8/23/289

Sylwester Nawrocki (5):
  clk: Provide not locked variant of of_clk_get_from_provider()
  clkdev: Fix race condition in clock lookup from device tree
  clk: Add common __clk_get(), __clk_put() implementations
  clk: Assign module owner of a clock being registered
  clk: Implement clk_unregister

 arch/arm/include/asm/clkdev.h  |2 +
 arch/blackfin/include/asm/clkdev.h |2 +
 arch/mips/include/asm/clkdev.h |2 +
 arch/sh/include/asm/clkdev.h   |2 +
 drivers/clk/clk.c  |  187 +--
 drivers/clk/clk.h  |   16 +++
 drivers/clk/clkdev.c   |   12 ++-
 include/linux/clk-private.h|5 +
 include/linux/clk-provider.h   |2 +
 include/linux/clkdev.h |5 +
 10 files changed, 222 insertions(+), 13 deletions(-)
 create mode 100644 drivers/clk/clk.h

--
1.7.4.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 06/12] target: Add memory allocation for bidirectional commands

[Christoph Hellwig]

>  static int
> +transport_generic_get_mem_bidi(struct se_cmd *cmd)

Except for the fields touched in struct se_cmd this is a duplication
of transport_generic_get_mem.  I'd suggest to factor that one into
a new helper:

static int
target_alloc_sgl(struct scatterlist **sgl, unsigned int **nents,
u32 length, gfp_t gfp_mask)
{
..
}

and then call that one from transport_generic_new_cmd directly,
including opencoding the actual BIDI case there as a first step.

If we go down your proposed route for COMPARE and WRITE we'd also
allocate that buffer there, although I think there is a more elegant
way to do that, but more on that later.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] clk: Add common __clk_get(), __clk_put() implementations

[Sylwester Nawrocki]

On 08/24/2013 01:13 AM, Russell King - ARM Linux wrote:

On Fri, Aug 23, 2013 at 05:03:45PM +0200, Sylwester Nawrocki wrote:

>  This patch adds common __clk_get(), __clk_put() clkdev helpers which
>  replace their platform specific counterparts when the common clock
>  API is enabled.
>
>  The owner module pointer field is added to struct clk so a reference
>  to the clock supplier module can be taken by the clock consumers.
>
>  Signed-off-by: Sylwester Nawrocki
>  Signed-off-by: Kyungmin Park


I'm mostly happy with this now.


>  +int __clk_get(struct clk *clk)
>  +{
>  + if (clk&&  !try_module_get(clk->owner))
>  + return 0;
>  +
>  + return 1;
>  +}
>  +EXPORT_SYMBOL(__clk_get);
>  +
>  +void __clk_put(struct clk *clk)
>  +{
>  + if (WARN_ON_ONCE(IS_ERR(clk)))
>  + return;
>  +
>  + if (clk)
>  + module_put(clk->owner);
>  +}
>  +EXPORT_SYMBOL(__clk_put);


Why are these exported?  clkdev can only be built into the kernel, as can
the common clk framework - they can't be modular.  So why would a module
wish to access these directly?


I must have been mislead by the fact that some ARM sub-architecture exports
those, have added them initially and then didn't think enough about it and
left these in. Actually, at some point I noticed the exporting is not 
needed,
but never did get around to remove it. Thanks. The updated series to 
follow.





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

[GIT PULL] ACPI fix for v3.11-rc7

[Rafael J. Wysocki]

Hi Linus,

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
acpi-3.11-rc7

to receive one ACPI fix for v3.11-rc7 as
commit 168cf0eca45b86014b8c2a17fcb0673ab1af809b

  Revert "ACPI / video: Always call acpi_video_init_brightness() on init"

on top of commit b36f4be3de1b123d8601de062e7dbfc904f305fb

  Linux 3.11-rc6

I really hoped that it wouldn't be necessary to change anything in ACPI at
this point, but it turns out that we need to revert one more ACPI video
commit causing trouble.

This reverts a change in the ACPI video driver that caused the ACPI
backlight initialization to be carried out even if acpi_backlight=vendor
is passed in the kernel command line which turns out to break things
at least on one system.

Thanks!


---

Rafael J. Wysocki (1):
  Revert "ACPI / video: Always call acpi_video_init_brightness() on init"

---

 drivers/acpi/video.c |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

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

Re: [PATCH v2 4/4] pinctrl: mvebu: Convert to use devm_ioremap_resource

[Ezequiel Garcia]

Hi Jisheng,

On Fri, Aug 23, 2013 at 10:34:02AM +0800, Jisheng Zhang wrote:
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 

Mmm.. I would prefer to see a better commit log for this patch.
In particular, the current code is buggy (for there's a leak) and
this patch fixes it.
Care to write something meaningful and re-send? (except the patch
Mike already took, I guess).

With that changes you can add:

Reviewed-by: Ezequiel Garcia T

for the whole series.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.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/

[PATCH v2] i915: Update VGA arbiter support for newer devices

[Alex Williamson]

This is intended to add VGA arbiter support for Intel HD graphics on
Core processors.  The old GMCH registers no longer exist, so even
though it appears that i915 participates in VGA arbitration, it doesn't
work.  On Intel HD graphics we already attempt to disable VGA regions
of the device.  This makes registering as a VGA client unnecessary since
we don't intend to operate differently depending on how many VGA devices
are present.  We can disable VGA memory regions by clearing the memory
enable bit in the VGA MSR.  That only leaves VGA IO, which we update
the VGA arbiter to know that we don't participate in VGA memory
arbitration.  We also add a hook on unload to re-enable memory and
reinstate VGA memory arbitration.

Signed-off-by: Alex Williamson 
---

v2: I915_READ/WRITE accessors don't work in i915_disable_vga, use inb/outb
directly.  Also, on the driver unbind VGA enable path, acquire legacy
IO to re-enable VGA memory.  Correct comment.

As with v1, this depends on "vgaarb: Fixes for partial VGA opt-out".  With
all patches I'm able to assign a discrete PEG VGA device to a guest and
execute the VBIOS w/o interference from IGD or corruption of the IGD
framebuffer.

 drivers/gpu/drm/i915/i915_dma.c  |9 ++---
 drivers/gpu/drm/i915/intel_display.c |   24 
 2 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f466980..d9cf216 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1287,9 +1287,12 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
-   if (ret && ret != -ENODEV)
-   goto out;
+   if (!HAS_PCH_SPLIT(dev)) {
+   ret = vga_client_register(dev->pdev, dev, NULL,
+ i915_vga_set_decode);
+   if (ret && ret != -ENODEV)
+   goto out;
+   }
 
intel_register_dsm_handler();
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fb3058..2bb805c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9519,6 +9519,15 @@ static void i915_disable_vga(struct drm_device *dev)
outb(SR01, VGA_SR_INDEX);
sr1 = inb(VGA_SR_DATA);
outb(sr1 | 1<<5, VGA_SR_DATA);
+
+   /* Disable VGA memory on Intel HD */
+   if (HAS_PCH_SPLIT(dev)) {
+   outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
+   vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
+  VGA_RSRC_NORMAL_IO |
+  VGA_RSRC_NORMAL_MEM);
+   }
+
vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
udelay(300);
 
@@ -9526,6 +9535,19 @@ static void i915_disable_vga(struct drm_device *dev)
POSTING_READ(vga_reg);
 }
 
+static void i915_enable_vga(struct drm_device *dev)
+{
+   /* Enable VGA memory on Intel HD */
+   if (HAS_PCH_SPLIT(dev)) {
+   vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
+   outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
+   vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_MASK |
+  VGA_RSRC_NORMAL_IO |
+  VGA_RSRC_NORMAL_MEM);
+   vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
+   }
+}
+
 void intel_modeset_init_hw(struct drm_device *dev)
 {
intel_init_power_well(dev);
@@ -9983,6 +10005,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
 
intel_disable_fbc(dev);
 
+   i915_enable_vga(dev);
+
intel_disable_gt_powersave(dev);
 
ironlake_teardown_rc6(dev);

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

[PATCH] perf: Prevent race in unthrottling code

[Jiri Olsa]

The current throttling code triggers WARN below via following
workload (only hit on AMD machine with 48 CPUs):

  # while [ 1 ]; do perf record perf bench sched messaging; done

  WARNING: at arch/x86/kernel/cpu/perf_event.c:1054 x86_pmu_start+0xc6/0x100()
  SNIP
  Call Trace:
 [] dump_stack+0x19/0x1b
   [] warn_slowpath_common+0x61/0x80
   [] warn_slowpath_null+0x1a/0x20
   [] x86_pmu_start+0xc6/0x100
   [] perf_adjust_freq_unthr_context.part.75+0x182/0x1a0
   [] perf_event_task_tick+0xc8/0xf0
   [] scheduler_tick+0xd1/0x140
   [] update_process_times+0x66/0x80
   [] tick_sched_handle.isra.15+0x25/0x60
   [] tick_sched_timer+0x41/0x60
   [] __run_hrtimer+0x74/0x1d0
   [] ? tick_sched_handle.isra.15+0x60/0x60
   [] hrtimer_interrupt+0xf7/0x240
   [] smp_apic_timer_interrupt+0x69/0x9c
   [] apic_timer_interrupt+0x6d/0x80
 [] ? __perf_event_task_sched_in+0x184/0x1a0
   [] ? kfree_skbmem+0x37/0x90
   [] ? __slab_free+0x1ac/0x30f
   [] ? kfree+0xfd/0x130
   [] kmem_cache_free+0x1b2/0x1d0
   [] kfree_skbmem+0x37/0x90
   [] consume_skb+0x34/0x80
   [] unix_stream_recvmsg+0x4e7/0x820
   [] sock_aio_read.part.7+0x116/0x130
   [] ? __perf_sw_event+0x19c/0x1e0
   [] sock_aio_read+0x21/0x30
   [] do_sync_read+0x80/0xb0
   [] vfs_read+0x145/0x170
   [] SyS_read+0x49/0xa0
   [] ? __audit_syscall_exit+0x1f6/0x2a0
   [] system_call_fastpath+0x16/0x1b
  ---[ end trace 622b7e226c4a766a ]---

The reason is race in perf_event_task_tick throttling code.
The race flow (simplified code):

  - perf_throttled_count is per cpu variable and is
CPU throttling flag, here starting with 0
  - perf_throttled_seq is sequence/domain for allowed
count of interrupts within the tick, gets increased
each tick

on single CPU (CPU bounded event):

  ... workload

perf_event_task_tick:
|
| T0inc(perf_throttled_seq)
| T1needs_unthr = xchg(perf_throttled_count, 0) == 0
 tick gets interrupted:

... event gets throttled under new seq ...

  T2last NMI comes, event is throttled - inc(perf_throttled_count)

 back to tick:
| perf_adjust_freq_unthr_context:
|
| T3unthrottling is skiped for event (needs_unthr == 0)
| T4event is stop and started via freq adjustment
|
tick ends

  ... workload
  ... no sample is hit for event ...

perf_event_task_tick:
|
| T5needs_unthr = xchg(perf_throttled_count, 0) != 0 (from T2)
| T6unthrottling is done on event (interrupts == MAX_INTERRUPTS)
|   event is already started (from T4) -> WARN

Fixing this by not checking needs_unthr again and thus
check all events for unthrottling.

Signed-off-by: Jiri Olsa 
Reported-by: Jan Stancek 
Suggested-by: Peter Zijlstra 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Stephane Eranian 
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 928fae7..299d1f1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2709,7 +2709,7 @@ static void perf_adjust_freq_unthr_context(struct 
perf_event_context *ctx,
 
hwc = &event->hw;
 
-   if (needs_unthr && hwc->interrupts == MAX_INTERRUPTS) {
+   if (hwc->interrupts == MAX_INTERRUPTS) {
hwc->interrupts = 0;
perf_log_throttle(event, 1);
event->pmu->start(event, 0);
-- 
1.7.11.7

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

Re: [PATCH 00/16] cpufreq: create & use cpufreq_generic_get() routine

[Rafael J. Wysocki]

On Saturday, August 24, 2013 09:50:06 AM Viresh Kumar wrote:
> On 24 August 2013 01:10, Rafael J. Wysocki  wrote:
> > On Friday, August 23, 2013 09:20:35 PM Viresh Kumar wrote:
> >> CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), 
> >> to get
> >> CPUs clk rate, has similar sort of code used for most of them.
> >>
> >> This patchset adds a generic ->get() which will do the same thing for 
> >> them. All
> >> those drivers are required to now is to set .get to cpufreq_generic_get() 
> >> and
> >> set their clk pointer in policy->clk during ->init().
> >>
> >> Later part of this patchset fixes 17 drivers with this change.
> >>
> >> That's part 7 of my generic cleanups for CPUFreq core, first six are here:
> >
> > And that's the last one for 3.13, right?
> 
> 3.13 is too far, can't promise that really :)

OK, let me rephrase that more directly: Please, slow down.  Allow your previous
changes to be integrated before you throw more of them at people.

Thanks,
Rafael

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

[PATCH 1/2] HID: apple: Add another device ID for the mid-2013 Macbook Air

[Ian Munsie]

This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
lsusb:

Bus 001 Device 003: ID 05ac:0290 Apple, Inc.

Since IDs already exist for this generation Macbook air as WELLSPRING8,
name this one WELLSPRING8A. This only adds an ANSI version since it's
device ID is only one less than the existing WELLSPRING8 IDs.

Signed-off-by: Ian Munsie 
---
 drivers/hid/hid-apple.c | 2 ++
 drivers/hid/hid-core.c  | 2 ++
 drivers/hid/hid-ids.h   | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index c7710b5..9e5e9dd 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -530,6 +530,8 @@ static const struct hid_device_id apple_devices[] = {
.driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
+   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI),
+   .driver_data = APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1..5ebcfac 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1550,6 +1550,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) },
@@ -2195,6 +2196,7 @@ static const struct hid_device_id hid_mouse_ignore_list[] 
= {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
{ }
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ffe4c7a..442a877 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -135,6 +135,7 @@
 #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS   0x023b
 #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI  0x0255
 #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO   0x0256
+#define USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI  0x0290
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI   0x0291
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0293
-- 
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 2/2] Input: bcm5974: Add another device ID for the mid-2013 Macbook Air

[Ian Munsie]

This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
lsusb:

Bus 001 Device 003: ID 05ac:0290 Apple, Inc.

Since IDs already exist for this generation Macbook air as WELLSPRING8,
name this one WELLSPRING8A. This only adds an ANSI version since it's
device ID is only one less than the existing WELLSPRING8 IDs.

Signed-off-by: Ian Munsie 
---
 drivers/input/mouse/bcm5974.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 4ef4d5e..fcd2f3f 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -88,6 +88,8 @@
 #define USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI  0x0259
 #define USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO   0x025a
 #define USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS   0x025b
+/* MacbookAir6,1 (unibody, June 2013) */
+#define USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI  0x0290
 /* MacbookAir6,2 (unibody, June 2013) */
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI   0x0291
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
@@ -149,6 +151,8 @@ static const struct usb_device_id bcm5974_table[] = {
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS),
+   /* MacbookAir6,1 */
+   BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI),
/* MacbookAir6,2 */
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_ISO),
@@ -424,6 +428,19 @@ static const struct bcm5974_config bcm5974_config_table[] 
= {
{ SN_COORD, -150, 6600 },
{ SN_ORIENT, -MAX_FINGER_ORIENTATION, MAX_FINGER_ORIENTATION }
},
+   {
+   USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI,
+   0,
+   0,
+   HAS_INTEGRATED_BUTTON,
+   0, sizeof(struct bt_data),
+   0x83, TYPE3, FINGER_TYPE3, FINGER_TYPE3 + SIZEOF_ALL_FINGERS,
+   { SN_PRESSURE, 0, 300 },
+   { SN_WIDTH, 0, 2048 },
+   { SN_COORD, -4620, 5140 },
+   { SN_COORD, -150, 6600 },
+   { SN_ORIENT, -MAX_FINGER_ORIENTATION, MAX_FINGER_ORIENTATION }
+   },
{}
 };
 
-- 
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/

Add missing device ID for mid-2013 Macbook Air 6,1

[Ian Munsie]

I recently got a new mid-2013 Macbook Air, which seems to use a device ID that
is missing from the kernel. From lsusb:
Bus 001 Device 003: ID 05ac:0290 Apple, Inc.

This generation of Macbook Air already has three IDs listed in the kernel
(0x0291, 0x0292 and 0x0293) as WELLSPRING8, so I've added 0x0290 to that list
as WELLSPRING8A. It looks like these generally come in triplets of consecutive
device IDs, so it's not clear to me why there would be an extra one in this
generation (and only -1 from the existing IDs which doesn't leave room for
additional ISO & JIS layouts if they are numbered consecutively).

With these patches the Fn key now works for me, as does the multitouch
functionality of the touchpad.

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