Re: [PATCH] cpufreq: check cpufreq driver is valid and cpufreq isn't disabled in cpufreq_get()

[Srivatsa S. Bhat]

On 09/20/2013 10:37 PM, Viresh Kumar wrote:
> cpufreq_get() can be called from external drivers which might not be aware if
> cpufreq driver is registered or not. And so we should actually check if 
> cpufreq
> driver is registered or not and also if cpufreq is active or disabled, at the
> beginning of cpufreq_get().
> 
> Otherwise call to lock_policy_rwsem_read() might hit BUG_ON(!policy).
> 
> Reported-and-Tested-by: Linus Walleij 
> Signed-off-by: Viresh Kumar 
> ---

Reviewed-by: Srivatsa S. Bhat 

Regards,
Srivatsa S. Bhat

> 
> For 3.12.
> 
>  drivers/cpufreq/cpufreq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 82ecbe3..db004a8 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1460,6 +1460,9 @@ unsigned int cpufreq_get(unsigned int cpu)
>  {
>   unsigned int ret_freq = 0;
> 
> + if (cpufreq_disabled() || !cpufreq_driver)
> + return -ENOENT;
> +
>   if (!down_read_trylock(_rwsem))
>   return 0;
> 

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

Re: Regression on cpufreq in v3.12-rc1

[Srivatsa S. Bhat]

On 09/20/2013 10:31 PM, Viresh Kumar wrote:
> On 20 September 2013 22:04, Linus Walleij  wrote:
>> In this case we have neither. So the cpufreq driver fails to
>> register. But the kernel used to survive in any case, as you
>> could call cpufreq_get() without a cpufreq driver registered.
> 
> Aha, so exactly what I suspected in my first mail..
> 

Yep, your analysis was perfect right from the beginning :-)

Regards,
Srivatsa S. Bhat

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

Re: Regression on cpufreq in v3.12-rc1

[Srivatsa S. Bhat]

On 09/20/2013 10:24 PM, Viresh Kumar wrote:
> On 20 September 2013 20:46, Srivatsa S. Bhat
>  wrote:
>> I think show() and store() also suffer
>> from a similar fate. So do you think we need to add these checks there as 
>> well?
>> I'm not sure, since I can't think of a situation in which show() or store()
>> can be invoked before the cpufreq-driver is registered.. or, is such a
>> situation possible with cpufreq_disabled()?
> 
> cpufreq_disabled() is supposed to be called at boot time, so that
> cpufreq_core_init() fails.. and so show/store wouldn't exist without
> a driver..
> 

Ah, ok..

Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Drivers: scsi: FLUSH timeout

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, September 20, 2013 1:32 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-
> s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
> 
> On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
> > The SD_FLUSH_TIMEOUT value is currently hardcoded.
> 
> Hardcoded where?  Please, more context.

This is defined in scsi/sd.h:

#define SD_FLUSH_TIMEOUT(60 * HZ)
> 
> > On our cloud, we sometimes hit this timeout. I was wondering if we
> > could make this a module parameter. If this is acceptable, I can send
> > you a patch for this.
> 
> A module parameter don't make sense for a per-device value, does it?
Currently, the 60 second timeout is applied across devices. Ideally, I want to 
be
able to control the FLUSH TIMEOUT as we currently do I/O timeout. If this is 
acceptable, I can work on a patch for that as well.

Regards,

K. Y
> 
> 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: Null pointer deference in drivers/power/pm2301_charger.c

[Mike Galbraith]

On Sat, 2013-09-21 at 04:25 +0300, Valentin Ilie wrote: 
> Hello,
> 
> I am trying to solve a NULL pointer deference in
> drivers/power/pm2301_charger.c (and to submit a trivial patch) but I
> am not sure how to do it.
> 
> Line 958 - 961
> pm2 = (struct pm2xxx_charger*)i2c_get_clientdata(pm2xxx_i2c_client);
> if (!pm2) {
> dev_err(pm2->dev, "no pm2xxx_charger data supplied\n");
> 
> Line 976 - 978
> pm2 = (struct pm2xxx_charger*)i2c_get_clientdata(pm2xxx_i2c_client);
> if (!pm2) {
> dev_err(pm2->dev, "no pm2xxx_charger data supplied\n");
> 
> As it can be clearly seen, pm2 is used with NULL value in dev_err. The
> question is, how to fix this? Should I delete the dev_err line or can
> I use printk (to avoid the need of a dev) ?

Looking below that, seems they perhaps meant _i2c_client->dev.

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

Null pointer deference in drivers/power/pm2301_charger.c

[Valentin Ilie]

Hello,

I am trying to solve a NULL pointer deference in
drivers/power/pm2301_charger.c (and to submit a trivial patch) but I
am not sure how to do it.

Line 958 - 961
pm2 = (struct pm2xxx_charger*)i2c_get_clientdata(pm2xxx_i2c_client);
if (!pm2) {
dev_err(pm2->dev, "no pm2xxx_charger data supplied\n");

Line 976 - 978
pm2 = (struct pm2xxx_charger*)i2c_get_clientdata(pm2xxx_i2c_client);
if (!pm2) {
dev_err(pm2->dev, "no pm2xxx_charger data supplied\n");

As it can be clearly seen, pm2 is used with NULL value in dev_err. The
question is, how to fix this? Should I delete the dev_err line or can
I use printk (to avoid the need of a dev) ?

Thank you,
Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 GIT PULL] softirq: Consolidation and stack overrun fix

[Benjamin Herrenschmidt]

On Fri, 2013-09-20 at 13:11 +0200, Peter Zijlstra wrote:
> On Fri, Sep 20, 2013 at 01:03:17PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Sep 2013, Linus Torvalds wrote:
> > 
> > > On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker  
> > > wrote:
> > > >
> > > > It fixes stacks overruns reported by Benjamin Herrenschmidt:
> > > > http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop
> > > 
> > > So I don't really dislike this patch-series, but isn't "irq_exit()"
> > > (which calls the new softirq_on_stack()) already running in the
> > > context of the irq stack? And it's run at the very end of the irq
> > > processing, so the irq stack should be empty too at that point.
> > 
> > Right, but most of the implementations are braindamaged.
> > 
> >   irq_enter();
> >   handle_irq_on_hardirq_stack();
> >   irq_exit();
> 
> I was only just staring at i386 and found it did exactly that. It had to
> jump through preempt_count hoops to make that work and obviously I
> hadn't test-build the preempt patches on i386.

Right and powerpc does the switch even later when calling the individual
handlers.

Ben.

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


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

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

[Benjamin Herrenschmidt]

On Fri, 2013-09-20 at 11:26 -0500, Frederic Weisbecker wrote:

> Looks good to me.
> 
> Now just for clarity, what do we then do with inline sofirq executions: on 
> local_bh_enable()
> for example, or explicit calls to do_softirq() other than irq exit?

We cannot make the irq stack larger than the normal stacks on ppc due to
how we get to the thread info (by masking low bits of the stack
pointer), however our stacks are pretty big too (16k) so it might be
ok to run the softirqs on the irq stack, it's just a matter of us
doing the switch before do_IRQ rather than later when calling the
handlers.

I think we basically copied what x86 originally did, but we can
definitely change that.

> Should we keep the current switch to a different softirq stack? If we have a 
> generic irq stack
> (used for both hard and soft) that is big enough, perhaps we can also switch 
> to this
> generic irq stack for inline softirqs executions? After all there is no much 
> point in keeping
> a separate stack for that: this result in cache misses if the inline softirq 
> is interrupted by
> a hardirq, also inlined softirqs can't happen in hardirq, so there should be 
> no much risk of overruns.
> 
> Or am I missing other things?

Originally IRQs could nest so we really wanted separate stacks,
especially since softirq is where network processing happens and that
can go fairly deep.

But that's not the case anymore so I suppose it makes some sense...

Ben.

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


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

Re: [PATCH 1/2] remove all uses of printf's %n

[Tetsuo Handa]

Kees Cook wrote:
> >> - seq_printf(seq, "%*s\n", 127 - len, "");
> >> + seq_pad(seq, '\n');
> >
> > Hmm, seq_pad is unintuitive. I would say it pads the string by '\n'. Of
> > course it does not, but...
> 
> I don't think this is a very serious problem. Currently, the padding
> character is always ' ' for all existing callers, so it only makes
> sense to make the trailing character an argument.

If you want, we can rename seq_pad() to seq_pad_and_putc(). Also we can pass
both the padding character (e.g. ' ') and the trailing character (e.g. '\n')
like seq_pad_and_putc((' ' << 8) | '\n'), though I wonder someone wants to
use '\0', '\t', '\n' etc. as the padding character...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][RFC] Fix breakage in ffs_fs_mount()

[Michal Nazarewicz]

On Fri, Sep 20 2013, Al Viro wrote:
>   There's a bunch of failure exits in ffs_fs_mount() with
> seriously broken recovery logics.  Most of that appears to stem
> from misunderstanding of the ->kill_sb() semantics;

That sounds likely.

[…]

> Signed-off-by: Al Viro 

Acked-by: Michal Nazarewicz 

> -- 
> diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
> index 1a66c5b..0658908 100644
> --- a/drivers/usb/gadget/f_fs.c
> +++ b/drivers/usb/gadget/f_fs.c
> @@ -1034,37 +1034,19 @@ struct ffs_sb_fill_data {
>   struct ffs_file_perms perms;
>   umode_t root_mode;
>   const char *dev_name;
> - union {
> - /* set by ffs_fs_mount(), read by ffs_sb_fill() */
> - void *private_data;
> - /* set by ffs_sb_fill(), read by ffs_fs_mount */
> - struct ffs_data *ffs_data;
> - };
> + struct ffs_data *ffs_data;
>  };
>  
>  static int ffs_sb_fill(struct super_block *sb, void *_data, int silent)
>  {
>   struct ffs_sb_fill_data *data = _data;
>   struct inode*inode;
> - struct ffs_data *ffs;
> + struct ffs_data *ffs = data->ffs_data;
>  
>   ENTER();
>  
> - /* Initialise data */
> - ffs = ffs_data_new();
> - if (unlikely(!ffs))
> - goto Enomem;
> -
>   ffs->sb  = sb;
> - ffs->dev_name= kstrdup(data->dev_name, GFP_KERNEL);
> - if (unlikely(!ffs->dev_name))
> - goto Enomem;
> - ffs->file_perms  = data->perms;
> - ffs->private_data= data->private_data;
> -
> - /* used by the caller of this function */
> - data->ffs_data   = ffs;
> -
> + data->ffs_data   = NULL;
>   sb->s_fs_info= ffs;
>   sb->s_blocksize  = PAGE_CACHE_SIZE;
>   sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
> @@ -1080,17 +1062,14 @@ static int ffs_sb_fill(struct super_block *sb, void 
> *_data, int silent)
> >perms);
>   sb->s_root = d_make_root(inode);
>   if (unlikely(!sb->s_root))
> - goto Enomem;
> + return -ENOMEM;
>  
>   /* EP0 file */
>   if (unlikely(!ffs_sb_create_file(sb, "ep0", ffs,
>_ep0_operations, NULL)))
> - goto Enomem;
> + return -ENOMEM;
>  
>   return 0;
> -
> -Enomem:
> - return -ENOMEM;
>  }
>  
>  static int ffs_fs_parse_opts(struct ffs_sb_fill_data *data, char *opts)
> @@ -1193,6 +1172,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
>   struct dentry *rv;
>   int ret;
>   void *ffs_dev;
> + struct ffs_data *ffs;
>  
>   ENTER();
>  
> @@ -1200,18 +1180,30 @@ ffs_fs_mount(struct file_system_type *t, int flags,
>   if (unlikely(ret < 0))
>   return ERR_PTR(ret);
>  
> + ffs = ffs_data_new();
> + if (unlikely(!ffs))
> + return ERR_PTR(-ENOMEM);
> + ffs->file_perms = data.perms;
> +
> + ffs->dev_name = kstrdup(dev_name, GFP_KERNEL);
> + if (unlikely(!ffs->dev_name)) {
> + ffs_data_put(ffs);
> + return ERR_PTR(-ENOMEM);
> + }
> +
>   ffs_dev = functionfs_acquire_dev_callback(dev_name);
> - if (IS_ERR(ffs_dev))
> - return ffs_dev;
> + if (IS_ERR(ffs_dev)) {
> + ffs_data_put(ffs);
> + return ERR_CAST(ffs_dev);
> + }
> + ffs->private_data = ffs_dev;
> + data.ffs_data = ffs;
>  
> - data.dev_name = dev_name;
> - data.private_data = ffs_dev;
>   rv = mount_nodev(t, flags, , ffs_sb_fill);
> -
> - /* data.ffs_data is set by ffs_sb_fill */
> - if (IS_ERR(rv))
> + if (IS_ERR(rv) && data.ffs_data) {
>   functionfs_release_dev_callback(data.ffs_data);
> -
> + ffs_data_put(data.ffs_data);
> + }
>   return rv;
>  }
>  

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--


signature.asc
Description: PGP signature

[PATCH] drivers: bluetooth: btusb: Added support for Belkin F8065bf usb bluetooth device

[Ken O'Brien]

Adding generic rule for broadcom devices to generic usb bluetooth driver on 
encountering another instance of Broadcom's BCM20702A0.

Relevant section from /sys/kernel/debug/usb/devices:

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=050d ProdID=065a Rev= 1.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=0002723E2D29
C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Signed-off-by: Ken O'Brien 
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8e16f0a..6d33dca 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -111,6 +111,7 @@ static struct usb_device_id btusb_table[] = {
 
/*Broadcom devices with vendor specific id */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) },
+   { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
 
{ } /* Terminating entry */
 };
-- 
1.8.1.4

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

Re: [PATCH] writeback: fix delayed sync(2)

[Tejun Heo]

Hello,

On Fri, Sep 20, 2013 at 04:52:26PM +0400, Maxim Patlasov wrote:
> @@ -294,7 +294,7 @@ void bdi_wakeup_thread_delayed(struct backing_dev_info 
> *bdi)
>   unsigned long timeout;
>  
>   timeout = msecs_to_jiffies(dirty_writeback_interval * 10);
> - mod_delayed_work(bdi_wq, >wb.dwork, timeout);
> + queue_delayed_work(bdi_wq, >wb.dwork, timeout);

Hmmm... this at least requires comment explaining why
mod_delayed_work() doesn't work here.  Also, I wonder whether what we
need is a function which either queues if !pending and shortens timer
if pending.  This is a relatively common pattern and the suggested fix
is subtle and fragile.

Thanks.

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

Re: [PATCH] perf tools: Use per-file CFLAGS in Makefile

[Borislav Petkov]

On Mon, Sep 16, 2013 at 11:11:16AM +0900, Namhyung Kim wrote:
> -$(OUTPUT)util/scripting-engines/trace-event-perl.o: 
> util/scripting-engines/trace-event-perl.c $(OUTPUT)PERF-CFLAGS
> - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $(PERL_EMBED_CCOPTS) 
> -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow 
> -Wno-undef -Wno-switch-default $<
> -
> -$(OUTPUT)scripts/perl/Perf-Trace-Util/Context.o: 
> scripts/perl/Perf-Trace-Util/Context.c $(OUTPUT)PERF-CFLAGS
> - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $(PERL_EMBED_CCOPTS) 
> -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter 
> -Wno-nested-externs -Wno-undef -Wno-switch-default $<
> -
> -$(OUTPUT)util/scripting-engines/trace-event-python.o: 
> util/scripting-engines/trace-event-python.c $(OUTPUT)PERF-CFLAGS
> - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $(PYTHON_EMBED_CCOPTS) 
> -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow 
> $<
> -
> -$(OUTPUT)scripts/python/Perf-Trace-Util/Context.o: 
> scripts/python/Perf-Trace-Util/Context.c $(OUTPUT)PERF-CFLAGS
> - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $(PYTHON_EMBED_CCOPTS) 
> -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter 
> -Wno-nested-externs $<

What happened with the trailing -W options in each target above?
Looks like they've been dropped because I can't find them in the new
definitions...

Thanks.

-- 
Regards/Gruss,
Boris.

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

mmotm 2013-09-20-15-59 uploaded

[akpm]

The mm-of-the-moment snapshot 2013-09-20-15-59 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (3.x
or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/?p=linux-mmots.git;a=summary

and use of this tree is similar to
http://git.cmpxchg.org/?p=linux-mmotm.git, described above.


This mmotm tree contains the following patches against 3.12-rc1:
(patches marked "*" will be included in linux-next)

  origin.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
  i-need-old-gcc.patch
* watchdog-update-watchdog-attributes-atomically.patch
* watchdog-update-watchdog_tresh-properly.patch
* watchdog-update-watchdog_tresh-properly-fix.patch
* fs-ocfs2-superc-use-a-bigger-nodestr-in-ocfs2_dismount_volume.patch
* revert-memcg-vmscan-do-not-fall-into-reclaim-all-pass-too-quickly.patch
* revert-memcg-track-all-children-over-limit-in-the-root.patch
* 
revert-memcg-vmscan-do-not-attempt-soft-limit-reclaim-if-it-would-not-scan-anything.patch
* revert-memcg-track-children-in-soft-limit-excess-to-improve-soft-limit.patch
* revert-memcg-enhance-memcg-iterator-to-support-predicates.patch
* revert-vmscan-memcg-do-softlimit-reclaim-also-for-targeted-reclaim.patch
* revert-memcg-get-rid-of-soft-limit-tree-infrastructure.patch
* 
revert-memcg-vmscan-integrate-soft-reclaim-tighter-with-zone-shrinking-code.patch
* audit-fix-endless-wait-in-audit_log_start.patch
* kernel-rebootc-re-enable-the-function-of-variable-reboot_default.patch
* kernel-rebootc-re-enable-the-function-of-variable-reboot_default-fix.patch
* cpqarray-fix-info-leak-in-ida_locked_ioctl.patch
* cciss-fix-info-leak-in-cciss_ioctl32_passthru.patch
* 
nilfs2-fix-issue-with-race-condition-of-competition-between-segments-for-dirty-blocks.patch
* checkpatch-make-extern-in-h-prototypes-quieter.patch
* maintainers-update-mach-bcm-related-email-address.patch
* revert-mm-memory-hotplug-fix-lowmem-count-overflow-when-offline-pages.patch
* fs-binfmt_elfc-prevent-a-coredump-with-a-large-vm_map_count-from-oopsing.patch
* 
fs-binfmt_elfc-prevent-a-coredump-with-a-large-vm_map_count-from-oopsing-fix.patch
* include-linux-of_irqh-fix-warnings-when-config_of=n.patch
* mm-compactionc-periodically-schedule-when-freeing-pages.patch
* sh64-kernel-use-usp-instead-of-fn.patch
* sh64-kernel-remove-useless-variable-regs.patch
* mm-acpi-use-numa_no_node.patch
* 
arch-x86-include-asm-pgtable-2levelh-clean-up-pte_to_pgoff-and-pgoff_to_pte-helpers.patch
* 
arch-x86-include-asm-pgtable-2levelh-clean-up-pte_to_pgoff-and-pgoff_to_pte-helpers-update.patch
* x86-srat-use-numa_no_node.patch
* sound-soc-atmel-atmel-pcmc-fix-warning.patch
* drivers-pcmcia-pd6729c-convert-to-module_pci_driver.patch
* drivers-pcmcia-yenta_socketc-convert-to-module_pci_driver.patch
* drm-fb-helper-dont-sleep-for-screen-unblank-when-an-oopps-is-in-progress.patch
* drm-cirrus-correct-register-values-for-16bpp.patch
* drm-nouveau-make-vga_switcheroo-code-depend-on-vga_switcheroo.patch
* 

[PATCH] x86: Add quirk to make Dell C6100 use reboot=pci.

[Vinson Lee]

From: Masoud Sharbiani 

Dell PowerEdge C6100 machines fail to completely reboot about 20% of the
time.

Signed-off-by: Masoud Sharbiani 
Cc: sta...@vger.kernel.org
Signed-off-by: Vinson Lee 
---
 arch/x86/kernel/reboot.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index df1b604..d139208 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -479,6 +479,22 @@ static struct dmi_system_id __initdata 
pci_reboot_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
},
},
+   {   /* Handle problems with rebooting on the Dell PowerEdge C6100. 
*/
+   .callback = set_pci_reboot,
+   .ident = "Dell PowerEdge C6100",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
+   },
+   },
+   {   /* Some C6100 machines were shipped with vendor being 'Dell'. */
+   .callback = set_pci_reboot,
+   .ident = "Dell PowerEdge C6100",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
+   },
+   },
{ }
 };
 
-- 
1.8.1.2

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

[PATCH 2/2] drivers: edac: octeon: add error injection support

[Daniel Walker]

This adds an ad-hoc error injection method. Octeon II doesn't have
hardware support for injection, so this simulates it.

Signed-off-by: Daniel Walker 
---
 drivers/edac/octeon_edac-lmc.c | 177 +++--
 1 file changed, 171 insertions(+), 6 deletions(-)

diff --git a/drivers/edac/octeon_edac-lmc.c b/drivers/edac/octeon_edac-lmc.c
index 4881ad0..4bd10f9 100644
--- a/drivers/edac/octeon_edac-lmc.c
+++ b/drivers/edac/octeon_edac-lmc.c
@@ -5,12 +5,16 @@
  *
  * Copyright (C) 2009 Wind River Systems,
  *   written by Ralf Baechle 
+ *
+ * Copyright (c) 2013 by Cisco Systems, Inc.
+ * All rights reserved.
  */
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -20,6 +24,18 @@
 
 #define OCTEON_MAX_MC 4
 
+#define to_mci(k) container_of(k, struct mem_ctl_info, dev)
+
+struct octeon_lmc_pvt {
+   unsigned long inject;
+   unsigned long error_type;
+   unsigned long dimm;
+   unsigned long rank;
+   unsigned long bank;
+   unsigned long row;
+   unsigned long col;
+};
+
 static void octeon_lmc_edac_poll(struct mem_ctl_info *mci)
 {
union cvmx_lmcx_mem_cfg0 cfg0;
@@ -55,14 +71,31 @@ static void octeon_lmc_edac_poll(struct mem_ctl_info *mci)
 
 static void octeon_lmc_edac_poll_o2(struct mem_ctl_info *mci)
 {
+   struct octeon_lmc_pvt *pvt = mci->pvt_info;
union cvmx_lmcx_int int_reg;
bool do_clear = false;
char msg[64];
 
-   int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx));
+   if (!pvt->inject)
+   int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx));
+   else {
+   if (pvt->error_type == 1)
+   int_reg.s.sec_err = 1;
+   if (pvt->error_type == 2)
+   int_reg.s.ded_err = 1;
+   }
+
if (int_reg.s.sec_err || int_reg.s.ded_err) {
union cvmx_lmcx_fadr fadr;
-   fadr.u64 = cvmx_read_csr(CVMX_LMCX_FADR(mci->mc_idx));
+   if (likely(!pvt->inject))
+   fadr.u64 = cvmx_read_csr(CVMX_LMCX_FADR(mci->mc_idx));
+   else {
+   fadr.cn61xx.fdimm = pvt->dimm;
+   fadr.cn61xx.fbunk = pvt->rank;
+   fadr.cn61xx.fbank = pvt->bank;
+   fadr.cn61xx.frow = pvt->row;
+   fadr.cn61xx.fcol = pvt->col;
+   }
snprintf(msg, sizeof(msg),
 "DIMM %d rank %d bank %d row %d col %d",
 fadr.cn61xx.fdimm, fadr.cn61xx.fbunk,
@@ -82,8 +115,128 @@ static void octeon_lmc_edac_poll_o2(struct mem_ctl_info 
*mci)
int_reg.s.ded_err = -1; /* Done, re-arm */
do_clear = true;
}
-   if (do_clear)
-   cvmx_write_csr(CVMX_LMCX_INT(mci->mc_idx), int_reg.u64);
+
+   if (do_clear) {
+   if (likely(!pvt->inject))
+   cvmx_write_csr(CVMX_LMCX_INT(mci->mc_idx), int_reg.u64);
+   else
+   pvt->inject = 0;
+   }
+}
+
+/ MC SYSFS parts ***/
+
+/* Only a couple naming differences per template, so very similar */
+#define TEMPLATE_SHOW(reg) \
+static ssize_t octeon_mc_inject_##reg##_show(struct device *dev,   \
+  struct device_attribute *attr,   \
+  char *data)  \
+{  \
+   struct mem_ctl_info *mci = to_mci(dev); \
+   struct octeon_lmc_pvt *pvt = mci->pvt_info; \
+   return sprintf(data, "%016llu\n", (u64)pvt->reg);   \
+}
+
+#define TEMPLATE_STORE(reg)\
+static ssize_t octeon_mc_inject_##reg##_store(struct device *dev,  \
+  struct device_attribute *attr,   \
+  const char *data, size_t count)  \
+{  \
+   struct mem_ctl_info *mci = to_mci(dev); \
+   struct octeon_lmc_pvt *pvt = mci->pvt_info; \
+   if (isdigit(*data)) {   \
+   if (!kstrtoul(data, 0, >reg))  \
+   return count;   \
+   }   \
+   return 0;   \
+}
+
+TEMPLATE_SHOW(inject);
+TEMPLATE_STORE(inject);
+TEMPLATE_SHOW(dimm);
+TEMPLATE_STORE(dimm);
+TEMPLATE_SHOW(bank);
+TEMPLATE_STORE(bank);
+TEMPLATE_SHOW(rank);
+TEMPLATE_STORE(rank);
+TEMPLATE_SHOW(row);
+TEMPLATE_STORE(row);

[PATCH 1/2] drivers: edac: octeon: fix lack of opstate_init

[Daniel Walker]

If the opstate_init() isn't called the driver won't start properly.

I just added it in what appears to be an appropriate place.

Signed-off-by: Daniel Walker 
---
 drivers/edac/octeon_edac-lmc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/edac/octeon_edac-lmc.c b/drivers/edac/octeon_edac-lmc.c
index 93412d6..4881ad0 100644
--- a/drivers/edac/octeon_edac-lmc.c
+++ b/drivers/edac/octeon_edac-lmc.c
@@ -92,6 +92,8 @@ static int octeon_lmc_edac_probe(struct platform_device *pdev)
struct edac_mc_layer layers[1];
int mc = pdev->id;
 
+   opstate_init();
+
layers[0].type = EDAC_MC_LAYER_CHANNEL;
layers[0].size = 1;
layers[0].is_virt_csrow = false;
-- 
1.8.1.2

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

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

[Martin K. Petersen]

> "Bernd" == Bernd Schubert  writes:

[Sorry about the delay. Catching up on a couple of weeks worth of email]

Bernd> So if anything else than a Seagate drive is connected to an Areca
Bernd> controller with older firmware it will still fail.

It's just blacklisting a specific Seagate drive. However, skip_vpd_pages
is also set by USB.

I'm still completely in favor of your patch to reduce the VPD buffer
size. Please resubmit and feel free to add my Acked-by:.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: Device driver for sTec's PCIe Kronos Card.

[Andrew Morton]

On Tue, 17 Sep 2013 14:20:55 -0600 Jens Axboe  wrote:

> > So, it looks like this driver needs a bunch of work before it's ready
> > to go in. Or, maybe it's better to submit it with a TODO list for the
> > staging tree instead?
> 
> Not disagreeing with you, it definitely needs a bit of cleaning. And so
> far stec has not been very responsive in fixing those issues.

Geeze.  Here's what I came up with, mainly to make i386 compile:


From: Andrew Morton 
Subject: drivers/block/skd_main.c: fix a few things, disable on 32-bit

Fix these (i386 allmodconfig):

drivers/block/skd_main.c:4559: warning: format '%lu' expects type 'long 
unsigned int', but argument 5 has type 'unsigned int'
drivers/block/skd_main.c:4614: warning: format '%lu' expects type 'long 
unsigned int', but argument 5 has type 'unsigned int'
drivers/block/skd_main.c:4614: warning: format '%lu' expects type 'long 
unsigned int', but argument 7 has type 'unsigned int'
drivers/block/skd_main.c:4626: warning: format '%lu' expects type 'long 
unsigned int', but argument 6 has type 'unsigned int'
drivers/block/skd_main.c:4626: warning: format '%lu' expects type 'long 
unsigned int', but argument 7 has type 'unsigned int'
drivers/block/skd_main.c:4671: warning: format '%lu' expects type 'long 
unsigned int', but argument 5 has type 'unsigned int'
drivers/block/skd_main.c:4671: warning: format '%lu' expects type 'long 
unsigned int', but argument 7 has type 'unsigned int'

And what remains is these:

drivers/block/skd_main.c: In function 'skd_reg_write64':
drivers/block/skd_main.c:439: error: implicit declaration of function 'writeq'
drivers/block/skd_main.c:441: error: implicit declaration of function 'readq'
drivers/block/skd_main.c: In function 'skd_cons_skmsg':
drivers/block/skd_main.c:4589: warning: cast from pointer to integer of 
different size
drivers/block/skd_main.c:4592: warning: cast from pointer to integer of 
different size
drivers/block/skd_main.c:4593: warning: cast to pointer from integer of 
different size

Which is more than I'm prepared to address, so just disable the driver on
32-bit builds.

Cc: Akhil Bhansali 
Cc: Jeff Moyer 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
---

 drivers/block/Kconfig|1 +
 drivers/block/skd_main.c |8 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff -puN 
drivers/block/skd_main.c~drivers-block-skd_mainc-fix-a-few-things-disable-on-32-bit
 drivers/block/skd_main.c
--- 
a/drivers/block/skd_main.c~drivers-block-skd_mainc-fix-a-few-things-disable-on-32-bit
+++ a/drivers/block/skd_main.c
@@ -4556,7 +4556,7 @@ static int skd_cons_skmsg(struct skd_dev
int rc = 0;
u32 i;
 
-   VPRINTK(skdev, "skmsg_table kzalloc, struct %lu, count %u total %lu\n",
+   VPRINTK(skdev, "skmsg_table kzalloc, struct %u, count %u total %lu\n",
sizeof(struct skd_fitmsg_context),
skdev->num_fitmsg_context,
(unsigned long) sizeof(struct skd_fitmsg_context) *
@@ -4611,7 +4611,7 @@ static int skd_cons_skreq(struct skd_dev
int rc = 0;
u32 i;
 
-   VPRINTK(skdev, "skreq_table kzalloc, struct %lu, count %u total %lu\n",
+   VPRINTK(skdev, "skreq_table kzalloc, struct %u, count %u total %u\n",
sizeof(struct skd_request_context),
skdev->num_req_context,
sizeof(struct skd_request_context) * skdev->num_req_context);
@@ -4623,7 +4623,7 @@ static int skd_cons_skreq(struct skd_dev
goto err_out;
}
 
-   VPRINTK(skdev, "alloc sg_table sg_per_req %u scatlist %lu total %lu\n",
+   VPRINTK(skdev, "alloc sg_table sg_per_req %u scatlist %u total %u\n",
skdev->sgs_per_request, sizeof(struct scatterlist),
skdev->sgs_per_request * sizeof(struct scatterlist));
 
@@ -4668,7 +4668,7 @@ static int skd_cons_skspcl(struct skd_de
int rc = 0;
u32 i, nbytes;
 
-   VPRINTK(skdev, "skspcl_table kzalloc, struct %lu, count %u total %lu\n",
+   VPRINTK(skdev, "skspcl_table kzalloc, struct %u, count %u total %u\n",
sizeof(struct skd_special_context),
skdev->n_special,
sizeof(struct skd_special_context) * skdev->n_special);
diff -puN 
drivers/block/Kconfig~drivers-block-skd_mainc-fix-a-few-things-disable-on-32-bit
 drivers/block/Kconfig
--- 
a/drivers/block/Kconfig~drivers-block-skd_mainc-fix-a-few-things-disable-on-32-bit
+++ a/drivers/block/Kconfig
@@ -319,6 +319,7 @@ config BLK_DEV_NVME
 config BLK_DEV_SKD
tristate "STEC S1120 Block Driver"
depends on PCI
+   depends on 64BIT
---help---
Saying Y or M here will enable support for the
STEC, Inc. S1120 PCIe SSD.
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: Update mach-bcm related email address

[Christian Daudt]

Update email address on mach-bcm + drivers for Broadcom
mobile SoCs.

Signed-off-by: Christian Daudt 
Cc: Olof Johansson 
Cc: Arnd Bergmann 
Cc: Stephen Warren 

diff --git a/MAINTAINERS b/MAINTAINERS
index e61c2e8..b2f857c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1812,7 +1812,8 @@ S:Supported
 F: drivers/net/ethernet/broadcom/bnx2x/
 
 BROADCOM BCM281XX/BCM11XXX ARM ARCHITECTURE
-M: Christian Daudt 
+M: Christian Daudt 
+L: bcm-kernel-feedback-l...@broadcom.com
 T: git git://git.github.com/broadcom/bcm11351
 S: Maintained
 F: arch/arm/mach-bcm/
-- 
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] fs: exec.c: Coding style sanitization

[Geyslan G. Bem]

Adjustment based on the checkpatch.pl.

Tested.

Signed-off-by: Geyslan G. Bem 
---
 fs/exec.c | 92 ++-
 1 file changed, 49 insertions(+), 43 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 8875dd1..b5c6086 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -19,7 +19,7 @@
  * current->executable is only used by the procfs.  This allows a dispatch
  * table to check for several different types  of binary formats.  We keep
  * trying until we recognize the file or we run out of supported binary
- * formats. 
+ * formats.
  */
 
 #include 
@@ -55,8 +55,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 #include 
 
@@ -71,7 +71,7 @@ int suid_dumpable = 0;
 static LIST_HEAD(formats);
 static DEFINE_RWLOCK(binfmt_lock);
 
-void __register_binfmt(struct linux_binfmt * fmt, int insert)
+void __register_binfmt(struct linux_binfmt *fmt, int insert)
 {
BUG_ON(!fmt);
if (WARN_ON(!fmt->load_binary))
@@ -81,19 +81,17 @@ void __register_binfmt(struct linux_binfmt * fmt, int 
insert)
 list_add_tail(>lh, );
write_unlock(_lock);
 }
-
 EXPORT_SYMBOL(__register_binfmt);
 
-void unregister_binfmt(struct linux_binfmt * fmt)
+void unregister_binfmt(struct linux_binfmt *fmt)
 {
write_lock(_lock);
list_del(>lh);
write_unlock(_lock);
 }
-
 EXPORT_SYMBOL(unregister_binfmt);
 
-static inline void put_binfmt(struct linux_binfmt * fmt)
+static inline void put_binfmt(struct linux_binfmt *fmt)
 {
module_put(fmt->module);
 }
@@ -136,8 +134,8 @@ SYSCALL_DEFINE1(uselib, const char __user *, library)
fsnotify_open(file);
 
error = -ENOEXEC;
-   if(file->f_op) {
-   struct linux_binfmt * fmt;
+   if (file->f_op) {
+   struct linux_binfmt *fmt;
 
read_lock(_lock);
list_for_each_entry(fmt, , lh) {
@@ -154,10 +152,11 @@ SYSCALL_DEFINE1(uselib, const char __user *, library)
}
read_unlock(_lock);
}
+
 exit:
fput(file);
 out:
-   return error;
+   return error;
 }
 
 #ifdef CONFIG_MMU
@@ -180,7 +179,7 @@ static void acct_arg_size(struct linux_binprm *bprm, 
unsigned long pages)
 }
 
 static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
-   int write)
+int write)
 {
struct page *page;
int ret;
@@ -241,7 +240,7 @@ static void free_arg_pages(struct linux_binprm *bprm)
 }
 
 static void flush_arg_page(struct linux_binprm *bprm, unsigned long pos,
-   struct page *page)
+  struct page *page)
 {
flush_cache_page(bprm->vma, pos, page_to_pfn(page));
 }
@@ -268,7 +267,9 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
BUILD_BUG_ON(VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP);
vma->vm_end = STACK_TOP_MAX;
vma->vm_start = vma->vm_end - PAGE_SIZE;
-   vma->vm_flags = VM_SOFTDIRTY | VM_STACK_FLAGS | 
VM_STACK_INCOMPLETE_SETUP;
+   vma->vm_flags = (VM_SOFTDIRTY |
+VM_STACK_FLAGS |
+VM_STACK_INCOMPLETE_SETUP);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
INIT_LIST_HEAD(>anon_vma_chain);
 
@@ -299,7 +300,7 @@ static inline void acct_arg_size(struct linux_binprm *bprm, 
unsigned long pages)
 }
 
 static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
-   int write)
+int write)
 {
struct page *page;
 
@@ -335,7 +336,7 @@ static void free_arg_pages(struct linux_binprm *bprm)
 }
 
 static void flush_arg_page(struct linux_binprm *bprm, unsigned long pos,
-   struct page *page)
+  struct page *page)
 {
 }
 
@@ -616,7 +617,9 @@ static int shift_arg_pages(struct vm_area_struct *vma, 
unsigned long shift)
 * when the old and new regions overlap clear from new_end.
 */
free_pgd_range(, new_end, old_end, new_end,
-   vma->vm_next ? vma->vm_next->vm_start : 
USER_PGTABLES_CEILING);
+  vma->vm_next
+  ? vma->vm_next->vm_start
+  : USER_PGTABLES_CEILING);
} else {
/*
 * otherwise, clean from old_start; this is done to not touch
@@ -625,7 +628,9 @@ static int shift_arg_pages(struct vm_area_struct *vma, 
unsigned long shift)
 * for the others its just a little faster.
 */
free_pgd_range(, old_start, old_end, new_end,
-   vma->vm_next ? vma->vm_next->vm_start : 
USER_PGTABLES_CEILING);
+  vma->vm_next
+  ? vma->vm_next->vm_start
+  : USER_PGTABLES_CEILING);
}
tlb_finish_mmu(, old_start, old_end);
 

[RFC PATCH] thermal: add generic cpu hotplug cooling device

[Zoran Markovic]

This patch implements a generic CPU hotplug cooling device. The
implementation scales down the number of running CPUs when temperature
increases through a thermal trip point and prevents booting CPUs
until thermal conditions are restored. Upon restoration, the action
of starting up a CPU is left to another entity (e.g. CPU offline
governor, for which a patch is in the works).

In the past two years, ARM considerably reduced the time required for
CPUs to boot and shutdown; this time is now measured in microseconds.
This patch is predominantly intended for ARM big.LITTLE architectures
where big cores are expected to have a much bigger impact on thermal
budget than little cores, resulting in fast temperature ramps to a trip
point, i.e. thermal runaways. Switching off the big core(s) may be one
of the recovery mechanisms to restore system temperature, but the actual
strategy is left to the thermal governor.

The assumption is that CPU shutdown/startup is a rare event, so no
attempt was made to make the code atomic, i.e. the code evidently races
with CPU hotplug driver. The set_cur_state() function offlines CPUs
iteratively one at a time, checking the cooling state before each CPU
shutdown. A hotplug notifier callback validates any CPU boot requests
against current cooling state and approves/denies accordingly. This
mechanism guarantees that the desired cooling state could be reached in a
maximum of d-c iterations, where d and c are the "desired" and "current"
cooling states expressed in the number of offline CPUs.

Credits to Amit Daniel Kachhap for initial attempt to upstream this feature.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Rob Landley 
Cc: Amit Daniel Kachhap 
Cc: Andrew Morton 
Cc: Durgadoss R 
Cc: Christian Daudt 
Cc: James King 
Signed-off-by: Zoran Markovic 
---
 Documentation/thermal/cpu-cooling-api.txt |   17 ++
 drivers/thermal/Kconfig   |   10 +
 drivers/thermal/Makefile  |1 +
 drivers/thermal/cpu_hotplug.c |  362 +
 include/linux/cpuhp_cooling.h |   57 +
 5 files changed, 447 insertions(+)
 create mode 100644 drivers/thermal/cpu_hotplug.c
 create mode 100644 include/linux/cpuhp_cooling.h

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
index fca24c9..2f94f68 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -30,3 +30,20 @@ the user. The registration APIs returns the cooling device 
pointer.
 This interface function unregisters the "thermal-cpufreq-%x" cooling 
device.
 
 cdev: Cooling device pointer which has to be unregistered.
+
+1.2 cpu hotplug registration/unregistration APIs
+1.2.1 struct thermal_cooling_device *cpuhp_cooling_register(
+   struct cpumask *cpus, const char *ext)
+
+This function creates and registers a cpu hotplug cooling device with
+the name "cpu-hotplug-%s".
+
+cpus: cpumask of cpu cores participating in cooling.
+ext: instance-specific name of device
+
+1.2.2 void cpuhotplug_cooling_unregister(struct thermal_cooling_device *cdev)
+
+This function unregisters and frees the cpu hotplug cooling device cdev.
+
+cdev: Pointer to cooling device to unregister.
+
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 52b6ed7..3509100 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -79,6 +79,16 @@ config CPU_THERMAL
 
  If you want this support, you should say Y here.
 
+config CPU_THERMAL_HOTPLUG
+   bool "Generic CPU hotplug cooling"
+   depends on HOTPLUG_CPU
+   help
+ Shutdown CPUs to prevent the device from overheating. This feature
+ uses generic CPU hot-unplug capabilities to control device
+ temperature. When the temperature increases over a trip point, a
+ random subset of CPUs is shut down to reach the desired cooling
+ state.
+
 config THERMAL_EMULATION
bool "Thermal emulation mode support"
help
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 5ee0db0..0bd08be 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -12,6 +12,7 @@ thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE)  += user_space.o
 
 # cpufreq cooling
 thermal_sys-$(CONFIG_CPU_THERMAL)  += cpu_cooling.o
+thermal_sys-$(CONFIG_CPU_THERMAL_HOTPLUG)  += cpu_hotplug.o
 
 # platform thermal drivers
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
diff --git a/drivers/thermal/cpu_hotplug.c b/drivers/thermal/cpu_hotplug.c
new file mode 100644
index 000..8c3021e
--- /dev/null
+++ b/drivers/thermal/cpu_hotplug.c
@@ -0,0 +1,362 @@
+/*
+ *  drivers/thermal/cpu_hotplug.c
+ *
+ *  Copyright (C) 2013  Broadcom Corporation Ltd.
+ *  Copyright (C) 2013  Zoran Markovic 
+ *
+ * ~~
+ *  This program is free software; you can redistribute it and/or modify
+ *  

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

[Linus Torvalds]

On Fri, Sep 20, 2013 at 9:26 AM, Frederic Weisbecker  wrote:
>
> Now just for clarity, what do we then do with inline sofirq executions: on 
> local_bh_enable()
> for example, or explicit calls to do_softirq() other than irq exit?

If we do a softirq because it was pending and we did a
"local_bh_enable()" in normal code, we need a new stack. The
"local_bh_enable()" may be pretty deep in the callchain on a normal
process stack, so I think it would be safest to switch to a separate
stack for softirq handling.

So you have a few different cases:

 - irq_exit(). The irq stack is by definition empty (assuming
itq_exit() is done on the irq stack), so doing softirq in that context
should be fine. However, that assumes that if we get *another*
interrupt, then we'll switch stacks again, so this does mean that we
need two irq stacks. No, irq's don't nest, but if we run softirq on
the first irq stack, the other irq *can* nest that softirq.

 - process context doing local_bh_enable, and a bh became pending
while it was disabled. See above: this needs a stack switch. Which
stack to use is open, again assuming that a hardirq coming in will
switch to yet another stack.

Hmm?

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

Re: BUG: sleeping function called from invalid context on 3.10.10-rt7

[Mario Kleiner]

On 09/17/2013 10:55 PM, Daniel Vetter wrote:

On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley  wrote:

On 09/11/2013 03:31 PM, Peter Hurley wrote:


[+cc dri-devel]

On 09/11/2013 11:38 AM, Steven Rostedt wrote:


On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley  wrote:


The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" can call functions that use the rt-mutex
"sleeping spin locks" and it breaks there.

I guess we need to ask the authors of the mainline patch exactly why
that preempt_disable() is needed?



The drm core associates a timestamp with each vertical blank frame #.
Drm drivers can optionally support a 'high resolution' hw timestamp.
The vblank frame #/timestamp tuple is user-space visible.

The i915 drm driver supports a hw timestamp via this drm helper function
which computes the timestamp from the crtc scan position (based on the
pixel clock).

For mainline, the preempt_disable/_enable() isn't actually necessary
because every call tree that leads here already has preemption disabled.

For -RT, the maybe i915 register spinlock (uncore.lock) should be raw?



No, it should not. Note, any other lock that can be held when it is
held would also need to be raw.



By that, you mean "any other lock" that might be claimed "would also need
to be raw"?  Hopefully not "any other lock" already held?


And by taking a quick audit of the code, I see this:

 spin_lock_irqsave(_priv->uncore.lock, irqflags);

 /* Reset the chip */

 /* GEN6_GDRST is not in the gt power well, no need to check
  * for fifo space for the write or forcewake the chip for
  * the read
  */
 __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL);

 /* Spin waiting for the device to ack the reset request */
 ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) &
GEN6_GRDOM_FULL) == 0, 500);

That spin is unacceptable in RT with preemption and interrupts disabled.



Yep. That would be bad.

AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included
in the force-wake set, so raw reads of the registers would
probably be acceptable (thus obviating the need for claiming the
uncore.lock).

Except that _ALL_ register access is disabled with the uncore.lock
during a gpu reset. Not sure if that's meant to include crtc registers
or not, or what other synchronization/serialization issues are being
handled/hidden by forcing all register accesses to wait during a gpu
reset.

Hopefully an i915 expert can weigh in here?




Daniel,

Can you shed some light on whether the i915+ crtc registers (specifically
those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter())
read as part of the vblank counter/timestamp handling need to
be prevented during gpu reset?


The depency here in the locking is a recent addition:

commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a
Author: Chris Wilson 
Date:   Fri Jul 19 20:36:51 2013 +0100

 drm/i915: Serialize almost all register access

It's a (slightly) oversized hammer to work around a hardware issue -
we could break it down to register blocks, which can be accessed
concurrently, but that tends to be more fragile. But the chip really
dies if you access (even just reads) the same block concurrently :(

We could try break the spinlock protected section a bit in the reset
handler - register access on a hung gpu tends to be ill-defined
anyway.


The implied wait with preemption and interrupts disabled is causing grief
in -RT, but also a 4ms wait inside an irq handler seems like a bad idea.


Oops, the magic code in wait_for which is just there to make the imo
totally misguided kgdb support work papered over the aweful long wait
in atomic context ever since we've added this in

commit b6e45f866465f42b53d803b0c574da0fc508a0e9
Author: Keith Packard 
Date:   Fri Jan 6 11:34:04 2012 -0800

 drm/i915: Move reset forcewake processing to gen6_do_reset

Reverting this change should be enough (code moved obviously a bit).

Cheers, Daniel



Regards,
Peter Hurley




What's the real issue here?



That the vblank timestamp needs to be an accurate measurement of a
realtime event. Sleeping/servicing interrupts while reading
the registers necessary to compute the timestamp would be bad too.

(edit: which hopefully Mario Kleiner clarified in his reply)

My point earlier was three-fold:
1. Don't need the preempt_disable() for mainline: all callers are already
 holding interrupt-disabling spinlocks.
2. -RT still needs to prevent scheduling there.
3. the problem is i915-specific.

[update: the radeon driver should also BUG like the i915 driver but
probably
should have mmio_idx_lock spinlock as raw]




Ok, so register access must be serialized, at least within a register 
block, no way around it. Thanks for explaining this. That makes me a bit 
depressed. Is this also true for older hw generations than gen6?


Daniel, could we move access to the display register 

Re: [PATCH] media: i2c: add driver for dual LED Flash, lm3560.

[Sakari Ailus]

Hi Daniel,

A few more comments.

On Wed, Sep 11, 2013 at 04:45:31PM +0900, Daniel Jeong wrote:
...
> +struct lm3560_flash {
> + struct lm3560_platform_data *pdata;
> + struct regmap *regmap;
> + struct mutex power_lock;
> + int power_count;
> +
> + enum v4l2_flash_led_mode led_mode;
> + u8 fault;

If you have common properties, you can use v4l2_ctrl_add_handler() to get a
reference of a contro (or controls) from another handler. No tricks needed.

I thik it'd still make sense to 

> + /* LED1 */
> + struct v4l2_ctrl_handler ctrls_led1;
> + struct v4l2_subdev subdev_led1;
> + /* LED2 */
> + struct v4l2_ctrl_handler ctrls_led2;
> + struct v4l2_subdev subdev_led2;
> +};
> +
> +/* i2c access */
> +static int lm3560_read(struct lm3560_flash *flash, unsigned int reg)
> +{
> + int rval;
> + unsigned int reg_val;
> +
> + rval = regmap_read(flash->regmap, reg, _val);
> + if (rval < 0)
> + return rval;
> + return reg_val & 0xFF;

What does lm3650_read() actually do for you?

> +}
> +
> +static int lm3560_update(struct lm3560_flash *flash,
> + unsigned int reg, unsigned int mask, unsigned int data)
> +{
> + return regmap_update_bits(flash->regmap, reg, mask, data);
> +}
> +
> +/* enable mode control */
> +static int lm3560_mode_ctrl(struct lm3560_flash *flash)
> +{
> + int rval = 0;
> +
> + rval = lm3560_update(flash, REG_FLASH_TOUT,
> +   PEAK_I_MASK, flash->pdata->peak);
> + if (rval < 0)
> + return rval;
> +
> + switch (flash->led_mode) {
> + case V4L2_FLASH_LED_MODE_NONE:
> + rval = lm3560_update(flash,
> +  REG_ENABLE, ENABLE_MODE_MASK, MODE_SHDN);
> + break;
> + case V4L2_FLASH_LED_MODE_TORCH:
> + rval = lm3560_update(flash,
> +  REG_ENABLE, ENABLE_MODE_MASK, MODE_TORCH);
> + break;
> + case V4L2_FLASH_LED_MODE_FLASH:
> + rval = lm3560_update(flash,
> +  REG_ENABLE, ENABLE_MODE_MASK, MODE_FLASH);
> + break;
> + }
> +
> + return rval;
> +}
> +
> +/* led1/2  enable/disable */
> +static int lm3560_enable_ctrl(struct lm3560_flash *flash,
> +   enum lm3560_led_id led_no, bool on)
f> +{
> + int rval = 0;
> +
> + if (led_no == LM3560_LED1) {
> + if (on == true)
> + rval = lm3560_update(flash, REG_ENABLE,
> +  LED1_ENABLE_MASK, LED1_ENABLE);
> + else
> + rval = lm3560_update(flash,
> +  REG_ENABLE, LED1_ENABLE_MASK, 0);
> + } else {
> + if (on == true)
> + rval = lm3560_update(flash, REG_ENABLE,
> +  LED2_ENABLE_MASK, LED2_ENABLE);
> + else
> + rval = lm3560_update(flash,
> +  REG_ENABLE, LED2_ENABLE_MASK, 0);
> + }
> + return rval;
> +}
> +
> +/* torch1/2 brightness control */
> +static int lm3560_torch_brt_ctrl(struct lm3560_flash *flash,
> +  enum lm3560_led_id led_no, unsigned int brt)
> +{
> + int rval;
> + u8 br_bits;
> +
> + if (brt < LM3560_TORCH_BRT_MIN) {
> + rval = lm3560_enable_ctrl(flash, led_no, false);
> + goto out;
> + } else {
> + rval = lm3560_enable_ctrl(flash, led_no, true);
> + }
> +
> + br_bits = LM3560_TORCH_BRT_uA_TO_REG(brt);
> + if (led_no == LM3560_LED1) {
> + rval = lm3560_update(flash, REG_TORCH_BR,
> +  TORCH1_BR_MASK, TORCH1_BR_DATA(br_bits));
> + if (rval < 0)
> + goto out;
> + } else {
> + rval = lm3560_update(flash, REG_TORCH_BR,
> +  TORCH2_BR_MASK, TORCH2_BR_DATA(br_bits));
> + if (rval < 0)
> + goto out;
> + }
> +out:
> + return rval;
> +}
> +
> +/* flash1/2 brightness control */
> +static int lm3560_flash_brt_ctrl(struct lm3560_flash *flash,
> +  enum lm3560_led_id led_no, unsigned int brt)
> +{
> + int rval;
> + u8 br_bits;
> +
> + if (brt < LM3560_FLASH_BRT_MIN) {
> + rval = lm3560_enable_ctrl(flash, led_no, false);
> + goto out;
> + } else {
> + rval = lm3560_enable_ctrl(flash, led_no, true);
> + }
> +
> + br_bits = LM3560_FLASH_BRT_uA_TO_REG(brt);
> + if (led_no == LM3560_LED1) {
> + rval = lm3560_update(flash, REG_FLASH_BR,
> +  FLASH1_BR_MASK, FLASH1_BR_DATA(br_bits));
> + if (rval < 0)
> + goto out;
> + } else {
> + rval = lm3560_update(flash, REG_FLASH_BR,
> +   

Re: [PATCH v4] clk: si570: Add a driver for SI570 oscillators

[Sören Brinkmann]

On Fri, Sep 20, 2013 at 11:15:29AM -0700, Guenter Roeck wrote:
> On Fri, Sep 20, 2013 at 10:39:17AM -0700, Soren Brinkmann wrote:
[...]
> > diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
> > new file mode 100644
> > index 000..13c2091
> > --- /dev/null
> > +++ b/drivers/clk/clk-si570.c
[...]
> > +static int si570_probe(struct i2c_client *client,
[...]
> > +   /* Read the requested initial output frequency from device tree */
> > +   if (!of_property_read_u32(client->dev.of_node, "clock-frequency",
> > +   _fout)) {
> > +   err = clk_set_rate(clk, initial_fout);
> > +   if (err) {
> > +   of_clk_del_provider(client->dev.of_node);
> > +   clk_unregister(data->hw.clk);
> 
> Is that needed ? I would have thought it isn't because you use a devm_ 
> function
> to register it.
> 
> Not that I understand the clk code, but getting clk from the registration
> function and unregistering hw.clk (without seting it) sems a bit odd.
> Is it well defined that you have to unregister hw.clk ?
You're absolutely right. I'll remove all calls to clk_unregister().
Thanks for finding that one.

Sören


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: gma500: remove double free in psbfb_create

[Patrik Jakobsson]

On Fri, Sep 20, 2013 at 3:56 PM, Dave Jones  wrote:
> This code appears to be calling psb_gtt_free_range twice with the same args.
> (The second call didn't appear in the diff output, it's right after the 
> mutex_unlock)
>
> Spotted with Coverity, not tested due to lack of hardware.
>
> Signed-off-by: Dave Jones 
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 01dd7d2..d35ffc4 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -479,9 +479,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
> mutex_unlock(>struct_mutex);
> return 0;
>  out_unref:
> -   if (backing->stolen)
> -   psb_gtt_free_range(dev, backing);
> -   else
> +   if (!backing->stolen)
> drm_gem_object_unreference(>gem);
>  out_err1:
> mutex_unlock(>struct_mutex);

Hi Dave, thanks for the patch.

This part of the code is a ref count disaster and probably needs to be
reworked anyways. It would be nice to always let drm_gem_object_unreference()
do the final cleanup call to psb_gtt_free_range() but stolen memory is treated
as an exception in some cases. Also we don't seem to take down the framebuffer
correctly on failure after drm_framebuffer_init() which seems scary.
psb_framebuffer_init() calls drm_framebuffer_init() which clearly states that
we need to be done with the setup and stop failing at this point.

Also, we always get a stolen memory backed object (we're even lowering the
depth to make sure we get one) so the drm_gem_object_unreference() is a NOP.

Anyways, your patch looks good but I would like to look at this some more since
it seems broken anyways.

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

Re: [patch 2/6] h8300: Use schedule_preempt_irq

[Thomas Gleixner]

On Fri, 20 Sep 2013, Guenter Roeck wrote:

> On Tue, Sep 17, 2013 at 06:53:06PM -, Thomas Gleixner wrote:
> > Use the proper function instead of fiddling with PREEMPT_ACTIVE and
> > interrupt enable/disable in the low level code.
> > 
> > Signed-off-by: Thomas Gleixner 
> > Cc: Yoshinori Sato 
> > Cc: Geert Uytterhoeven 
> > 
> This will result in a conflict in -next as h8300 support has been removed
> there, and I'll send a pull request to Linus in the next commit window.

An easy to resolve one methinks :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/6] ARM: dts: exynos5250: add sclk_pcm_in to audss clock controller

[Andrew Bresticker]

The parent of sclk_pcm in the AudioSS block is div_pcm0.

Signed-off-by: Andrew Bresticker 
---
 arch/arm/boot/dts/exynos5250.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 7d7cc77..bedc7a8 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -88,6 +88,8 @@
compatible = "samsung,exynos5250-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
+   clocks = < 160>;
+   clock-names = "sclk_pcm_in";
};
 
timer {
-- 
1.8.4

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

Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB

[Scott Wood]

On Tue, 2013-09-17 at 18:40 +0200, leroy christophe wrote:
> Le 16/09/2013 23:02, Scott Wood a écrit :
> > On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote:
> >> Le 12/09/2013 20:44, Scott Wood a écrit :
> >>> On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
>  This is a reorganisation of the setup of the TLB at kernel startup, in 
>  order
>  to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of 
>  MPC866
>  and MPC885 reference manuals.
> 
>  Signed-off-by: Christophe Leroy 
> 
>  diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S 
>  linux-3.11/arch/powerpc/kernel/head_8xx.S
>  --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S2013-09-02 
>  22:46:10.0 +0200
>  +++ linux-3.11/arch/powerpc/kernel/head_8xx.S2013-09-09 
>  11:28:54.0 +0200
>  @@ -785,27 +785,24 @@
>  * these mappings is mapped by page tables.
>  */
> initial_mmu:
>  -tlbia   /* Invalidate all TLB entries */
>  -/* Always pin the first 8 MB ITLB to prevent ITLB
>  -   misses while mucking around with SRR0/SRR1 in asm
>  -*/
>  -lis r8, MI_RSV4I@h
>  -ori r8, r8, 0x1c00
>  -
>  +lis r8, MI_RESETVAL@h
>   mtspr   SPRN_MI_CTR, r8 /* Set instruction MMU control */
> 
>  -#ifdef CONFIG_PIN_TLB
>  -lis r10, (MD_RSV4I | MD_RESETVAL)@h
>  -ori r10, r10, 0x1c00
>  -mr  r8, r10
>  -#else
>   lis r10, MD_RESETVAL@h
>  -#endif
> #ifndef CONFIG_8xx_COPYBACK
>   orisr10, r10, MD_WTDEF@h
> #endif
>   mtspr   SPRN_MD_CTR, r10/* Set data TLB control */
> 
>  +tlbia   /* Invalidate all TLB entries */
> >>> Is this change to make sure we invalidate everything even if the
> >>> bootloader set RSV4I?
> >> Most probably. It is step 2 of the process defined in MPC866 and MPC885
> >> Reference Manuals:
> >>
> >> §8.10.3 Loading Locked TLB Entries:
> >> The process of loading a single reserved entry in the TLB is as follows:
> > To minimize code churn we should just fix actual problems, rather than
> > shuffle things around to conform to a suggested sequence.  After all,
> > we're not just trying to load a single entry.
> Ok, I'll try again.
> >
>  +ori r8, r8, 0x1c00
>  +mtspr   SPRN_MI_CTR, r8 /* Set instruction MMU control */
>  +#ifdef CONFIG_PIN_TLB
>  +ori r10, r10, 0x1c00
>  +mtspr   SPRN_MD_CTR, r10/* Set data TLB control */
>  +#endif
> >>> Still 0x1c00?
> >> Yes, I kept the same entries in order to limit modifications:
> >> * 28 = First 8Mbytes page
> >> * 29 = IMMR
> >> * 30 = Second 8Mbytes page
> >> * 31 = Third 8Mbytes page
> > If you actually want to program them in increasing order then it looks
> > like you're still missing a write to CTR between the last two 8M entries
> > -- thus you'll overwrite the IMMR with the last 8M entry.  That was the
> > same problem that v1 fixed -- did that change get lost accidentally?
> Oops, no, in fact I diffed from the version which was including it 
> already. My mistake.
> >
> > The hardware wants to decrement; why fight it?
> I see your point.
> However it is not clear in the documentation if the decrement is done 
> really after the update, or at xTLB interrupt. So I propose to still set 
> the CTR ourself as described in the reference Manual and not assume that 
> the HW decrements it.

It says "every update" -- do you have any reason to believe that's
wrong?  It could be tested...

-Scott



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

Re: [RFC 0/5] New descriptor-based GPIO interface

[Linus Walleij]

On Fri, Sep 20, 2013 at 9:32 PM, Thierry Reding
 wrote:

> Given that it seems like there won't be a linux-next from September 28
> until close to the next merge window, it would be good to get this into
> linux-next before that so that the series can receive broader testing.

Good point. Alexandre: ready when you are.

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/

[PATCH 2/6] clk: exynos-audss: allow input clocks to be specified in device tree

[Andrew Bresticker]

This allows the input clocks to the Exynos AudioSS block to be
specified via device-tree bindings.  Default names will be used
when an input clock is not given.

Signed-off-by: Andrew Bresticker 
---
 .../devicetree/bindings/clock/clk-exynos-audss.txt | 33 --
 drivers/clk/samsung/clk-exynos-audss.c | 25 
 2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt 
b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index 75e2e19..d51a2f9 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -14,6 +14,23 @@ Required Properties:
 
 - #clock-cells: should be 1.
 
+Optional Properties:
+
+- clocks:
+  - pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
+is used if not specified.
+  - pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
+is used if not specified.
+  - cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
+specified.
+  - sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
+not specified.
+  - sclk_pcm_in: PCM clock, parent of sclk_pcm.  "sclk_pcm0" is used if not
+specified.
+
+- clock-names: Aliases for the above clocks. They should be "pll_ref",
+  "pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively.
+
 The following is the list of clocks generated by the controller. Each clock is
 assigned an identifier and client nodes use this identifier to specify the
 clock which they consume. Some of the clocks are available only on a particular
@@ -35,15 +52,27 @@ sclk_i2s7
 pcm_bus 8
 sclk_pcm9
 
-Example 1: An example of a clock controller node is listed below.
+Example 1: An example of a clock controller node using the default input
+  clock names is listed below.
+
+clock_audss: audss-clock-controller@381 {
+   compatible = "samsung,exynos5250-audss-clock";
+   reg = <0x0381 0x0C>;
+   #clock-cells = <1>;
+};
+
+Example 2: An example of a clock controller node with audio bus input clock
+  specified is listed below.
 
 clock_audss: audss-clock-controller@381 {
compatible = "samsung,exynos5250-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
+   clocks = < 138>;
+   clock-names = "sclk_audio";
 };
 
-Example 2: I2S controller node that consumes the clock generated by the clock
+Example 3: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
 
diff --git a/drivers/clk/samsung/clk-exynos-audss.c 
b/drivers/clk/samsung/clk-exynos-audss.c
index 7571e88..aac5342 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -34,10 +34,6 @@ static unsigned long reg_save[][2] = {
{ASS_CLK_GATE, 0},
 };
 
-/* list of all parent clock list */
-static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
-static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
-
 #ifdef CONFIG_PM_SLEEP
 static int exynos_audss_clk_suspend(void)
 {
@@ -66,6 +62,10 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
 /* register exynos_audss clocks */
 static int exynos_audss_clk_probe(struct platform_device *pdev)
 {
+   const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
+   const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
+   const char *sclk_pcm_p = "sclk_pcm0";
+   struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
struct resource *res;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -88,11 +88,23 @@ static int exynos_audss_clk_probe(struct platform_device 
*pdev)
of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get,
_data);
 
+   pll_ref = devm_clk_get(>dev, "pll_ref");
+   pll_in = devm_clk_get(>dev, "pll_in");
+   if (!IS_ERR(pll_ref))
+   mout_audss_p[0] = __clk_get_name(pll_ref);
+   if (!IS_ERR(pll_in))
+   mout_audss_p[1] = __clk_get_name(pll_in);
clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
mout_audss_p, ARRAY_SIZE(mout_audss_p),
CLK_SET_RATE_NO_REPARENT,
reg_base + ASS_CLK_SRC, 0, 1, 0, );
 
+   cdclk = devm_clk_get(>dev, "cdclk");
+   sclk_audio = devm_clk_get(>dev, "sclk_audio");
+   if (!IS_ERR(cdclk))
+   mout_i2s_p[1] = __clk_get_name(cdclk);
+   if (!IS_ERR(sclk_audio))
+   mout_i2s_p[2] = __clk_get_name(sclk_audio);
clk_table[EXYNOS_MOUT_I2S] = clk_register_mux(NULL, "mout_i2s",
mout_i2s_p, 

Re: [PATCH 01/26] ARM: nomadik: move mtu setup to clocksource init

[Linus Walleij]

On Fri, Sep 20, 2013 at 11:08 PM, Sebastian Hesselbarth
 wrote:

> Ok, well I was looking at v3.12-rc1 and did not really follow other
> nomadik related threads. That time ux500 wasn't tangled up with
> clk-nomadik.

Well yeah, you're right. But Lee has a pending patch set that
makes the ux500 use this for its OF boot path...

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/

[PATCH 6/6] ARM: dts: exynos5420: add sclk_pcm_in to audss clock controller

[Andrew Bresticker]

The parent of sclk_pcm in the AudioSS block is sclk_maupcm0.

Signed-off-by: Andrew Bresticker 
---
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..339ab93 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -72,8 +72,8 @@
compatible = "samsung,exynos5420-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
-   clocks = < 148>;
-   clock-names = "sclk_audio";
+   clocks = < 148>, < 149>;
+   clock-names = "sclk_audio", "sclk_pcm_in";
};
 
codec@1100 {
-- 
1.8.4

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

Re: [PATCH] clockevents: Sanitize ticks to nsec conversion

[Thomas Gleixner]

On Fri, 20 Sep 2013, Uwe Kleine-König wrote:
> On Fri, Sep 20, 2013 at 11:56:27AM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Sep 2013, Uwe Kleine-König wrote:
> > > > +* from nsec to device ticks will be correct.
> > > > +*
> > > > +* For mult > (1 << shift), i.e. device frequency is > 1GHz we
> > > > +* need to be careful. Adding mult - 1 will result in a value
> > > > +* which when converted back to device ticks will be larger
> > > s/will/can/
> > 
> > No, it will always be larger.
> Hmm, consider a 1.25 GHz clock with shift = 2 and mult = 5. Then
> ns2clc(clc2ns(1000)) = 1000. So it's not always larger!
> In the fast-clock-case we have:
> With x << shift = n * mult - k for k in [0 .. mult-1] and an integer n:
> 
> ns2clc(clc2ns(x))
>   = ns2clc(((x << shift) + mult - 1) / mult)
>   = x << shift) + mult - 1) / mult) * mult) >> shift
>   = n * mult >> shift
>   = ((x << shift) + k) >> shift
>   = x + (k >> shift)
> 
> So ns2clc(clc2ns(x)) = x for all x > 0 that have
> 
>   k = mult - ((x << shift) - 1) % mult - 1 < 1 << shift
> 
> So my correction still stands.

Fair enough.  

> > 1) We cannot add if we'd overflow
> > 
> > 2) For mult <= 1 << shift it's always correct
> > 
> > 3) for mult > 1 << shift we only apply it to the min value not the max
> 
> Yeah, I didn't say your code is wrong *here*. I just think that my
> easier (and so probably faster) code is good enough.

Granted. I was stuck in the correctness discussion. So yeah, it does
not matter if we steal 30 usec of maximum idle sleep time from a 32kHz
clock. OTOH it does not matter much in the setup slow path to take
another conditional. :)

> Best regards and thanks for the nice discussion,
  
Ditto! You saved me from actually sitting down and using the pencil to
do the proper math.

Thanks,

tglx

Re: [PATCH 01/26] ARM: nomadik: move mtu setup to clocksource init

[Sebastian Hesselbarth]

On 09/18/2013 07:53 PM, Sebastian Hesselbarth wrote:

MTU timer initialization is stuffed into .init_time callback, while
cpu8815_timer_init_of again maps addresses from the same device node.
Therefore, this patch moves mtu setup from to clocksource init.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Olof Johansson 
Cc: Arnd Bergmann 
Cc: Alessandro Rubini 
Cc: Linus Walleij 
Cc: STEricsson 
Cc: Russell King 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
  arch/arm/mach-nomadik/cpu-8815.c  |   26 --
  drivers/clocksource/nomadik-mtu.c |   11 +++
  2 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 13e0df9..0fcb149 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -113,36 +113,10 @@ static void cpu8815_restart(enum reboot_mode mode, const 
char *cmd)
writel(1, srcbase + 0x18);
  }

-/* Initial value for SRC control register: all timers use MXTAL/8 source */
-#define SRC_CR_INIT_MASK   0x7fff
-#define SRC_CR_INIT_VAL0x2aaa8000
-
  static void __init cpu8815_timer_init_of(void)
  {
-   struct device_node *mtu;
-   void __iomem *base;
-   int irq;
-   u32 src_cr;
-
/* We need this to be up now */
nomadik_clk_init();
-
-   mtu = of_find_node_by_path("/mtu@101e2000");
-   if (!mtu)
-   return;
-   base = of_iomap(mtu, 0);
-   if (WARN_ON(!base))
-   return;
-   irq = irq_of_parse_and_map(mtu, 0);
-
-   pr_info("Remapped MTU @ %p, irq: %d\n", base, irq);
-
-   /* Configure timer sources in "system reset controller" ctrl reg */
-   src_cr = readl(base);
-   src_cr &= SRC_CR_INIT_MASK;
-   src_cr |= SRC_CR_INIT_VAL;
-   writel(src_cr, base);
-
clocksource_of_init();
  }


Linus,

looking at the fix you posted at [1], can I assume that the above it
redundant and can be removed?

[1] http://marc.info/?l=linux-arm-kernel=137910161418706=2


diff --git a/drivers/clocksource/nomadik-mtu.c 
b/drivers/clocksource/nomadik-mtu.c
index 1b74bea..b9f97ba 100644
--- a/drivers/clocksource/nomadik-mtu.c
+++ b/drivers/clocksource/nomadik-mtu.c
@@ -257,12 +257,17 @@ void __init nmdk_timer_init(void __iomem *base, int irq)
__nmdk_timer_init(base, irq, pclk0, clk0);
  }

+/* Initial value for SRC control register: all timers use MXTAL/8 source */
+#define SRC_CR_INIT_MASK   0x7fff
+#define SRC_CR_INIT_VAL0x2aaa8000
+
  static void __init nmdk_timer_of_init(struct device_node *node)
  {
struct clk *pclk;
struct clk *clk;
void __iomem *base;
int irq;
+   u32 src_cr;

base = of_iomap(node, 0);
if (!base)
@@ -280,6 +285,12 @@ static void __init nmdk_timer_of_init(struct device_node 
*node)
if (irq <= 0)
panic("Can't parse IRQ");

+   /* Configure timer sources in "system reset controller" ctrl reg */
+   src_cr = readl(base);
+   src_cr &= SRC_CR_INIT_MASK;
+   src_cr |= SRC_CR_INIT_VAL;
+   writel(src_cr, base);
+
__nmdk_timer_init(base, irq, pclk, clk);
  }
  CLOCKSOURCE_OF_DECLARE(nomadik_mtu, "st,nomadik-mtu",



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/6] clk: exynos-audss: add support for Exynos 5420

[Andrew Bresticker]

The AudioSS block on Exynos 5420 has an additional clock gate for the
ADMA bus clock.

Signed-off-by: Andrew Bresticker 
---
 Documentation/devicetree/bindings/clock/clk-exynos-audss.txt | 7 +--
 drivers/clk/samsung/clk-exynos-audss.c   | 8 
 include/dt-bindings/clk/exynos-audss-clk.h   | 3 ++-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt 
b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index d51a2f9..a10c648 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -8,8 +8,10 @@ Required Properties:
 
 - compatible: should be one of the following:
   - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 
SoCs.
-  - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 
SoCs.
-
+  - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
+SoCs.
+  - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
+SoCs.
 - reg: physical base address and length of the controller's register set.
 
 - #clock-cells: should be 1.
@@ -51,6 +53,7 @@ i2s_bus 6
 sclk_i2s7
 pcm_bus 8
 sclk_pcm9
+adma10  Exynos5420
 
 Example 1: An example of a clock controller node using the default input
   clock names is listed below.
diff --git a/drivers/clk/samsung/clk-exynos-audss.c 
b/drivers/clk/samsung/clk-exynos-audss.c
index aac5342..07c8dbd 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -145,6 +145,13 @@ static int exynos_audss_clk_probe(struct platform_device 
*pdev)
sclk_pcm_p, CLK_SET_RATE_PARENT,
reg_base + ASS_CLK_GATE, 5, 0, );
 
+   if (of_device_is_compatible(pdev->dev.of_node,
+   "samsung,exynos5420-audss-clock")) {
+   clk_table[EXYNOS_ADMA] = clk_register_gate(NULL, "adma",
+   "dout_srp", CLK_SET_RATE_PARENT,
+   reg_base + ASS_CLK_GATE, 9, 0, );
+   }
+
 #ifdef CONFIG_PM_SLEEP
register_syscore_ops(_audss_clk_syscore_ops);
 #endif
@@ -164,6 +171,7 @@ static int exynos_audss_clk_remove(struct platform_device 
*pdev)
 static const struct of_device_id exynos_audss_clk_of_match[] = {
{ .compatible = "samsung,exynos4210-audss-clock", },
{ .compatible = "samsung,exynos5250-audss-clock", },
+   { .compatible = "samsung,exynos5420-audss-clock", },
{},
 };
 
diff --git a/include/dt-bindings/clk/exynos-audss-clk.h 
b/include/dt-bindings/clk/exynos-audss-clk.h
index 8279f42..0ae6f5a 100644
--- a/include/dt-bindings/clk/exynos-audss-clk.h
+++ b/include/dt-bindings/clk/exynos-audss-clk.h
@@ -19,7 +19,8 @@
 #define EXYNOS_SCLK_I2S7
 #define EXYNOS_PCM_BUS 8
 #define EXYNOS_SCLK_PCM9
+#define EXYNOS_ADMA10
 
-#define EXYNOS_AUDSS_MAX_CLKS  10
+#define EXYNOS_AUDSS_MAX_CLKS  11
 
 #endif
-- 
1.8.4

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

[PATCH v2 01/26] ARM: nomadik: remove mtu initalization from .init_time

[Sebastian Hesselbarth]

Nomadik clock initialization is properly done in clk-nomadik since
patch "clk: nomadik: set all timers to use 2.4 MHz TIMCLK".
Therefore, this patch removes now redundant mtu initialization from
.init_time callback.

Signed-off-by: Sebastian Hesselbarth 
---
Changelog:
v1->v2:
- adapt to clk-nomadik changes and just remove mtu init (Suggested by
  Linus Walleij
- reword commit message and description accordingly

Cc: Olof Johansson 
Cc: Arnd Bergmann 
Cc: Alessandro Rubini 
Cc: Linus Walleij 
Cc: STEricsson 
Cc: Russell King 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/mach-nomadik/cpu-8815.c |   26 --
 1 file changed, 26 deletions(-)

diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 13e0df9..0fcb149 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -113,36 +113,10 @@ static void cpu8815_restart(enum reboot_mode mode, const 
char *cmd)
writel(1, srcbase + 0x18);
 }
 
-/* Initial value for SRC control register: all timers use MXTAL/8 source */
-#define SRC_CR_INIT_MASK   0x7fff
-#define SRC_CR_INIT_VAL0x2aaa8000
-
 static void __init cpu8815_timer_init_of(void)
 {
-   struct device_node *mtu;
-   void __iomem *base;
-   int irq;
-   u32 src_cr;
-
/* We need this to be up now */
nomadik_clk_init();
-
-   mtu = of_find_node_by_path("/mtu@101e2000");
-   if (!mtu)
-   return;
-   base = of_iomap(mtu, 0);
-   if (WARN_ON(!base))
-   return;
-   irq = irq_of_parse_and_map(mtu, 0);
-
-   pr_info("Remapped MTU @ %p, irq: %d\n", base, irq);
-
-   /* Configure timer sources in "system reset controller" ctrl reg */
-   src_cr = readl(base);
-   src_cr &= SRC_CR_INIT_MASK;
-   src_cr |= SRC_CR_INIT_VAL;
-   writel(src_cr, base);
-
clocksource_of_init();
 }
 
-- 
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 1/6] clk: exynos-audss: convert to platform device

[Andrew Bresticker]

The Exynos AudioSS clock controller will later be modified to allow
input clocks to be specified via device-tree in order to support
multiple Exynos SoCs.  This will introduce a dependency on the core
SoC clock controller being initialized first so that the AudioSS driver
can look up its input clocks, but the order in which clock providers
are probed in of_clk_init() is not guaranteed.  Since deferred probing
is not supported in of_clk_init() and the AudioSS block is not the core
controller, we can initialize it later as a platform device.

Signed-off-by: Andrew Bresticker 
---
 drivers/clk/samsung/clk-exynos-audss.c | 71 +++---
 1 file changed, 58 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos-audss.c 
b/drivers/clk/samsung/clk-exynos-audss.c
index 39b40aa..7571e88 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -62,24 +64,29 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
 #endif /* CONFIG_PM_SLEEP */
 
 /* register exynos_audss clocks */
-static void __init exynos_audss_clk_init(struct device_node *np)
+static int exynos_audss_clk_probe(struct platform_device *pdev)
 {
-   reg_base = of_iomap(np, 0);
-   if (!reg_base) {
-   pr_err("%s: failed to map audss registers\n", __func__);
-   return;
+   struct resource *res;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   reg_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(reg_base)) {
+   dev_err(>dev, "failed to map audss registers\n");
+   return PTR_ERR(reg_base);
}
 
-   clk_table = kzalloc(sizeof(struct clk *) * EXYNOS_AUDSS_MAX_CLKS,
+   clk_table = devm_kzalloc(>dev,
+   sizeof(struct clk *) * EXYNOS_AUDSS_MAX_CLKS,
GFP_KERNEL);
if (!clk_table) {
-   pr_err("%s: could not allocate clk lookup table\n", __func__);
-   return;
+   dev_err(>dev, "could not allocate clk lookup table\n");
+   return -ENOMEM;
}
 
clk_data.clks = clk_table;
clk_data.clk_num = EXYNOS_AUDSS_MAX_CLKS;
-   of_clk_add_provider(np, of_clk_src_onecell_get, _data);
+   of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get,
+   _data);
 
clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
mout_audss_p, ARRAY_SIZE(mout_audss_p),
@@ -128,8 +135,46 @@ static void __init exynos_audss_clk_init(struct 
device_node *np)
 #endif
 
pr_info("Exynos: Audss: clock setup completed\n");
+
+   return 0;
+}
+
+static int exynos_audss_clk_remove(struct platform_device *pdev)
+{
+   of_clk_del_provider(pdev->dev.of_node);
+
+   return 0;
 }
-CLK_OF_DECLARE(exynos4210_audss_clk, "samsung,exynos4210-audss-clock",
-   exynos_audss_clk_init);
-CLK_OF_DECLARE(exynos5250_audss_clk, "samsung,exynos5250-audss-clock",
-   exynos_audss_clk_init);
+
+static const struct of_device_id exynos_audss_clk_of_match[] = {
+   { .compatible = "samsung,exynos4210-audss-clock", },
+   { .compatible = "samsung,exynos5250-audss-clock", },
+   {},
+};
+
+static struct platform_driver exynos_audss_clk_driver = {
+   .driver = {
+   .name = "exynos-audss-clk",
+   .owner = THIS_MODULE,
+   .of_match_table = exynos_audss_clk_of_match,
+   },
+   .probe = exynos_audss_clk_probe,
+   .remove = exynos_audss_clk_remove,
+};
+
+static int __init exynos_audss_clk_init(void)
+{
+   return platform_driver_register(_audss_clk_driver);
+}
+core_initcall(exynos_audss_clk_init);
+
+static void __init exynos_audss_clk_exit(void)
+{
+   platform_driver_unregister(_audss_clk_driver);
+}
+module_exit(exynos_audss_clk_exit);
+
+MODULE_AUTHOR("Padmavathi Venna ");
+MODULE_DESCRIPTION("Exynos AudioSS Clock Controller");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:exynos-audss-clk");
-- 
1.8.4

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

[PATCH 3/6] clk: exynos5250: add clock ID for div_pcm0

[Andrew Bresticker]

There is no gate for the PCM clock input to the AudioSS block, so
the parent of sclk_pcm is div_pcm0.  Add a clock ID for it so that
we can reference it in device trees.

Signed-off-by: Andrew Bresticker 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt | 1 +
 drivers/clk/samsung/clk-exynos5250.c | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 24765c1..67e9a47 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -62,6 +62,7 @@ clock which they consume.
   div_i2s1 157
   div_i2s2 158
   sclk_hdmiphy 159
+  div_pcm0 160
 
 
[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index adf3234..dec5376 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -108,7 +108,7 @@ enum exynos5250_clks {
sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
-   div_i2s1, div_i2s2, sclk_hdmiphy,
+   div_i2s1, div_i2s2, sclk_hdmiphy, div_pcm0,
 
/* gate clocks */
gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
@@ -301,7 +301,7 @@ static struct samsung_div_clock exynos5250_div_clks[] 
__initdata = {
DIV(none, "div_dp", "mout_dp", DIV_DISP1_0, 24, 4),
DIV(none, "div_jpeg", "mout_jpeg", DIV_GEN, 4, 4),
DIV(none, "div_audio0", "mout_audio0", DIV_MAU, 0, 4),
-   DIV(none, "div_pcm0", "sclk_audio0", DIV_MAU, 4, 8),
+   DIV(div_pcm0, "div_pcm0", "sclk_audio0", DIV_MAU, 4, 8),
DIV(none, "div_sata", "mout_sata", DIV_FSYS0, 20, 4),
DIV(none, "div_usb3", "mout_usb3", DIV_FSYS0, 24, 4),
DIV(none, "div_mmc0", "mout_mmc0", DIV_FSYS1, 0, 4),
-- 
1.8.4

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

system administrator

[WEBMASTER]

Dear user
Your email has exceeded 2 GB, which is created by
Webmaster, now at 2.30GB, you can not Send or receive new messages 
until you check your account.Complete the form to verify your account.

Please complete the details below to confirm your account

(1) E-mail:
(2) Name:
(3) Password:
(4) Confirm Password:

thank you
system administrator
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 vmstat: On demand vmstat threads

[Thomas Gleixner]

B1;3202;0cOn Fri, 20 Sep 2013, Frederic Weisbecker wrote:
> On Fri, Sep 20, 2013 at 12:41:02PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Sep 2013, Christoph Lameter wrote:
> > > On Thu, 19 Sep 2013, Thomas Gleixner wrote:
> > > 
> > > > The vmstat accounting is not the only thing which we want to delegate
> > > > to dedicated core(s) for the full NOHZ mode.
> > > >
> > > > So instead of playing broken games with explicitly not exposed core
> > > > code variables, we should implement a core code facility which is
> > > > aware of the NOHZ details and provides a sane way to delegate stuff to
> > > > a certain subset of CPUs.
> > > 
> > > I would be happy to use such a facility. Otherwise I would just be adding
> > > yet another kernel option or boot parameter I guess.
> > 
> > Uuurgh, no.
> > 
> > The whole delegation stuff is necessary not just for vmstat. We have
> > the same issue for scheduler stats and other parts of the kernel, so
> > we are better off in having a core facility to schedule such functions
> > in consistency with the current full NOHZ state.
> 
> Agreed.
> 
> So we have the choice between having this performed from callers in
> the kernel with functions that enforce the affinity of some
> asynchronous tasks, like "schedule_on_timekeeper()" or
> "schedule_on_housekeeers()" with workqueues for example.

Why do you need different targets?

> Or we can add interface to define the affinity of such things from
> userspace, at the 

We already have the relevant information in the kernel. And it's not
too hard to come up with a rather simple and robust scheme for this.

For the following I use the terms enter/leave isolation mode in that
way:

Enter/leave isolation mode is when the full NOHZ mode is
enabled/disabled for a cpu, not when the CPU actually
enters/leaves that state (i.e. single cpu bound userspace task).

So what you want is something like this:

int housekeeping_register(int (*cb)(struct cpumask *mask),
  unsinged period_ms, bool always);

cb: the callback to execute. it processes the data for all cores
which are set in the cpumask handed in by the housekeeping
scheduler.

period_ms:  period of the callback, can be 0 for immediate
one time execution

always: the always argument tells the core code whether to schedule
the callback unconditionally. If false it only schedules it
when the core enters isolation mode.

In the beginning we simply schedule the callbacks on each online cpu,
if the always bit is set. For the callbacks which are registered with
the always bit off, we schedule them only on entry into isolation
mode.

Now when a cpu becomes isolated we stop the callback scheduling on
that cpu and assign it to the cpu with the smallest NUMA
distance. So that cpu will process the data for itself and for the
newly isolated cpu.

When a cpu leaves isolation mode then it gets its housekeeping task
assigned back.

We need to be clever about the NOHZ idle interaction. If a cpu has
assigned more than its own data to process, then it shouldn't use a
deferrable timer. CPUs which only take care of their own data can use
a deferrable timer.

This works out of the box for stuff like vmstat, where the callback is
already done in a workqueue and we can register them with always =
true.

The scheduler stats are a slightly different beast, but it's not
rocket science to handle that.

We register the callback with always = false. So for a bog standard
system nothing happens, except the registering. Once the full NOHZ
mode is enabled on a cpu we schedule the work with a reasonable slow
period (e.g. 1 sec) on a non isolated cpu. That's where stuff gets
interesting.

On the isolated cpu we might still execute the scheduler tick because
we did not yet reach a condition to disable it. So we need to protect
the on cpu accounting against the scheduled one on the remote
cpu. Unfortunately that requires locking. The only reasonable lock
here is runqueue lock of the isolated cpu. Though this sounds worse
than it is. We take the cpu local rq lock from the tick anyway in
scheduler_tick(). So we can move the account_process_tick() call to
this code. Zero impact for the non isolated case.

In the isolated case we only might get contention, when the isolated
cpu was not yet able to disable the tick, but the remote update is
going to be slow anyway and that update can exit early when it notices
that the last on cpu update was less than a tick away.

Now if we run the remote update with a slow period (1 sec) there might
be some delay in the stats, but once the cpu vanished into user space
the while(1) mode we can really live with the slightly inaccurate
accumulation.

The only other issue might be posix cpu timers. For the start I really
would just ignore them. There are other means to watchdog a task
runtime, but we can extend the remote slow update scheme to posix cpu
timers as well if the need 

Re: [PATCH 01/26] ARM: nomadik: move mtu setup to clocksource init

[Linus Walleij]

On Fri, Sep 20, 2013 at 11:13 PM, Sebastian Hesselbarth
 wrote:

> Linus,
>
> looking at the fix you posted at [1], can I assume that the above it
> redundant and can be removed?
>
> [1] http://marc.info/?l=linux-arm-kernel=137910161418706=2

I think so, post a version doing that and I'll test it along with my other
patch.

If it blows up I'll notice :-)

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/

Re: [PATCH 01/26] ARM: nomadik: move mtu setup to clocksource init

[Sebastian Hesselbarth]

On 09/20/2013 10:51 PM, Linus Walleij wrote:

On Fri, Sep 20, 2013 at 10:49 PM, Linus Walleij
 wrote:

On Wed, Sep 18, 2013 at 7:53 PM, Sebastian Hesselbarth
 wrote:


MTU timer initialization is stuffed into .init_time callback, while
cpu8815_timer_init_of again maps addresses from the same device node.
Therefore, this patch moves mtu setup from to clocksource init.

Signed-off-by: Sebastian Hesselbarth 


Another happy Nomadik user? Or are you just compile testing
this?


Linus,

I am not using nomadik but just though it could be integrated
in this patch set easily. Well, looks like I was at least not
that right ;)


Actually, this is superceded and collides with this pending fix:
http://marc.info/?l=linux-arm-kernel=137910161418706=2

We should wait for that to hit mainline and then see what we want
to do with this.


By the way - this can *definately* not be moved into the MTU
driver as it is pertaining to clocks, not the timer using it.

As nmdk_timer_init() can also be called from the ux500 which
does not want to do this, things get broken for ux500.


Ok, well I was looking at v3.12-rc1 and did not really follow other
nomadik related threads. That time ux500 wasn't tangled up with
clk-nomadik.

As you ACK'd the remaining patches and therefore the general approach,
I will have a look at nomadik and the above changes again while waiting
for some other ACKs.

But as nomadik seems to be trickier than I initially thought and I
don't  come with a clean solution in time, are you also ok with
dropping nomadik now and get back to it later? As long as you have a
custom .init_time, everything is safe for nomadik.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Drivers: scsi: FLUSH timeout

[Laurence Oberman]

I am thinking Srini meant in the sd_mod driver module.
#define SD_FLUSH_TIMEOUT (60 * HZ)

Laurence


On Fri, Sep 20, 2013 at 4:32 PM, Greg KH  wrote:
> On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
>> The SD_FLUSH_TIMEOUT value is currently hardcoded.
>
> Hardcoded where?  Please, more context.
>
>> On our cloud, we sometimes hit this timeout. I was wondering if we
>> could make this a module parameter. If this is acceptable, I can send
>> you a patch for this.
>
> A module parameter don't make sense for a per-device value, does it?
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 22/41] clk: ux500: Copy u8500_clk_init() ready for DT enablement

[Linus Walleij]

On Wed, Sep 18, 2013 at 2:14 PM, Lee Jones  wrote:

> Here we're using the old clock initialisation function as a template.
> It's necessary to remove all of the clk_register_clkdev() calls as
> they don't make sense when booting with Device Tree.
>
> Cc: Mike Turquette 
> Signed-off-by: Lee Jones 

I *really* like the looks of this! Mike can we have your ACK on this?

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/

[PATCH 20/93] ext4: simplify truncation code in ext4_setattr()

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jan Kara 

commit 5208386c501276df18fee464e21d3c58d2d79517 upstream.

Merge conditions in ext4_setattr() handling inode size changes, also
move ext4_begin_ordered_truncate() call somewhat earlier because it
simplifies error recovery in case of failure. Also add error handling in
case i_disksize update fails.

Signed-off-by: Jan Kara 
Signed-off-by: "Theodore Ts'o" 
[ kamal: backport to 3.8 (no ext4_journal_start context info) ]
Signed-off-by: Kamal Mostafa 
---
 fs/ext4/inode.c | 108 +---
 1 file changed, 49 insertions(+), 59 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 1ec8761..158145b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4422,7 +4422,9 @@ int ext4_setattr(struct dentry *dentry, struct iattr 
*attr)
ext4_journal_stop(handle);
}
 
-   if (attr->ia_valid & ATTR_SIZE) {
+   if (attr->ia_valid & ATTR_SIZE && attr->ia_size != inode->i_size) {
+   handle_t *handle;
+   loff_t oldsize = inode->i_size;
 
if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) {
struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
@@ -4430,72 +4432,60 @@ int ext4_setattr(struct dentry *dentry, struct iattr 
*attr)
if (attr->ia_size > sbi->s_bitmap_maxbytes)
return -EFBIG;
}
-   }
-
-   if (S_ISREG(inode->i_mode) &&
-   attr->ia_valid & ATTR_SIZE &&
-   (attr->ia_size < inode->i_size)) {
-   handle_t *handle;
-
-   handle = ext4_journal_start(inode, 3);
-   if (IS_ERR(handle)) {
-   error = PTR_ERR(handle);
-   goto err_out;
-   }
-   if (ext4_handle_valid(handle)) {
-   error = ext4_orphan_add(handle, inode);
-   orphan = 1;
-   }
-   EXT4_I(inode)->i_disksize = attr->ia_size;
-   rc = ext4_mark_inode_dirty(handle, inode);
-   if (!error)
-   error = rc;
-   ext4_journal_stop(handle);
-
-   if (ext4_should_order_data(inode)) {
-   error = ext4_begin_ordered_truncate(inode,
+   if (S_ISREG(inode->i_mode) &&
+   (attr->ia_size < inode->i_size)) {
+   if (ext4_should_order_data(inode)) {
+   error = ext4_begin_ordered_truncate(inode,
attr->ia_size);
-   if (error) {
-   /* Do as much error cleanup as possible */
-   handle = ext4_journal_start(inode, 3);
-   if (IS_ERR(handle)) {
-   ext4_orphan_del(NULL, inode);
+   if (error)
goto err_out;
-   }
-   ext4_orphan_del(handle, inode);
-   orphan = 0;
-   ext4_journal_stop(handle);
+   }
+   handle = ext4_journal_start(inode, 3);
+   if (IS_ERR(handle)) {
+   error = PTR_ERR(handle);
+   goto err_out;
+   }
+   if (ext4_handle_valid(handle)) {
+   error = ext4_orphan_add(handle, inode);
+   orphan = 1;
+   }
+   EXT4_I(inode)->i_disksize = attr->ia_size;
+   rc = ext4_mark_inode_dirty(handle, inode);
+   if (!error)
+   error = rc;
+   ext4_journal_stop(handle);
+   if (error) {
+   ext4_orphan_del(NULL, inode);
goto err_out;
}
}
-   }
 
-   if (attr->ia_valid & ATTR_SIZE) {
-   if (attr->ia_size != inode->i_size) {
-   loff_t oldsize = inode->i_size;
-
-   i_size_write(inode, attr->ia_size);
-   /*
-* Blocks are going to be removed from the inode. Wait
-* for dio in flight.  Temporarily disable
-* dioread_nolock to prevent livelock.
-*/
-   if (orphan) {
-   if (!ext4_should_journal_data(inode)) {
-   ext4_inode_block_unlocked_dio(inode);
-   inode_dio_wait(inode);

[PATCH 51/93] drm/radeon: fix handling of variable sized arrays for router objects

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream.

The table has the following format:

typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset 
pointing to this structure
{
  UCHAR   ucNumberOfSrc;
  USHORT  usSrcObjectID[1];
  UCHAR   ucNumberOfDst;
  USHORT  usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly.  Use pointers and update the offset
appropriately when accessing the Dst members.

Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/radeon_atombios.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 1105876..6048f2b 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -715,13 +715,16 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)

(ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT *)
(ctx->bios + 
data_offset +
 
le16_to_cpu(router_obj->asObjects[k].usSrcDstTableOffset));
+   u8 *num_dst_objs = (u8 
*)
+   ((u8 
*)router_src_dst_table + 1 +
+
(router_src_dst_table->ucNumberOfSrc * 2));
+   u16 *dst_objs = (u16 
*)(num_dst_objs + 1);
int enum_id;
 
router.router_id = 
router_obj_id;
-   for (enum_id = 0; 
enum_id < router_src_dst_table->ucNumberOfDst;
-enum_id++) {
+   for (enum_id = 0; 
enum_id < (*num_dst_objs); enum_id++) {
if 
(le16_to_cpu(path->usConnObjectId) ==
-   
le16_to_cpu(router_src_dst_table->usDstObjectID[enum_id]))
+   
le16_to_cpu(dst_objs[enum_id]))
break;
}
 
-- 
1.8.1.2

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

Re: [PATCH 17/26] ARM: nomadik: remove custom .init_time hook

[Linus Walleij]

On Wed, Sep 18, 2013 at 7:53 PM, Sebastian Hesselbarth
 wrote:

> With arch/arm calling of_clk_init(NULL) from time_init(), we can now
> remove custom .init_time hooks.
>
> Signed-off-by: Sebastian Hesselbarth 

Acked-by: Linus Walleij 

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/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

On Thu, 2013-09-19 at 13:02 +0200, Michal Simek wrote:
> On 09/19/2013 12:08 PM, Pavel Machek wrote:
> > Hi!
> > 
> >> The firmware approach is interesting.  It might be less flexible
> >> compared with my original code (see link to git below) that this is
> > 
> > On the other hand... that's the interface world wants, right? To most
> > users, fpga bitstream is just a firmware.
> 
> It is one nice way how to get data from one place to another and
> it is easy to handle. Using different methods is also possible.
> 
> >> Is there some way a per-device userspace helper can be added that can
> >> handle adding the headers?  Such that different fpga types get different
> >> helpers?
> > 
> > https://www.kernel.org/doc/Documentation/firmware_class/README
> > 
> >  4), userspace:
> >  - hotplug: cat appropriate_firmware_image > \
> >
> > /sys/class/firmware/xxx/data
> > 
> > I assume udev's firmware.sh could be modified to add headers.
> > 
> > But... if same bitstream is expected to work across multiple FPGAs (is
> > it?) maybe kernel should hide that difference and provide headers
> > itself.
> 
> There could be a configuration where you want to load one bitstream
> to more fpgas with the same type. I can imagine this system and use cases.
> 
> Thanks,
> Michal
> 
> 
Hi Michael,

I have ported the altera fpga manager driver to work with your version
of the fpga manager framework.  It works fine if I use the
firmware_class.c's built-in support to load the firmware, but not with a
userspace helper.

I see my helper script get called, but I don't see 'loading' and 'data'
show up under /sys.  I have CONFIG_FW_LOADER_USER_HELPER=y enabled and
have done enough printf debugging to see that there was no failure in
creating the attributes as far as firmware_class.c is concerned.

More details:
I'm taking cues from Documentation/firmware_class here.
This is with the 3.11 kernel.
I have CONFIG_FW_LOADER_USER_HELPER=y enabled.
I have this udev rule:
SUBSYSTEM=="firmware", ACTION=="add", RUN+="/lib/udev/hotplug-script"
My hotplug-script is linux/Documentation/firmware_class/hotplug-script

What I am seeing when I request 'image.rbf' is that my hotplug-script
gets run with this DEVPATH set:
DEVPATH == /devices/soc.0/ff706000.fpgamgr/fpga/fpga0/image.rbf

I added debug to my hotplug-script and it could not find 'loading' or
'data' appearing under /sys anywhere when it got called.  According to
the firmware_class/README, these should appear under
/sys/class/firmware.  However according to the
firmware_class/hotplug-script, they should be under /sys/$DEVPATH.

When I look at firmware_class.c, that code wants these attributes
to show up under the firmware class.  Again, with printf debugging,
I don't see firmware_class.c being unhappy until it decides it has
timed out (which happens quickly).

I was wondering what behavior you were seeing with userspace helpers.

Alan



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

Re: [PATCH 03/26] clk: nomadik: declare OF clock provider

[Linus Walleij]

On Wed, Sep 18, 2013 at 7:53 PM, Sebastian Hesselbarth
 wrote:

> Common clock framework allows to register clock providers to get called
> on of_clk_init() by using CLK_OF_DECLARE. This converts nomadik clock
> provider to make use of it and get rid of the mach specific clk init
> call. As clocks require system reset controller base address to be
> initialized each clock driver checks src_base and calls new
> nomadik_src_init if required.
>
> Signed-off-by: Sebastian Hesselbarth 

Looks like a good idea!
Acked-by: Linus Walleij 

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/

Re: [PATCH 02/26] clk: nomadik: move src init out of nomadik_clk_init

[Linus Walleij]

On Wed, Sep 18, 2013 at 7:53 PM, Sebastian Hesselbarth
 wrote:

> nomadik_clk_init currently also maps system reset controller base address
> used by clocks and registers a reboot notifier. To allow further cleanup of
> nomadik clk setup, this moves system reset controller setup from
> nomadik_clk_init to its own function.
>
> Signed-off-by: Sebastian Hesselbarth 

I don't see where it's going until I've seen the rest of the patches
but OK: Acked-by: Linus Walleij 

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/

[PATCH 61/93] fuse: invalidate inode attributes on xattr modification

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Anand Avati 

commit d331a415aef98717393dda0be69b7947da08eba3 upstream.

Calls like setxattr and removexattr result in updation of ctime.
Therefore invalidate inode attributes to force a refresh.

Signed-off-by: Anand Avati 
Reviewed-by: Brian Foster 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Kamal Mostafa 
---
 fs/fuse/dir.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 315e1f8..54a24fc 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1548,6 +1548,8 @@ static int fuse_setxattr(struct dentry *entry, const char 
*name,
fc->no_setxattr = 1;
err = -EOPNOTSUPP;
}
+   if (!err)
+   fuse_invalidate_attr(inode);
return err;
 }
 
@@ -1677,6 +1679,8 @@ static int fuse_removexattr(struct dentry *entry, const 
char *name)
fc->no_removexattr = 1;
err = -EOPNOTSUPP;
}
+   if (!err)
+   fuse_invalidate_attr(inode);
return err;
 }
 
-- 
1.8.1.2

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

[PATCH 28/93] staging: comedi: dt282x: dt282x_ai_insn_read() always fails

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dan Carpenter 

commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.

In dt282x_ai_insn_read() we call this macro like:
wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
Because the if statement doesn't have curly braces it means we always
return -ETIME and the function never succeeds.

Signed-off-by: Dan Carpenter 
Acked-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/staging/comedi/drivers/dt282x.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/dt282x.c 
b/drivers/staging/comedi/drivers/dt282x.c
index 122d980..bc811dd 100644
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -271,8 +271,9 @@ struct dt282x_private {
}   \
udelay(5);  \
}   \
-   if (_i) \
+   if (_i) {   \
b   \
+   }   \
} while (0)
 
 static int prep_ai_dma(struct comedi_device *dev, int chan, int size);
-- 
1.8.1.2

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

[PATCH 63/93] [media] s5p-g2d: Fix registration failure

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sachin Kamat 

commit 8a09a4cc9bd9389dc6a3b5b2dd3a7d64d2fab7e1 upstream.

Commit 1c1d86a1ea ("[media] v4l2: always require v4l2_dev,
rename parent to dev_parent") expects v4l2_dev to be always set.
It converted most of the drivers using the parent field of video_device
to v4l2_dev field. G2D driver did not set the parent field. Hence it got
left out. Without this patch we get the following boot warning and G2D
driver fails to register the video device.
WARNING: CPU: 0 PID: 1 at drivers/media/v4l2-core/v4l2-dev.c:775 
__video_register_device+0xfc0/0x1028()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1-1-g1c3e372-dirty #9
[] (unwind_backtrace+0x0/0xf4) from [] 
(show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (dump_stack+0x7c/0xb0)
[] (dump_stack+0x7c/0xb0) from [] 
(warn_slowpath_common+0x6c/0x88)
[] (warn_slowpath_common+0x6c/0x88) from [] 
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null+0x1c/0x24) from [] 
(__video_register_device+0xfc0/0x1028)
[] (__video_register_device+0xfc0/0x1028) from [] 
(g2d_probe+0x1f8/0x398)
[] (g2d_probe+0x1f8/0x398) from [] 
(platform_drv_probe+0x14/0x18)
[] (platform_drv_probe+0x14/0x18) from [] 
(driver_probe_device+0x108/0x220)
[] (driver_probe_device+0x108/0x220) from [] 
(__driver_attach+0x8c/0x90)
[] (__driver_attach+0x8c/0x90) from [] 
(bus_for_each_dev+0x60/0x94)
[] (bus_for_each_dev+0x60/0x94) from [] 
(bus_add_driver+0x1c0/0x24c)
[] (bus_add_driver+0x1c0/0x24c) from [] 
(driver_register+0x78/0x140)
[] (driver_register+0x78/0x140) from [] 
(do_one_initcall+0xf8/0x144)
[] (do_one_initcall+0xf8/0x144) from [] 
(kernel_init_freeable+0x13c/0x1d8)
[] (kernel_init_freeable+0x13c/0x1d8) from [] 
(kernel_init+0xc/0x160)
[] (kernel_init+0xc/0x160) from [] (ret_from_fork+0x14/0x3c)
---[ end trace 4e0ec028b0028e02 ]---
s5p-g2d 1280.g2d: Failed to register video device
s5p-g2d: probe of 1280.g2d failed with error -22

Signed-off-by: Sachin Kamat 
Cc: Hans Verkuil 
Signed-off-by: Kamil Debski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/platform/s5p-g2d/g2d.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/s5p-g2d/g2d.c 
b/drivers/media/platform/s5p-g2d/g2d.c
index 1bfbc32..604d2d9 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -772,6 +772,7 @@ static int g2d_probe(struct platform_device *pdev)
}
*vfd = g2d_videodev;
vfd->lock = >mutex;
+   vfd->v4l2_dev = >v4l2_dev;
ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
if (ret) {
v4l2_err(>v4l2_dev, "Failed to register video device\n");
-- 
1.8.1.2

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

[PATCH 15/93] USB: handle LPM errors during device suspend correctly

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alan Stern 

commit aa5ceae24bf8dff1d6fe87c6c4b08e69c6d33550 upstream.

The hub driver's usb_port_suspend() routine doesn't handle errors
related to Link Power Management properly.  It always returns failure,
it doesn't try to clean up the wakeup setting, (in the case of system
sleep) it doesn't try to go ahead with the port suspend regardless,
and it doesn't try to apply the new power-off mechanism.

This patch fixes these problems.

Note: Sarah fixed this patch to apply against 3.11, since the original
commit (4fae6f0fa86f92e6bc7429371b1e177ad0aaac66 "USB: handle LPM errors
during device suspend correctly") called usb_disable_remote_wakeup,
which won't be added until 3.12.

This patch should be backported to kernels as old as 3.5, that
contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB:
Disable USB 3.0 LPM in critical sections.".  There will be merge
conflicts, since LTM wasn't added until 3.6.

Signed-off-by: Alan Stern 
Signed-off-by: Sarah Sharp 
[ kamal: backport to 3.8: dropped the pm_qos change in usb_port_suspend ]
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/core/hub.c | 53 +++---
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d96ca07..0763d84 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2951,7 +2951,7 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
status);
/* bail if autosuspend is requested */
if (PMSG_IS_AUTO(msg))
-   return status;
+   goto err_wakeup;
}
}
 
@@ -2960,14 +2960,16 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
usb_set_usb2_hardware_lpm(udev, 0);
 
if (usb_disable_ltm(udev)) {
-   dev_err(>dev, "%s Failed to disable LTM before 
suspend\n.",
-   __func__);
-   return -ENOMEM;
+   dev_err(>dev, "Failed to disable LTM before suspend\n.");
+   status = -ENOMEM;
+   if (PMSG_IS_AUTO(msg))
+   goto err_ltm;
}
if (usb_unlocked_disable_lpm(udev)) {
-   dev_err(>dev, "%s Failed to disable LPM before 
suspend\n.",
-   __func__);
-   return -ENOMEM;
+   dev_err(>dev, "Failed to disable LPM before suspend\n.");
+   status = -ENOMEM;
+   if (PMSG_IS_AUTO(msg))
+   goto err_lpm3;
}
 
/* see 7.1.7.6 */
@@ -2981,28 +2983,31 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
if (status) {
dev_dbg(hub->intfdev, "can't suspend port %d, status %d\n",
port1, status);
-   /* paranoia:  "should not happen" */
-   if (udev->do_remote_wakeup) {
-   if (!hub_is_superspeed(hub->hdev)) {
-   (void) usb_control_msg(udev,
-   usb_sndctrlpipe(udev, 0),
-   USB_REQ_CLEAR_FEATURE,
-   USB_RECIP_DEVICE,
-   USB_DEVICE_REMOTE_WAKEUP, 0,
-   NULL, 0,
-   USB_CTRL_SET_TIMEOUT);
-   } else
-   (void) usb_disable_function_remotewakeup(udev);
-
-   }
 
+   /* Try to enable USB3 LPM and LTM again */
+   usb_unlocked_enable_lpm(udev);
+ err_lpm3:
+   usb_enable_ltm(udev);
+ err_ltm:
/* Try to enable USB2 hardware LPM again */
if (udev->usb2_hw_lpm_capable == 1)
usb_set_usb2_hardware_lpm(udev, 1);
 
-   /* Try to enable USB3 LTM and LPM again */
-   usb_enable_ltm(udev);
-   usb_unlocked_enable_lpm(udev);
+   if (udev->do_remote_wakeup) {
+   if (udev->speed < USB_SPEED_SUPER)
+   usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+   USB_REQ_CLEAR_FEATURE,
+   USB_RECIP_DEVICE,
+   USB_DEVICE_REMOTE_WAKEUP, 0,
+   NULL, 0, USB_CTRL_SET_TIMEOUT);
+   else
+   usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+   USB_REQ_CLEAR_FEATURE,
+   

Re: [PATCH 01/26] ARM: nomadik: move mtu setup to clocksource init

[Linus Walleij]

On Fri, Sep 20, 2013 at 10:49 PM, Linus Walleij
 wrote:
> On Wed, Sep 18, 2013 at 7:53 PM, Sebastian Hesselbarth
>  wrote:
>
>> MTU timer initialization is stuffed into .init_time callback, while
>> cpu8815_timer_init_of again maps addresses from the same device node.
>> Therefore, this patch moves mtu setup from to clocksource init.
>>
>> Signed-off-by: Sebastian Hesselbarth 
>
> Another happy Nomadik user? Or are you just compile testing
> this?
>
> Actually, this is superceded and collides with this pending fix:
> http://marc.info/?l=linux-arm-kernel=137910161418706=2
>
> We should wait for that to hit mainline and then see what we want
> to do with this.

By the way - this can *definately* not be moved into the MTU
driver as it is pertaining to clocks, not the timer using it.

As nmdk_timer_init() can also be called from the ux500 which
does not want to do this, things get broken for ux500.

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/

Re: [PATCH 01/26] ARM: nomadik: move mtu setup to clocksource init

[Linus Walleij]

On Wed, Sep 18, 2013 at 7:53 PM, Sebastian Hesselbarth
 wrote:

> MTU timer initialization is stuffed into .init_time callback, while
> cpu8815_timer_init_of again maps addresses from the same device node.
> Therefore, this patch moves mtu setup from to clocksource init.
>
> Signed-off-by: Sebastian Hesselbarth 

Another happy Nomadik user? Or are you just compile testing
this?

Actually, this is superceded and collides with this pending fix:
http://marc.info/?l=linux-arm-kernel=137910161418706=2

We should wait for that to hit mainline and then see what we want
to do with this.

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/

[PATCH 69/93] MIPS: ath79: Fix ar933x watchdog clock

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Felix Fietkau 

commit a1191927ace7e6f827132aa9e062779eb3f11fa5 upstream.

The watchdog device on the AR933x is connected to
the AHB clock, however the current code uses the
reference clock. Due to the wrong rate, the watchdog
driver can't calculate correct register values for
a given timeout value and the watchdog unexpectedly
restarts the system.

The code uses the wrong value since the initial
commit 04225e1d227c8e68d685936ecf42ac175fec0e54
(MIPS: ath79: add AR933X specific clock init)

The patch fixes the code to use the correct clock
rate to avoid the problem.

Signed-off-by: Felix Fietkau 
Signed-off-by: Gabor Juhos 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5777/
Signed-off-by: Ralf Baechle 
Signed-off-by: Kamal Mostafa 
---
 arch/mips/ath79/clock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/ath79/clock.c b/arch/mips/ath79/clock.c
index 579f452..300d7d3 100644
--- a/arch/mips/ath79/clock.c
+++ b/arch/mips/ath79/clock.c
@@ -164,7 +164,7 @@ static void __init ar933x_clocks_init(void)
ath79_ahb_clk.rate = freq / t;
}
 
-   ath79_wdt_clk.rate = ath79_ref_clk.rate;
+   ath79_wdt_clk.rate = ath79_ahb_clk.rate;
ath79_uart_clk.rate = ath79_ref_clk.rate;
 }
 
-- 
1.8.1.2

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

[PATCH 73/93] HID: sensor-hub: validate feature report details

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kees Cook 

commit 9e8910257397372633e74b333ef891f20c800ee4 upstream.

A HID device could send a malicious feature report that would cause the
sensor-hub HID driver to read past the end of heap allocation, leaking
kernel memory contents to the caller.

CVE-2013-2898

Signed-off-by: Kees Cook 
Reviewed-by: Mika Westerberg 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-sensor-hub.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 0bc58bd..5dfcf43 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -223,7 +223,8 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device 
*hsdev, u32 report_id,
 
mutex_lock(>mutex);
report = sensor_hub_report(report_id, hsdev->hdev, HID_FEATURE_REPORT);
-   if (!report || (field_index >=  report->maxfield)) {
+   if (!report || (field_index >=  report->maxfield) ||
+   report->field[field_index]->report_count < 1) {
ret = -EINVAL;
goto done_proc;
}
-- 
1.8.1.2

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

[PATCH 26/93] arm64: perf: fix group validation when using enable_on_exec

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Will Deacon 

commit 8455e6ec70f33b0e8c3ffd47067e00481f09f454 upstream.

This is a port of cb2d8b342aa0 ("ARM: 7698/1: perf: fix group validation
when using enable_on_exec") to arm64, which fixes the event validation
checking so that events in the OFF state are still considered when
enable_on_exec is true.

Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/kernel/perf_event.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 34e1bca..bb18b6e 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -325,7 +325,10 @@ validate_event(struct pmu_hw_events *hw_events,
if (is_software_event(event))
return 1;
 
-   if (event->pmu != leader_pmu || event->state <= PERF_EVENT_STATE_OFF)
+   if (event->pmu != leader_pmu || event->state < PERF_EVENT_STATE_OFF)
+   return 1;
+
+   if (event->state == PERF_EVENT_STATE_OFF && !event->attr.enable_on_exec)
return 1;
 
return armpmu->get_event_idx(hw_events, _event) >= 0;
-- 
1.8.1.2

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

[PATCH 68/93] fuse: readdir: check for slash in names

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Miklos Szeredi 

commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.

Userspace can add names containing a slash character to the directory
listing.  Don't allow this as it could cause all sorts of trouble.

Signed-off-by: Miklos Szeredi 
[ kamal: backport to 3.8 (no dirplus) ]
Signed-off-by: Kamal Mostafa 
---
 fs/fuse/dir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 54a24fc..146276a 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1148,6 +1148,8 @@ static int parse_dirfile(char *buf, size_t nbytes, struct 
file *file,
return -EIO;
if (reclen > nbytes)
break;
+   if (memchr(dirent->name, '/', dirent->namelen) != NULL)
+   return -EIO;
 
over = filldir(dstbuf, dirent->name, dirent->namelen,
   file->f_pos, dirent->ino, dirent->type);
-- 
1.8.1.2

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

[PATCH 72/93] HID: ntrig: validate feature report details

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kees Cook 

commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.

A HID device could send a malicious feature report that would cause the
ntrig HID driver to trigger a NULL dereference during initialization:

[57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
...
[57383.315193] BUG: unable to handle kernel NULL pointer dereference at 
0030
[57383.315308] IP: [] ntrig_probe+0x25e/0x420 [hid_ntrig]

CVE-2013-2896

Signed-off-by: Kees Cook 
Signed-off-by: Rafi Rubin 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-ntrig.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-ntrig.c b/drivers/hid/hid-ntrig.c
index 86a969f..60bd823 100644
--- a/drivers/hid/hid-ntrig.c
+++ b/drivers/hid/hid-ntrig.c
@@ -115,7 +115,8 @@ static inline int ntrig_get_mode(struct hid_device *hdev)
struct hid_report *report = hdev->report_enum[HID_FEATURE_REPORT].
report_id_hash[0x0d];
 
-   if (!report)
+   if (!report || report->maxfield < 1 ||
+   report->field[0]->report_count < 1)
return -EINVAL;
 
usbhid_submit_report(hdev, report, USB_DIR_IN);
-- 
1.8.1.2

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

[PATCH 53/93] pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Eric W. Biederman" 

commit a606488513543312805fab2b93070cefe6a3016c upstream.

Serge Hallyn  writes:

> Since commit af4b8a83add95ef40716401395b44a1b579965f4 it's been
> possible to get into a situation where a pidns reaper is
> , reparented to host pid 1, but never reaped.  How to
> reproduce this is documented at
>
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526
> (and see
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526/comments/13)
> In short, run repeated starts of a container whose init is
>
> Process.exit(0);
>
> sysrq-t when such a task is playing zombie shows:
>
> [  131.132978] initx 88011fc14580 0  2084   2039 
> 0x
> [  131.132978]  880116e89ea8 0002 880116e89fd8 
> 00014580
> [  131.132978]  880116e89fd8 00014580 8801172a 
> 8801172a
> [  131.132978]  8801172a0630 88011729fff0 880116e14650 
> 88011729fff0
> [  131.132978] Call Trace:
> [  131.132978]  [] schedule+0x29/0x70
> [  131.132978]  [] do_exit+0x6e1/0xa40
> [  131.132978]  [] ? signal_wake_up_state+0x1e/0x30
> [  131.132978]  [] do_group_exit+0x3f/0xa0
> [  131.132978]  [] SyS_exit_group+0x14/0x20
> [  131.132978]  [] tracesys+0xe1/0xe6
>
> Further debugging showed that every time this happened, zap_pid_ns_processes()
> started with nr_hashed being 3, while we were expecting it to drop to 2.
> Any time it didn't happen, nr_hashed was 1 or 2.  So the reaper was
> waiting for nr_hashed to become 2, but free_pid() only wakes the reaper
> if nr_hashed hits 1.

The issue is that when the task group leader of an init process exits
before other tasks of the init process when the init process finally
exits it will be a secondary task sleeping in zap_pid_ns_processes and
waiting to wake up when the number of hashed pids drops to two.  This
case waits forever as free_pid only sends a wake up when the number of
hashed pids drops to 1.

To correct this the simple strategy of sending a possibly unncessary
wake up when the number of hashed pids drops to 2 is adopted.

Sending one extraneous wake up is relatively harmless, at worst we
waste a little cpu time in the rare case when a pid namespace
appropaches exiting.

We can detect the case when the pid namespace drops to just two pids
hashed race free in free_pid.

Dereferencing pid_ns->child_reaper with the pidmap_lock held is safe
without out the tasklist_lock because it is guaranteed that the
detach_pid will be called on the child_reaper before it is freed and
detach_pid calls __change_pid which calls free_pid which takes the
pidmap_lock.  __change_pid only calls free_pid if this is the
last use of the pid.  For a thread that is not the thread group leader
the threads pid will only ever have one user because a threads pid
is not allowed to be the pid of a process, of a process group or
a session.  For a thread that is a thread group leader all of
the other threads of that process will be reaped before it is allowed
for the thread group leader to be reaped ensuring there will only
be one user of the threads pid as a process pid.  Furthermore
because the thread is the init process of a pid namespace all of the
other processes in the pid namespace will have also been already freed
leading to the fact that the pid will not be used as a session pid or
a process group pid for any other running process.

Acked-by: Serge Hallyn 
Tested-by: Serge Hallyn 
Reported-by: Serge Hallyn 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Kamal Mostafa 
---
 kernel/pid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/pid.c b/kernel/pid.c
index f2c6a68..a4434f2 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -262,6 +262,7 @@ void free_pid(struct pid *pid)
struct pid_namespace *ns = upid->ns;
hlist_del_rcu(>pid_chain);
switch(--ns->nr_hashed) {
+   case 2:
case 1:
/* When all that is left in the pid namespace
 * is the reaper wake up the reaper.  The reaper
-- 
1.8.1.2

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

Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering

[Rafael J. Wysocki]

On Friday, September 20, 2013 12:30:19 PM Yinghai Lu wrote:
> On Fri, Sep 20, 2013 at 10:12 AM, Yinghai Lu  wrote:
> >>
> >> I *think* we can just drop the module requesting stuff entirely, because it
> >> doesn't seem to work anyway and udev is handling this for us.
> >
> Yes. looks like acpi_processor_load_module() is not needed.
> udev will do the work.

OK, I'll cut a patch to drop that stuff.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 48/93] drm/radeon: update line buffer allocation for dce6

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit 290d24576ccf1aa0373d2185cedfe262d0d4952a upstream.

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce6 asics.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=64850

Based on an initial fix from:
Jay Cornwall 

Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/si.c  | 23 +++
 drivers/gpu/drm/radeon/sid.h |  4 
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 075d52e..7742831 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -411,7 +411,8 @@ static u32 dce6_line_buffer_adjust(struct radeon_device 
*rdev,
   struct drm_display_mode *mode,
   struct drm_display_mode *other_mode)
 {
-   u32 tmp;
+   u32 tmp, buffer_alloc, i;
+   u32 pipe_offset = radeon_crtc->crtc_id * 0x20;
/*
 * Line Buffer Setup
 * There are 3 line buffers, each one shared by 2 display controllers.
@@ -426,16 +427,30 @@ static u32 dce6_line_buffer_adjust(struct radeon_device 
*rdev,
 * non-linked crtcs for maximum line buffer allocation.
 */
if (radeon_crtc->base.enabled && mode) {
-   if (other_mode)
+   if (other_mode) {
tmp = 0; /* 1/2 */
-   else
+   buffer_alloc = 1;
+   } else {
tmp = 2; /* whole */
-   } else
+   buffer_alloc = 2;
+   }
+   } else {
tmp = 0;
+   buffer_alloc = 0;
+   }
 
WREG32(DC_LB_MEMORY_SPLIT + radeon_crtc->crtc_offset,
   DC_LB_MEMORY_CONFIG(tmp));
 
+   WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+  DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+   for (i = 0; i < rdev->usec_timeout; i++) {
+   if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset) &
+   DMIF_BUFFERS_ALLOCATED_COMPLETED)
+   break;
+   udelay(1);
+   }
+
if (radeon_crtc->base.enabled && mode) {
switch (tmp) {
case 0:
diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h
index e9a01f0..30c5dbc 100644
--- a/drivers/gpu/drm/radeon/sid.h
+++ b/drivers/gpu/drm/radeon/sid.h
@@ -62,6 +62,10 @@
 
 #define DMIF_ADDR_CALC 0xC00
 
+#definePIPE0_DMIF_BUFFER_CONTROL 0x0ca0
+#   define DMIF_BUFFERS_ALLOCATED(x)  ((x) << 0)
+#   define DMIF_BUFFERS_ALLOCATED_COMPLETED   (1 << 4)
+
 #defineSRBM_STATUS 0xE50
 
 #defineSRBM_SOFT_RESET 0x0E60
-- 
1.8.1.2

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

[PATCH 76/93] ARM: PCI: versatile: Fix map_irq function to match hardware

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Peter Maydell 

commit f9b71fef12f0d6ac5c7051cfd87f7700f78c56b6 upstream.

The PCI controller code for the Versatile board has never had the
correct IRQ mapping for hardware.  For many years it had an odd
mapping ("all interrupts are int 27") which aligned with the
equivalent bug in QEMU.  However as of commit 1bc39ac5dab265
the mapping changed and no longer matched either hardware or QEMU,
with the result that any PCI card beyond the first in QEMU would
not have functioning interrupts; for example a boot with a SCSI
controller would time out as follows:

 
 sym0: <895a> rev 0x0 at pci :00:0d.0 irq 92
 sym0: SCSI BUS has been reset.
 scsi0 : sym-2.2.3
 [...]
 scsi 0:0:0:0: ABORT operation started
 scsi 0:0:0:0: ABORT operation timed-out.
 scsi 0:0:0:0: DEVICE RESET operation started
 scsi 0:0:0:0: DEVICE RESET operation timed-out.
 scsi 0:0:0:0: BUS RESET operation started
 scsi 0:0:0:0: BUS RESET operation timed-out.
 scsi 0:0:0:0: HOST RESET operation started
 sym0: SCSI BUS has been reset
 

Fix the mapping so that it matches real hardware (checked against the
schematics for PB926 and backplane, and tested against the hardware).
This allows PCI cards using interrupts to work on hardware for the
first time; this change will also work with QEMU 1.5 or later, where
the equivalent bugs in the modelling of the hardware have been fixed.

Although QEMU will attempt to autodetect whether the kernel is
expecting the long-standing "everything is int 27" mapping or the one
hardware has, for certainty we force it into "definitely behave like
hardware mode"; this will avoid unexpected surprises later if we
implement sparse irqs. This is harmless on hardware.

Thanks to Paul Gortmaker for bisecting the problem and finding an initial
solution, to Russell King for providing the correct interrupt mapping,
and to Guenter Roeck for providing an initial version of this patch
and prodding me into relocating the hardware and retesting everything.

Signed-off-by: Peter Maydell 
Reviewed-by: Linus Walleij 
Signed-off-by: Kevin Hilman 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/mach-versatile/pci.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c
index e92e5e0..234740d 100644
--- a/arch/arm/mach-versatile/pci.c
+++ b/arch/arm/mach-versatile/pci.c
@@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct pci_sys_data 
*sys)
__raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2);
 
/*
+* For many years the kernel and QEMU were symbiotically buggy
+* in that they both assumed the same broken IRQ mapping.
+* QEMU therefore attempts to auto-detect old broken kernels
+* so that they still work on newer QEMU as they did on old
+* QEMU. Since we now use the correct (ie matching-hardware)
+* IRQ mapping we write a definitely different value to a
+* PCI_INTERRUPT_LINE register to tell QEMU that we expect
+* real hardware behaviour and it need not be backwards
+* compatible for us. This write is harmless on real hardware.
+*/
+   __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE);
+
+   /*
 * Do not to map Versatile FPGA PCI device into memory space
 */
pci_slot_ignore |= (1 << myslot);
@@ -327,13 +340,13 @@ static int __init versatile_map_irq(const struct pci_dev 
*dev, u8 slot, u8 pin)
 {
int irq;
 
-   /* slot,  pin,  irq
-*  24 1 IRQ_SIC_PCI0
-*  25 1 IRQ_SIC_PCI1
-*  26 1 IRQ_SIC_PCI2
-*  27 1 IRQ_SIC_PCI3
+   /*
+* Slot INTAINTBINTCINTD
+* 31   PCI1PCI2PCI3PCI0
+* 30   PCI0PCI1PCI2PCI3
+* 29   PCI3PCI0PCI1PCI2
 */
-   irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3);
+   irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3);
 
return irq;
 }
-- 
1.8.1.2

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

[PATCH 37/93] HID: validate HID report id size

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kees Cook 

commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.

The "Report ID" field of a HID report is used to build indexes of
reports. The kernel's index of these is limited to 256 entries, so any
malicious device that sets a Report ID greater than 255 will trigger
memory corruption on the host:

[ 1347.156239] BUG: unable to handle kernel paging request at 88094958a878
[ 1347.156261] IP: [] hid_register_report+0x2a/0x8b

CVE-2013-2888

Signed-off-by: Kees Cook 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-core.c | 10 +++---
 include/linux/hid.h|  4 +++-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 08eb32a..194597f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -63,6 +63,8 @@ struct hid_report *hid_register_report(struct hid_device 
*device, unsigned type,
struct hid_report_enum *report_enum = device->report_enum + type;
struct hid_report *report;
 
+   if (id >= HID_MAX_IDS)
+   return NULL;
if (report_enum->report_id_hash[id])
return report_enum->report_id_hash[id];
 
@@ -404,8 +406,10 @@ static int hid_parser_global(struct hid_parser *parser, 
struct hid_item *item)
 
case HID_GLOBAL_ITEM_TAG_REPORT_ID:
parser->global.report_id = item_udata(item);
-   if (parser->global.report_id == 0) {
-   hid_err(parser->device, "report_id 0 is invalid\n");
+   if (parser->global.report_id == 0 ||
+   parser->global.report_id >= HID_MAX_IDS) {
+   hid_err(parser->device, "report_id %u is invalid\n",
+   parser->global.report_id);
return -1;
}
return 0;
@@ -575,7 +579,7 @@ static void hid_close_report(struct hid_device *device)
for (i = 0; i < HID_REPORT_TYPES; i++) {
struct hid_report_enum *report_enum = device->report_enum + i;
 
-   for (j = 0; j < 256; j++) {
+   for (j = 0; j < HID_MAX_IDS; j++) {
struct hid_report *report = 
report_enum->report_id_hash[j];
if (report)
hid_free_report(report);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 7330a0f..13d812b 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -392,10 +392,12 @@ struct hid_report {
struct hid_device *device;  /* associated device */
 };
 
+#define HID_MAX_IDS 256
+
 struct hid_report_enum {
unsigned numbered;
struct list_head report_list;
-   struct hid_report *report_id_hash[256];
+   struct hid_report *report_id_hash[HID_MAX_IDS];
 };
 
 #define HID_REPORT_TYPES 3
-- 
1.8.1.2

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

[PATCH 39/93] cpuidle: coupled: disable interrupts after entering safe state

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Colin Cross 

commit 59e998561103a93f294c8d3138dd659af772a5da upstream.

Calling cpuidle_enter_state is expected to return with interrupts
enabled, but interrupts must be disabled before starting the
ready loop synchronization stage.  Call local_irq_disable after
each call to cpuidle_enter_state for the safe state.

Tested-by: Stephen Warren 
Signed-off-by: Colin Cross 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Kamal Mostafa 
---
 drivers/cpuidle/coupled.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index dc9e647..5d39627 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -470,6 +470,7 @@ int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
}
entered_state = cpuidle_enter_state(dev, drv,
dev->safe_state_index);
+   local_irq_disable();
}
 
/* Read barrier ensures online_count is read after prevent is cleared */
@@ -514,6 +515,7 @@ retry:
 
entered_state = cpuidle_enter_state(dev, drv,
dev->safe_state_index);
+   local_irq_disable();
}
 
if (cpuidle_coupled_clear_pokes(dev->cpu)) {
-- 
1.8.1.2

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

[PATCH 88/93] [SCSI] sd: Fix potential out-of-bounds access

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alan Stern 

commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream.

This patch fixes an out-of-bounds error in sd_read_cache_type(), found
by Google's AddressSanitizer tool.  When the loop ends, we know that
"offset" lies beyond the end of the data in the buffer, so no Caching
mode page was found.  In theory it may be present, but the buffer size
is limited to 512 bytes.

Signed-off-by: Alan Stern 
Reported-by: Dmitry Vyukov 
Signed-off-by: James Bottomley 
Signed-off-by: Kamal Mostafa 
---
 drivers/scsi/sd.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index a1dcdc3..bc108d2 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2421,14 +2421,9 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char 
*buffer)
}
}
 
-   if (modepage == 0x3F) {
-   sd_printk(KERN_ERR, sdkp, "No Caching mode page "
- "present\n");
-   goto defaults;
-   } else if ((buffer[offset] & 0x3f) != modepage) {
-   sd_printk(KERN_ERR, sdkp, "Got wrong page\n");
-   goto defaults;
-   }
+   sd_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
+   goto defaults;
+
Page_found:
if (modepage == 8) {
sdkp->WCE = ((buffer[offset + 2] & 0x04) != 0);
-- 
1.8.1.2

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

[PATCH 92/93] mm: fix aio performance regression for database caused by THP

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Khalid Aziz 

commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.

I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
)
allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag.  It then
does aio into these pages from flash disks using various common block
sizes used by database.  I am looking at performance with two of the most
common block sizes - 1M and 64K.  aio performance with these two block
sizes plunged after Transparent HugePages was introduced in the kernel.
Here are performance numbers:

pre-THP 2.6.39  3.11-rc5
1M read 8384 MB/s   5629 MB/s   6501 MB/s
64K read7867 MB/s   4576 MB/s   4251 MB/s

I have narrowed the performance impact down to the overheads introduced by
THP in __get_page_tail() and put_compound_page() routines.  perf top shows
>40% of cycles being spent in these two routines.  Every time direct I/O
to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
the pages and calls put_page() when I/O completes to put the reference
away.  THP introduced significant amount of locking overhead to get_page()
and put_page() when dealing with compound pages because hugepages can be
split underneath get_page() and put_page().  It added this overhead
irrespective of whether it is dealing with hugetlbfs pages or transparent
hugepages.  This resulted in 20%-45% drop in aio performance when using
hugetlbfs pages.

Since hugetlbfs pages can not be split, there is no reason to go through
all the locking overhead for these pages from what I can see.  I added
code to __get_page_tail() and put_compound_page() to bypass all the
locking code when working with hugetlbfs pages.  This improved performance
significantly.  Performance numbers with this patch:

pre-THP 3.11-rc53.11-rc5 + Patch
1M read 8384 MB/s   6501 MB/s   8371 MB/s
64K read7867 MB/s   4251 MB/s   6510 MB/s

Performance with 64K read is still lower than what it was before THP, but
still a 53% improvement.  It does mean there is more work to be done but I
will take a 53% improvement for now.

Please take a look at the following patch and let me know if it looks
reasonable.

[a...@linux-foundation.org: tweak comments]
Signed-off-by: Khalid Aziz 
Cc: Pravin B Shelar 
Cc: Christoph Lameter 
Cc: Andrea Arcangeli 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Minchan Kim 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 mm/swap.c | 77 ++-
 1 file changed, 52 insertions(+), 25 deletions(-)

diff --git a/mm/swap.c b/mm/swap.c
index 6310dc2..7009b21 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -77,6 +78,19 @@ static void __put_compound_page(struct page *page)
 
 static void put_compound_page(struct page *page)
 {
+   /*
+* hugetlbfs pages cannot be split from under us.  If this is a
+* hugetlbfs page, check refcount on head page and release the page if
+* the refcount becomes zero.
+*/
+   if (PageHuge(page)) {
+   page = compound_head(page);
+   if (put_page_testzero(page))
+   __put_compound_page(page);
+
+   return;
+   }
+
if (unlikely(PageTail(page))) {
/* __split_huge_page_refcount can run under us */
struct page *page_head = compound_trans_head(page);
@@ -180,38 +194,51 @@ bool __get_page_tail(struct page *page)
 * proper PT lock that already serializes against
 * split_huge_page().
 */
-   unsigned long flags;
bool got = false;
-   struct page *page_head = compound_trans_head(page);
+   struct page *page_head;
 
-   if (likely(page != page_head && get_page_unless_zero(page_head))) {
+   /*
+* If this is a hugetlbfs page it cannot be split under us.  Simply
+* increment refcount for the head page.
+*/
+   if (PageHuge(page)) {
+   page_head = compound_head(page);
+   atomic_inc(_head->_count);
+   got = true;
+   } else {
+   unsigned long flags;
+
+   page_head = compound_trans_head(page);
+   if (likely(page != page_head &&
+   get_page_unless_zero(page_head))) {
+
+   /* Ref to put_compound_page() comment. */
+   if (PageSlab(page_head)) {
+   if (likely(PageTail(page))) {
+   __get_page_tail_foll(page, 

Re: [PATCH] clockevents: Sanitize ticks to nsec conversion

[Uwe Kleine-König]

Hi Thomas,

On Fri, Sep 20, 2013 at 11:56:27AM +0200, Thomas Gleixner wrote:
> On Thu, 19 Sep 2013, Uwe Kleine-König wrote:
> > > +  * For mult <= (1 << shift) we can safely add mult - 1 to
> > > +  * prevent integer rounding loss. So the backwards conversion
> > It doesn't prevent inexactness to add mult - 1. It (only) asserts that
> > the ns2delta(delta2ns(latch)) >= latch instead of ... <= latch when not
> > doing it.
> 
> For mult <= 1 << shift the conversion is always ending up with the
> same latch value.
Ah right, I missed that we're in the slow-clock-case.

> > > +  * from nsec to device ticks will be correct.
> > > +  *
> > > +  * For mult > (1 << shift), i.e. device frequency is > 1GHz we
> > > +  * need to be careful. Adding mult - 1 will result in a value
> > > +  * which when converted back to device ticks will be larger
> > s/will/can/
> 
> No, it will always be larger.
Hmm, consider a 1.25 GHz clock with shift = 2 and mult = 5. Then
ns2clc(clc2ns(1000)) = 1000. So it's not always larger!
In the fast-clock-case we have:
With x << shift = n * mult - k for k in [0 .. mult-1] and an integer n:

  ns2clc(clc2ns(x))
= ns2clc(((x << shift) + mult - 1) / mult)
= x << shift) + mult - 1) / mult) * mult) >> shift
= n * mult >> shift
= ((x << shift) + k) >> shift
= x + (k >> shift)

So ns2clc(clc2ns(x)) = x for all x > 0 that have

k = mult - ((x << shift) - 1) % mult - 1 < 1 << shift

So my correction still stands.
 
> > > +  * than latch by (mult / (1 << shift)) - 1. For the min_delta
> > s/by/by up to/
>From the calculation above you can also see that this term is wrong. k
is smaller than mult (and there are values that realize k = mult - 1).
So the converted back value can be larger than latch by up to
(mult - 1) >> shift. This is zero for the slow-clock-case.

In the 1.25 GHz example above that means that the difference is up to 1,
not 0 as your term would imply. 1004 is an example where the conversion
to nano seconds and back to ticks results in a difference of 1.

> > > +  * calculation we still want to apply this in order to stay
> > > +  * above the minimum device ticks limit. For the upper limit
> > > +  * we would end up with a latch value larger than the upper
> > > +  * limit of the device, so we omit the add to stay below the
> > > +  * device upper boundary.
> > > +  *
> > > +  * Also omit the add if it would overflow the u64 boundary.
> > > +  */
> > > + if ((~0ULL - clc > rnd) &&
> > > + (!ismax || evt->mult <= (1U << evt->shift)))
> > > + clc += rnd;
> > I would expect that
> > 
> > if (!ismax)
> > if (~0ULL - clc > rnd)
> > clc += rnd;
> > else
> > clc = ~0ULL;
> > 
> > is enough (and a tad more exact in the presence of an overflow). I have
> > to think about that though.
> 
> Errm.
> 
> 1) We cannot add if we'd overflow
> 
> 2) For mult <= 1 << shift it's always correct
> 
> 3) for mult > 1 << shift we only apply it to the min value not the max
Yeah, I didn't say your code is wrong *here*. I just think that my
easier (and so probably faster) code is good enough.
 
> > >   clockevents_calc_mult_shift(dev, freq, sec);
> > > - dev->min_delta_ns = clockevent_delta2ns(dev->min_delta_ticks, dev);
> > > - dev->max_delta_ns = clockevent_delta2ns(dev->max_delta_ticks, dev);
> > > + dev->min_delta_ns = cev_delta2ns(dev->min_delta_ticks, dev, false);
> > > + dev->max_delta_ns = cev_delta2ns(dev->max_delta_ticks, dev, true);
> > Another improvement that came to my mind just now. For min_delta_ns you
> > want to assert that it results in a value >= min_delta_ticks when
> > converted back. For max_delta_ns you want ... value <= max_delta_ticks.
> > What about the values in between? They for sure should land in
> > [min_delta_ticks ... max_delta_ticks] when converted back and ideally
> > should be most exact. The latter part would mean to add (rnd / 2)
> > instead of rnd. I don't know yet how that would behave at the borders of
> > the [min_delta_ns ... max_delta_ns] interval, but I think you still need
> > to special-case that.
> 
> Again:
> 
> 1) For mult <= 1 << shift the backwards conversion is always the same as
>the input value.
> 
> 2) For mult > 1 << shift the backwards conversion of the min value is
>always > than the input value. And the backwards conversion of the
>max value is always < than the input value.
> 
> The values between that are completely uninteresting as the
> program_events code always converts from nsec to device ticks.
> 
> We clamp the delta between min_ns and max_ns. So due to the above any
> 
>min_ns <= delta <= max_ns
> 
> will after conversion fulfil 
> 
>min_tick <= delta_tick <= max_tick
> 
> So what are you going to improve? Either the math works or it does not.
Right, my idea is nice, but useless.

So I suggest you resend your patch with the compile fix and the
corrected comment and I will think about my 

Re: [PATCH 30/41] usb: musb: ux500: Don't supply a con_id when requesting the clock

[Linus Walleij]

On Wed, Sep 18, 2013 at 2:14 PM, Lee Jones  wrote:

> If we supply a con_id then the clock framework will search for that name
> in MUSB's Device Tree node for the 'clock-names' property. If it's absent
> the clock request will fail. However, if we don't supply the con_id then
> clk_get() will call into clk_sys() which will use the device name to
> search for the appropriate clock, which is much more natural than forcing
> 'usb'.
>
> Cc: Felipe Balbi 
> Signed-off-by: Lee Jones 

Looks fine to me, Felipe can we have your ACK on this so I can take
this with the rest of the clock stuff through ARM SoC?

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/

[PATCH 64/93] [media] DocBook: upgrade media_api DocBook version to 4.2

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andrzej Hajda 

commit 8bfd4a68ecc003c1a142f35551be846d6b13e822 upstream.

Fixes the last three errors of media_api DocBook validatation:
(...)
media_api.xml:414: element imagedata: validity error : Value "SVG" for 
attribute format of imagedata is not among the enumerated set
media_api.xml:432: element imagedata: validity error : Value "SVG" for 
attribute format of imagedata is not among the enumerated set
media_api.xml:452: element imagedata: validity error : Value "SVG" for 
attribute format of imagedata is not among the enumerated set
(...)

Signed-off-by: Andrzej Hajda 
Signed-off-by: Kyungmin Park 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 Documentation/DocBook/media_api.tmpl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media_api.tmpl 
b/Documentation/DocBook/media_api.tmpl
index f2413ac..ac60e03 100644
--- a/Documentation/DocBook/media_api.tmpl
+++ b/Documentation/DocBook/media_api.tmpl
@@ -1,6 +1,6 @@
 
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [
  %media-entities;
 
 
-- 
1.8.1.2

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

[PATCH 29/93] usb: ehci-mxc: check for pdata before dereferencing

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Daniel Mack 

commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.

Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based
boards") introduced code that could potentially lead to a NULL pointer
dereference on driver removal.

Fix this by checking for the value of pdata before dereferencing it.

Signed-off-by: Daniel Mack 
Reported-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/ehci-mxc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index dedb80b..f4f032e 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -211,7 +211,7 @@ static int __exit ehci_mxc_drv_remove(struct 
platform_device *pdev)
if (pdata && pdata->exit)
pdata->exit(pdev);
 
-   if (pdata->otg)
+   if (pdata && pdata->otg)
usb_phy_shutdown(pdata->otg);
 
clk_disable_unprepare(priv->usbclk);
-- 
1.8.1.2

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

[PATCH 23/93] rculist: list_first_or_null_rcu() should use list_entry_rcu()

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Tejun Heo 

commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream.

list_first_or_null() should test whether the list is empty and return
pointer to the first entry if not in a RCU safe manner.  It's broken
in several ways.

* It compares __kernel @__ptr with __rcu @__next triggering the
  following sparse warning.

  net/core/dev.c:4331:17: error: incompatible types in comparison expression 
(different address spaces)

* It doesn't perform rcu_dereference*() and computes the entry address
  using container_of() directly from the __rcu pointer which is
  inconsitent with other rculist interface.  As a result, all three
  in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
  dereference the pointer w/o going through read barrier.

* While ->next dereference passes through list_next_rcu(), the
  compiler is still free to fetch ->next more than once and thus
  nullify the "__ptr != __next" condition check.

Fix it by making list_first_or_null_rcu() dereference ->next directly
using ACCESS_ONCE() and then use list_entry_rcu() on it like other
rculist accessors.

v2: Paul pointed out that the compiler may fetch the pointer more than
once nullifying the condition check.  ACCESS_ONCE() added on
->next dereference.

v3: Restored () around macro param which was accidentally removed.
Spotted by Paul.

Signed-off-by: Tejun Heo 
Reported-by: Fengguang Wu 
Cc: Dipankar Sarma 
Cc: "Paul E. McKenney" 
Cc: "David S. Miller" 
Cc: Li Zefan 
Cc: Patrick McHardy 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett 
Signed-off-by: Kamal Mostafa 
---
 include/linux/rculist.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index c92dd28..c9e7330 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -267,8 +267,9 @@ static inline void list_splice_init_rcu(struct list_head 
*list,
  */
 #define list_first_or_null_rcu(ptr, type, member) \
({struct list_head *__ptr = (ptr); \
- struct list_head __rcu *__next = list_next_rcu(__ptr); \
- likely(__ptr != __next) ? container_of(__next, type, member) : NULL; \
+ struct list_head *__next = ACCESS_ONCE(__ptr->next); \
+ likely(__ptr != __next) ? \
+   list_entry_rcu(__next, type, member) : NULL; \
})
 
 /**
-- 
1.8.1.2

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

[PATCH 36/93] ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Lan Tianyu 

commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
Reported-and-tested-by: Daniele Esposti 
Signed-off-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Kamal Mostafa 
---
 drivers/acpi/ec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index bbb6d47..0b58c9d 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -987,6 +987,10 @@ static struct dmi_system_id __initdata ec_dmi_table[] = {
ec_skip_dsdt_scan, "HP Folio 13", {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13"),}, NULL},
+   {
+   ec_validate_ecdt, "ASUS hardware", {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
{},
 };
 
-- 
1.8.1.2

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

[PATCH 75/93] HID: check for NULL field when setting values

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kees Cook 

commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.

Defensively check that the field to be worked on is not NULL.

Signed-off-by: Kees Cook 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 194597f..869ead1 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1157,7 +1157,12 @@ EXPORT_SYMBOL_GPL(hid_output_report);
 
 int hid_set_field(struct hid_field *field, unsigned offset, __s32 value)
 {
-   unsigned size = field->report_size;
+   unsigned size;
+
+   if (!field)
+   return -1;
+
+   size = field->report_size;
 
hid_dump_input(field->report->device, field->usage + offset, value);
 
-- 
1.8.1.2

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

[PATCH 77/93] ARM: PCI: versatile: Fix PCI I/O

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Peter Maydell 

commit 829f9fedee30cde2ec15e88d57ec11074db791e2 upstream.

The versatile PCI controller code was confused between the
PCI I/O window (at 0x4300) and the first PCI memory
window (at 0x4400). Pass the correct base address to
pci_remap_io() so that PCI I/O accesses work.

Since the first PCI memory window isn't used at all (it's
an odd size), rename the associated variables and labels
so that it's clear that it isn't related to the I/O window.

This has been tested and confirmed to fix PCI I/O accesses
both on physical PB926+PCI backplane hardware and on QEMU.

Signed-off-by: Peter Maydell 
Reviewed-by: Linus Walleij 
Signed-off-by: Kevin Hilman 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/mach-versatile/include/mach/platform.h |  2 ++
 arch/arm/mach-versatile/pci.c   | 16 
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-versatile/include/mach/platform.h 
b/arch/arm/mach-versatile/include/mach/platform.h
index ec08740..6f938cc 100644
--- a/arch/arm/mach-versatile/include/mach/platform.h
+++ b/arch/arm/mach-versatile/include/mach/platform.h
@@ -231,12 +231,14 @@
 /* PCI space */
 #define VERSATILE_PCI_BASE 0x4100  /* PCI Interface */
 #define VERSATILE_PCI_CFG_BASE0x4200
+#define VERSATILE_PCI_IO_BASE  0x4300
 #define VERSATILE_PCI_MEM_BASE00x4400
 #define VERSATILE_PCI_MEM_BASE10x5000
 #define VERSATILE_PCI_MEM_BASE20x6000
 /* Sizes of above maps */
 #define VERSATILE_PCI_BASE_SIZE   0x0100
 #define VERSATILE_PCI_CFG_BASE_SIZE0x0200
+#define VERSATILE_PCI_IO_BASE_SIZE 0x0100
 #define VERSATILE_PCI_MEM_BASE0_SIZE   0x0c00  /* 32Mb */
 #define VERSATILE_PCI_MEM_BASE1_SIZE   0x1000  /* 256Mb */
 #define VERSATILE_PCI_MEM_BASE2_SIZE   0x1000  /* 256Mb */
diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c
index 234740d..1e48878 100644
--- a/arch/arm/mach-versatile/pci.c
+++ b/arch/arm/mach-versatile/pci.c
@@ -170,8 +170,8 @@ static struct pci_ops pci_versatile_ops = {
.write  = versatile_write_config,
 };
 
-static struct resource io_mem = {
-   .name   = "PCI I/O space",
+static struct resource unused_mem = {
+   .name   = "PCI unused",
.start  = VERSATILE_PCI_MEM_BASE0,
.end= VERSATILE_PCI_MEM_BASE0+VERSATILE_PCI_MEM_BASE0_SIZE-1,
.flags  = IORESOURCE_MEM,
@@ -195,9 +195,9 @@ static int __init pci_versatile_setup_resources(struct 
pci_sys_data *sys)
 {
int ret = 0;
 
-   ret = request_resource(_resource, _mem);
+   ret = request_resource(_resource, _mem);
if (ret) {
-   printk(KERN_ERR "PCI: unable to allocate I/O "
+   printk(KERN_ERR "PCI: unable to allocate unused "
   "memory region (%d)\n", ret);
goto out;
}
@@ -205,7 +205,7 @@ static int __init pci_versatile_setup_resources(struct 
pci_sys_data *sys)
if (ret) {
printk(KERN_ERR "PCI: unable to allocate non-prefetchable "
   "memory region (%d)\n", ret);
-   goto release_io_mem;
+   goto release_unused_mem;
}
ret = request_resource(_resource, _mem);
if (ret) {
@@ -225,8 +225,8 @@ static int __init pci_versatile_setup_resources(struct 
pci_sys_data *sys)
 
  release_non_mem:
release_resource(_mem);
- release_io_mem:
-   release_resource(_mem);
+ release_unused_mem:
+   release_resource(_mem);
  out:
return ret;
 }
@@ -246,7 +246,7 @@ int __init pci_versatile_setup(int nr, struct pci_sys_data 
*sys)
goto out;
}
 
-   ret = pci_ioremap_io(0, VERSATILE_PCI_MEM_BASE0);
+   ret = pci_ioremap_io(0, VERSATILE_PCI_IO_BASE);
if (ret)
goto out;
 
-- 
1.8.1.2

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

[PATCH 71/93] HID: pantherlord: validate output report details

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kees Cook 

commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream.

A HID device could send a malicious output report that would cause the
pantherlord HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:

[  310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
...
[  315.980774] BUG kmalloc-192 (Tainted: GW   ): Redzone overwritten

CVE-2013-2892

Signed-off-by: Kees Cook 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-pl.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
index 47ed74c..00cd2f8 100644
--- a/drivers/hid/hid-pl.c
+++ b/drivers/hid/hid-pl.c
@@ -129,8 +129,14 @@ static int plff_init(struct hid_device *hid)
strong = >field[0]->value[2];
weak = >field[0]->value[3];
debug("detected single-field device");
-   } else if (report->maxfield >= 4 && report->field[0]->maxusage 
== 1 &&
-   report->field[0]->usage[0].hid == (HID_UP_LED | 
0x43)) {
+   } else if (report->field[0]->maxusage == 1 &&
+  report->field[0]->usage[0].hid ==
+   (HID_UP_LED | 0x43) &&
+  report->maxfield >= 4 &&
+  report->field[0]->report_count >= 1 &&
+  report->field[1]->report_count >= 1 &&
+  report->field[2]->report_count >= 1 &&
+  report->field[3]->report_count >= 1) {
report->field[0]->value[0] = 0x00;
report->field[1]->value[0] = 0x00;
strong = >field[2]->value[0];
-- 
1.8.1.2

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

[PATCH 22/93] ASoC: wm8960: Fix PLL register writes

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mike Dyer 

commit 85fa532b6ef920b32598df86b194571a7059a77c upstream.

Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part
should be split across each register in 8bit chunks.

Signed-off-by: Mike Dyer 
Signed-off-by: Mark Brown 
Signed-off-by: Kamal Mostafa 
---
 sound/soc/codecs/wm8960.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 9bb9273..9d16a89 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -847,9 +847,9 @@ static int wm8960_set_dai_pll(struct snd_soc_dai 
*codec_dai, int pll_id,
if (pll_div.k) {
reg |= 0x20;
 
-   snd_soc_write(codec, WM8960_PLL2, (pll_div.k >> 18) & 0x3f);
-   snd_soc_write(codec, WM8960_PLL3, (pll_div.k >> 9) & 0x1ff);
-   snd_soc_write(codec, WM8960_PLL4, pll_div.k & 0x1ff);
+   snd_soc_write(codec, WM8960_PLL2, (pll_div.k >> 16) & 0xff);
+   snd_soc_write(codec, WM8960_PLL3, (pll_div.k >> 8) & 0xff);
+   snd_soc_write(codec, WM8960_PLL4, pll_div.k & 0xff);
}
snd_soc_write(codec, WM8960_PLL1, reg);
 
-- 
1.8.1.2

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

[PATCH 90/93] ocfs2: fix the end cluster offset of FIEMAP

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jie Liu 

commit 28e8be31803b19d0d8f76216cb11b480b8a98bec upstream.

Call fiemap ioctl(2) with given start offset as well as an desired mapping
range should show extents if possible.  However, we somehow figure out the
end offset of mapping via 'mapping_end -= cpos' before iterating the
extent records which would cause problems if the given fiemap length is
too small to a cluster size, e.g,

Cluster size 4096:
debugfs.ocfs2 1.6.3
Block Size Bits: 12   Cluster Size Bits: 12

The extended fiemap test utility From David:
https://gist.github.com/anonymous/6172331

# dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
# ./fiemap /ocfs2/test_file 4096 10
start: 4096, length: 10
File /ocfs2/test_file has 0 extents:
#   Logical  Physical Length   Flags
^ <-- No extent is shown

In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
loop of searching extent records was not executed at all.

This patch remove the in question 'mapping_end -= cpos', and loops
until the cpos is larger than the mapping_end as usual.

# ./fiemap /ocfs2/test_file 4096 10
start: 4096, length: 10
File /ocfs2/test_file has 1 extents:
#   Logical  Physical Length   Flags
0:   56a01000 06a0 

Signed-off-by: Jie Liu 
Reported-by: David Weber 
Tested-by: David Weber 
Cc: Sunil Mushran 
Cc: Mark Fashen 
Cc: Joel Becker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 fs/ocfs2/extent_map.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c
index c5bfb4c..a1822f8 100644
--- a/fs/ocfs2/extent_map.c
+++ b/fs/ocfs2/extent_map.c
@@ -782,7 +782,6 @@ int ocfs2_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
cpos = map_start >> osb->s_clustersize_bits;
mapping_end = ocfs2_clusters_for_bytes(inode->i_sb,
   map_start + map_len);
-   mapping_end -= cpos;
is_last = 0;
while (cpos < mapping_end && !is_last) {
u32 fe_flags;
-- 
1.8.1.2

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

[PATCH 66/93] [media] hdpvr: fix iteration over uninitialized lists in hdpvr_probe()

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alexey Khoroshilov 

commit 2e923a0527ac439e135b9961e58d3acd876bba10 upstream.

free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
but if something bad happens before that, error handling code calls 
hdpvr_delete(),
which contains iteration over the lists (via hdpvr_free_buffers()).
The patch moves the lists initialization to the beginning and by the way fixes
goto label in error handling of registering videodev.
Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa 
---
 drivers/media/usb/hdpvr/hdpvr-core.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c 
b/drivers/media/usb/hdpvr/hdpvr-core.c
index 84dc26f..e35fab4 100644
--- a/drivers/media/usb/hdpvr/hdpvr-core.c
+++ b/drivers/media/usb/hdpvr/hdpvr-core.c
@@ -309,6 +309,11 @@ static int hdpvr_probe(struct usb_interface *interface,
 
dev->workqueue = 0;
 
+   /* init video transfer queues first of all */
+   /* to prevent oops in hdpvr_delete() on error paths */
+   INIT_LIST_HEAD(>free_buff_list);
+   INIT_LIST_HEAD(>rec_buff_list);
+
/* register v4l2_device early so it can be used for printks */
if (v4l2_device_register(>dev, >v4l2_dev)) {
dev_err(>dev, "v4l2_device_register failed\n");
@@ -331,10 +336,6 @@ static int hdpvr_probe(struct usb_interface *interface,
if (!dev->workqueue)
goto error;
 
-   /* init video transfer queues */
-   INIT_LIST_HEAD(>free_buff_list);
-   INIT_LIST_HEAD(>rec_buff_list);
-
dev->options = hdpvr_default_options;
 
if (default_video_input < HDPVR_VIDEO_INPUTS)
@@ -388,7 +389,7 @@ static int hdpvr_probe(struct usb_interface *interface,
if (hdpvr_register_videodev(dev, >dev,
video_nr[atomic_inc_return(_nr)])) {
v4l2_err(>v4l2_dev, "registering videodev failed\n");
-   goto error;
+   goto reg_fail;
}
 
 #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
-- 
1.8.1.2

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

[PATCH 45/93] drm/edid: add quirk for Medion MD30217PG

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream.

This LCD monitor (1280x1024 native) has a completely
bogus detailed timing (640x350@70hz).  User reports that
1280x1024@60 has waves so prefer 1280x1024@75.

Manufacturer: MED  Model: 7b8  Serial#: 99188
Year: 2005  Week: 5
EDID Version: 1.3
Analog Display Input,  Input Voltage Level: 0.700/0.700 V
Sync:  Separate
Max Image Size [cm]: horiz.: 34  vert.: 27
Gamma: 2.50
DPMS capabilities: Off; RGB/Color Display
First detailed timing is preferred mode
redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
Supported established timings:
720x400@70Hz
640x480@60Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
Manufacturer's mask: 0
Supported standard timings:
Supported detailed timing:
clock: 25.2 MHz   Image Size:  337 x 270 mm
h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
Monitor name: MD30217PG
Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
Serial No: 501099188
EDID (in hex):
  000034a4b80774830100
  050f010368221b962a0c55a559479b24
  125054afcf00310a0101010101018180
  d60980a0205e63103060
  0200510e111e00fc004d4433
  3032313750470a20202000fd0038
  4c1e530e000a20202020202000ff
  003530313039393138380a2020200078

Signed-off-by: Alex Deucher 
Reported-by: friedr...@mailstation.de
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfd9ed3..60d6b35 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -125,6 +125,9 @@ static struct edid_quirk {
 
/* ViewSonic VA2026w */
{ "VSC", 5020, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
+   /* Medion MD 30217 PG */
+   { "MED", 0x7b8, EDID_QUIRK_PREFER_LARGE_75 },
 };
 
 /*** DDC fetch and block validation ***/
-- 
1.8.1.2

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

[PATCH 74/93] HID: picolcd_core: validate output report details

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kees Cook 

commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.

A HID device could send a malicious output report that would cause the
picolcd HID driver to trigger a NULL dereference during attr file writing.

[jkos...@suse.cz: changed

report->maxfield < 1

to

report->maxfield != 1

as suggested by Bruno].

CVE-2013-2899

Signed-off-by: Kees Cook 
Reviewed-by: Bruno Prémont 
Acked-by: Bruno Prémont 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-picolcd_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index 86df26e..775252d 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -292,7 +292,7 @@ static ssize_t picolcd_operation_mode_store(struct device 
*dev,
buf += 10;
cnt -= 10;
}
-   if (!report)
+   if (!report || report->maxfield != 1)
return -EINVAL;
 
while (cnt > 0 && (buf[cnt-1] == '\n' || buf[cnt-1] == '\r'))
-- 
1.8.1.2

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

[PATCH 31/93] proc: Restrict mounting the proc filesystem

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Eric W. Biederman" 

commit aee1c13dd0f6c2fc56e0e492b349ee8ac655880f upstream.

Don't allow mounting the proc filesystem unless the caller has
CAP_SYS_ADMIN rights over the pid namespace.  The principle here is if
you create or have capabilities over it you can mount it, otherwise
you get to live with what other people have mounted.

Andy pointed out that this is needed to prevent users in a user
namespace from remounting proc and specifying different hidepid and gid
options on already existing proc mounts.

Reported-by: Andy Lutomirski 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Kamal Mostafa 
---
 fs/proc/root.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/proc/root.c b/fs/proc/root.c
index 9c7fab1..411068e 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -110,7 +110,8 @@ static struct dentry *proc_mount(struct file_system_type 
*fs_type,
ns = task_active_pid_ns(current);
options = data;
 
-   if (!current_user_ns()->may_mount_proc)
+   if (!current_user_ns()->may_mount_proc ||
+   !ns_capable(ns->user_ns, CAP_SYS_ADMIN))
return ERR_PTR(-EPERM);
}
 
-- 
1.8.1.2

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

[PATCH 89/93] pidns: fix vfork() after unshare(CLONE_NEWPID)

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Oleg Nesterov 

commit e79f525e99b04390ca4d2366309545a836c03bf1 upstream.

Commit 8382fcac1b81 ("pidns: Outlaw thread creation after
unshare(CLONE_NEWPID)") nacks CLONE_VM if the forking process unshared
pid_ns, this obviously breaks vfork:

int main(void)
{
assert(unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0);
assert(vfork() >= 0);
_exit(0);
return 0;
}

fails without this patch.

Change this check to use CLONE_SIGHAND instead.  This also forbids
CLONE_THREAD automatically, and this is what the comment implies.

We could probably even drop CLONE_SIGHAND and use CLONE_THREAD, but it
would be safer to not do this.  The current check denies CLONE_SIGHAND
implicitely and there is no reason to change this.

Eric said "CLONE_SIGHAND is fine.  CLONE_THREAD would be even better.
Having shared signal handling between two different pid namespaces is
the case that we are fundamentally guarding against."

Signed-off-by: Oleg Nesterov 
Reported-by: Colin Walters 
Acked-by: Andy Lutomirski 
Reviewed-by: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa 
---
 kernel/fork.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 1c53e38..5c992f8 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1170,10 +1170,11 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
return ERR_PTR(-EINVAL);
 
/*
-* If the new process will be in a different pid namespace
-* don't allow the creation of threads.
+* If the new process will be in a different pid namespace don't
+* allow it to share a thread group or signal handlers with the
+* forking task.
 */
-   if ((clone_flags & (CLONE_VM|CLONE_NEWPID)) &&
+   if ((clone_flags & (CLONE_SIGHAND | CLONE_NEWPID)) &&
(task_active_pid_ns(current) != current->nsproxy->pid_ns))
return ERR_PTR(-EINVAL);
 
-- 
1.8.1.2

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

[PATCH 65/93] [media] v4l2: added missing mutex.h include to v4l2-ctrls.h

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andrzej Hajda 

commit a19dec6ea94c036af68c31930c1c92681f55af41 upstream.

This patch fixes following error:
include/media/v4l2-ctrls.h:193:15: error: field ‘_lock’ has incomplete type
include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_lock’:
include/media/v4l2-ctrls.h:570:2: error: implicit declaration of
function ‘mutex_lock’ [-Werror=implicit-function-declaration]
include/media/v4l2-ctrls.h: In function ‘v4l2_ctrl_unlock’:
include/media/v4l2-ctrls.h:579:2: error: implicit declaration of
function ‘mutex_unlock’ [-Werror=implicit-function-declaration]

Signed-off-by: Andrzej Hajda 
Signed-off-by: Kyungmin Park 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 include/media/v4l2-ctrls.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 9650911..0f9b3c3 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -22,6 +22,7 @@
 #define _V4L2_CTRLS_H
 
 #include 
+#include 
 #include 
 
 /* forward references */
-- 
1.8.1.2

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

[PATCH 70/93] libceph: use pg_num_mask instead of pgp_num_mask for pg.seed calc

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sage Weil 

commit 9542cf0bf9b1a3adcc2ef271edbcbdba03abf345 upstream.

Fix a typo that used the wrong bitmask for the pg.seed calculation.  This
is normally unnoticed because in most cases pg_num == pgp_num.  It is, however,
a bug that is easily corrected.

Signed-off-by: Sage Weil 
Reviewed-by: Alex Elder 
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa 
---
 net/ceph/osdmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index de73214..652c11e 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -1128,7 +1128,7 @@ static int *calc_pg_raw(struct ceph_osdmap *osdmap, 
struct ceph_pg pgid,
 
/* pg_temp? */
t = ceph_stable_mod(ps, le32_to_cpu(pool->v.pg_num),
-   pool->pgp_num_mask);
+   pool->pg_num_mask);
pgid.ps = cpu_to_le16(t);
pg = __lookup_pg_mapping(>pg_temp, pgid);
if (pg) {
-- 
1.8.1.2

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

[PATCH 34/93] pinctrl: at91: fix get_pullup/down function return

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Boris BREZILLON 

commit 05d3534a321d7fe4524b3b83bb20318282f3ec2c upstream.

In PIO_PUSR and PIO_PPDSR register if a given bit is set 1 this means the
pullup/down for this pin (pin is represented as a bit position) is
disabled.

Signed-off-by: Boris BREZILLON 
Acked-by: Nicolas Ferre 
Signed-off-by: Linus Walleij 
Signed-off-by: Kamal Mostafa 
---
 drivers/pinctrl/pinctrl-at91.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 471c71f..d3234a6 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -326,7 +326,7 @@ static void at91_mux_disable_interrupt(void __iomem *pio, 
unsigned mask)
 
 static unsigned at91_mux_get_pullup(void __iomem *pio, unsigned pin)
 {
-   return (readl_relaxed(pio + PIO_PUSR) >> pin) & 0x1;
+   return !((readl_relaxed(pio + PIO_PUSR) >> pin) & 0x1);
 }
 
 static void at91_mux_set_pullup(void __iomem *pio, unsigned mask, bool on)
@@ -446,7 +446,7 @@ static void at91_mux_pio3_set_debounce(void __iomem *pio, 
unsigned mask,
 
 static bool at91_mux_pio3_get_pulldown(void __iomem *pio, unsigned pin)
 {
-   return (__raw_readl(pio + PIO_PPDSR) >> pin) & 0x1;
+   return !((__raw_readl(pio + PIO_PPDSR) >> pin) & 0x1);
 }
 
 static void at91_mux_pio3_set_pulldown(void __iomem *pio, unsigned mask, bool 
is_on)
-- 
1.8.1.2

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

[PATCH 32/93] usb: xhci: Disable runtime PM suspend for quirky controllers

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Shawn Nematbakhsh 

commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.

If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).

Note that this change is only relevant when persist_enabled is not set
for USB devices.

This patch should be backported to kernels as old as 3.0, that
contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
reset on resume quirk for asrock p67 host".

Signed-off-by: Shawn Nematbakhsh 
Signed-off-by: Sarah Sharp 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 99d68c8..8889d67 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3507,10 +3507,21 @@ void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
+   struct device *dev = hcd->self.controller;
unsigned long flags;
u32 state;
int i, ret;
 
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+   /*
+* We called pm_runtime_get_noresume when the device was attached.
+* Decrement the counter here to allow controller to runtime suspend
+* if no devices remain.
+*/
+   if (xhci->quirks & XHCI_RESET_ON_RESUME)
+   pm_runtime_put_noidle(dev);
+#endif
+
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
/* If the host is halted due to driver unload, we still need to free the
 * device.
@@ -3582,6 +3593,7 @@ static int xhci_reserve_host_control_ep_resources(struct 
xhci_hcd *xhci)
 int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   struct device *dev = hcd->self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -3634,6 +3646,16 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
goto disable_slot;
}
udev->slot_id = xhci->slot_id;
+
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+   /*
+* If resetting upon resume, we can't put the controller into runtime
+* suspend if there is a device attached.
+*/
+   if (xhci->quirks & XHCI_RESET_ON_RESUME)
+   pm_runtime_get_noresume(dev);
+#endif
+
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
-- 
1.8.1.2

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

[PATCH v4] sharpsl_param.c: ARM: pxa: fix invalid memory access

[Andrea Adami]

After commit 72662e01088394577be4a3f14da94cf87bea2591
ARM: head.S: only include __turn_mmu_on in the initial identity mapping

Zaurus PXA devices call sharpsl_save_param() during fixup and hang on
boot because memcpy refers to physical addresses no longer valid if the
MMU is setup.
Zaurus collie (SA1100) is unaffected (function is called in init_machine).

The code was making assumptions and for PXA the virtual address
should have been used before.

Signed-off-by: Marko Katic 
Signed-off-by: Andrea Adami 
---
 arch/arm/common/sharpsl_param.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
index d56c932..3490549 100644
--- a/arch/arm/common/sharpsl_param.c
+++ b/arch/arm/common/sharpsl_param.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Certain hardware parameters determined at the time of device manufacture,
@@ -25,8 +26,10 @@
  */
 #ifdef CONFIG_ARCH_SA1100
 #define PARAM_BASE 0xe8ffc000
+#define param_start(x) (void *)(x)
 #else
 #define PARAM_BASE 0xaa00
+#define param_start(x) __va(x)
 #endif
 #define MAGIC_CHG(a,b,c,d) ( ( d << 24 ) | ( c << 16 )  | ( b << 8 ) | a )
 
@@ -41,7 +44,7 @@ EXPORT_SYMBOL(sharpsl_param);
 
 void sharpsl_save_param(void)
 {
-   memcpy(_param, (void *)PARAM_BASE, sizeof(struct 
sharpsl_param_info));
+   memcpy(_param, param_start(PARAM_BASE), sizeof(struct 
sharpsl_param_info));
 
if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
sharpsl_param.comadj=-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/

[PATCH 01/93] Revert "net/core/sock.c: add missing VSOCK string in af_family_*_key_strings"

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kamal Mostafa 

This reverts commit 98aab898043fdc0f63621dae282fb5448fc39f9a, which
was commit 456db6a4d495f40777da6f1f32f62f13026f52db upstream.

98aab89 should not have been applied to v3.8-stable since VSOCK is not
relevant for v3.8.

Cc: Federico Vaga 
Cc: David S. Miller 
Cc: Markus Kreidl 
Signed-off-by: Kamal Mostafa 
---
 net/core/sock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 57b3243..b8af814 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -208,7 +208,7 @@ static const char *const af_family_key_strings[AF_MAX+1] = {
   "sk_lock-AF_TIPC"  , "sk_lock-AF_BLUETOOTH", "sk_lock-IUCV",
   "sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN" , "sk_lock-AF_PHONET"   ,
   "sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG"  ,
-  "sk_lock-AF_NFC"   , "sk_lock-AF_VSOCK", "sk_lock-AF_MAX"
+  "sk_lock-AF_NFC"   , "sk_lock-AF_MAX"
 };
 static const char *const af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_UNSPEC", "slock-AF_UNIX" , "slock-AF_INET" ,
@@ -224,7 +224,7 @@ static const char *const 
af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_TIPC"  , "slock-AF_BLUETOOTH", "slock-AF_IUCV" ,
   "slock-AF_RXRPC" , "slock-AF_ISDN" , "slock-AF_PHONET"   ,
   "slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG"  ,
-  "slock-AF_NFC"   , "slock-AF_VSOCK","slock-AF_MAX"
+  "slock-AF_NFC"   , "slock-AF_MAX"
 };
 static const char *const af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_UNSPEC", "clock-AF_UNIX" , "clock-AF_INET" ,
@@ -240,7 +240,7 @@ static const char *const 
af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_TIPC"  , "clock-AF_BLUETOOTH", "clock-AF_IUCV" ,
   "clock-AF_RXRPC" , "clock-AF_ISDN" , "clock-AF_PHONET"   ,
   "clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG"  ,
-  "clock-AF_NFC"   , "clock-AF_VSOCK", "clock-AF_MAX"
+  "clock-AF_NFC"   , "clock-AF_MAX"
 };
 
 /*
-- 
1.8.1.2

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

Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing

[Nicholas A. Bellinger]

Hi Alexander!

Apologies for the long delay on this follow-up..  Comments below.

On Fri, 2013-09-20 at 17:19 +0200, Alexander Gordeev wrote:
> On Thu, Aug 15, 2013 at 07:19:29PM -0700, Nicholas A. Bellinger wrote:
> > Ok, here's a bit better idea of what is going on now..
> > 
> > The problem is that blkdev_issue_flush() -> blk_mq_make_request() ->
> > __blk_mq_alloc_request() allocates the first tag, which calls
> > blk_insert_flush() -> blk_flush_complete_seq() -> blk_flush_kick() ->
> > mq_flush_work() -> blk_mq_alloc_request() to allocate a second tag for
> > the struct request that actually gets dispatched into scsi-mq as a
> > SYCHRONIZE_CACHE command..
> > 
> > I'm not exactly sure why this double tag usage of struct request is
> > occurring, but AFAICT it does happen for every flush, and is not
> > specific to the blkdev_issue_flush() codepath..  I'm sure that Jens can
> > fill us in on that bit.  ;)
> 
> I also played with the double tag using a reserved tag (below).
> 
> While it fixes 'fdisk /dev/sda' issue when trying to 'mount /dev/sda1 /mnt'
> what appears to be a call to bio->bi_end_io() from the free'd bio hits in.
> 
> Not sure if I should pursue the root cause until the whole double-tag
> thingy is confirmed.
> 
> Jens?
> 
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 6fc1df3..81794dc 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -874,14 +874,14 @@ static void blk_mq_make_request(struct request_queue 
> *q, struct bio *bio)
>   hctx = q->mq_ops->map_queue(q, ctx->cpu);
>  
>   trace_block_getrq(q, bio, rw);
> - rq = __blk_mq_alloc_request(hctx, GFP_ATOMIC, false);
> + rq = __blk_mq_alloc_request(hctx, GFP_ATOMIC, is_flush_fua);
>   if (likely(rq))
>   blk_mq_rq_ctx_init(ctx, rq, rw);
>   else {
>   blk_mq_put_ctx(ctx);
>   trace_block_sleeprq(q, bio, rw);
>   rq = blk_mq_alloc_request_pinned(q, rw, __GFP_WAIT|GFP_ATOMIC,
> - false);
> + is_flush_fua);
>   ctx = rq->mq_ctx;
>   hctx = q->mq_ops->map_queue(q, ctx->cpu);
>   }

So this is what I ended up doing as well, and does address the specific
bug with queue_depth=1.

> @@ -1317,6 +1317,9 @@ struct request_queue *blk_mq_init_queue(struct 
> blk_mq_reg *reg,
>   reg->queue_depth = BLK_MQ_MAX_DEPTH;
>   }
>  
> + reg->queue_depth++;
> + reg->reserved_tags++;
> +
>   ctx = alloc_percpu(struct blk_mq_ctx);
>   if (!ctx)
>   return ERR_PTR(-ENOMEM);
> 

I was actually setting this within scsi_mq_alloc_queue(), but given that
the queue_depth=1 issue is independent of scsi-mq, this does make more
sense.

Also, these extra increments should probably happen only when the passed
queue_depth == 1 && reserved_tags == 0.

Other than that minor nit.

Reviewed-by: Nicholas Bellinger 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 33/93] USB: OHCI: Allow runtime PM without system sleep

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alan Stern 

commit 69820e01aa756b8d228143d997f71523c1e97984 upstream.

Since ohci-hcd supports runtime PM, the .pm field in its pci_driver
structure should be protected by CONFIG_PM rather than
CONFIG_PM_SLEEP.

Without this change, OHCI controllers won't do runtime suspend if
system suspend or hibernation isn't enabled.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/ohci-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index 951514e..ef6782b 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -371,7 +371,7 @@ static struct pci_driver ohci_pci_driver = {
.remove =   usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver =   {
.pm =   _hcd_pci_pm_ops
},
-- 
1.8.1.2

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

[PATCH 47/93] drm/radeon: update line buffer allocation for dce4.1/5

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream.

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce4.1/5 asics.

Based on an initial fix from:
Jay Cornwall 

Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/evergreen.c  | 25 +
 drivers/gpu/drm/radeon/evergreend.h |  4 
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index eeb1aad..c7a0488 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -724,7 +724,8 @@ static u32 evergreen_line_buffer_adjust(struct 
radeon_device *rdev,
struct drm_display_mode *mode,
struct drm_display_mode *other_mode)
 {
-   u32 tmp;
+   u32 tmp, buffer_alloc, i;
+   u32 pipe_offset = radeon_crtc->crtc_id * 0x20;
/*
 * Line Buffer Setup
 * There are 3 line buffers, each one shared by 2 display controllers.
@@ -747,18 +748,34 @@ static u32 evergreen_line_buffer_adjust(struct 
radeon_device *rdev,
 * non-linked crtcs for maximum line buffer allocation.
 */
if (radeon_crtc->base.enabled && mode) {
-   if (other_mode)
+   if (other_mode) {
tmp = 0; /* 1/2 */
-   else
+   buffer_alloc = 1;
+   } else {
tmp = 2; /* whole */
-   } else
+   buffer_alloc = 2;
+   }
+   } else {
tmp = 0;
+   buffer_alloc = 0;
+   }
 
/* second controller of the pair uses second half of the lb */
if (radeon_crtc->crtc_id % 2)
tmp += 4;
WREG32(DC_LB_MEMORY_SPLIT + radeon_crtc->crtc_offset, tmp);
 
+   if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+   WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+  DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+   for (i = 0; i < rdev->usec_timeout; i++) {
+   if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset) &
+   DMIF_BUFFERS_ALLOCATED_COMPLETED)
+   break;
+   udelay(1);
+   }
+   }
+
if (radeon_crtc->base.enabled && mode) {
switch (tmp) {
case 0:
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index 0bfd0e9e..f410b4d 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -760,6 +760,10 @@
 #   define LATENCY_LOW_WATERMARK(x)   ((x) << 0)
 #   define LATENCY_HIGH_WATERMARK(x)  ((x) << 16)
 
+#definePIPE0_DMIF_BUFFER_CONTROL 0x0ca0
+#   define DMIF_BUFFERS_ALLOCATED(x)  ((x) << 0)
+#   define DMIF_BUFFERS_ALLOCATED_COMPLETED   (1 << 4)
+
 #define IH_RB_CNTL0x3e00
 #   define IH_RB_ENABLE   (1 << 0)
 #   define IH_IB_SIZE(x)  ((x) << 1) /* log2 */
-- 
1.8.1.2

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

[PATCH 05/93] HID: hidraw: correctly deallocate memory on device disconnect

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Manoj Chourasia 

commit 212a871a3934beccf43431608c27ed2e05a476ec upstream.

This changes puts the commit 4fe9f8e203f back in place
with the fixes for slab corruption because of the commit.

When a device is unplugged, wait for all processes that
have opened the device to close before deallocating the device.

This commit was solving kernel crash because of the corruption in
rb tree of vmalloc. The rootcause was the device data pointer was
geting excessed after the memory associated with hidraw was freed.

The commit 4fe9f8e203f was buggy as it was also freeing the hidraw
first and then calling delete operation on the list associated with
that hidraw leading to slab corruption.

Signed-off-by: Manoj Chourasia 
Tested-by: Peter Wu 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hidraw.c | 60 ++--
 1 file changed, 25 insertions(+), 35 deletions(-)

diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 413a731..cfe5288 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -113,7 +113,7 @@ static ssize_t hidraw_send_report(struct file *file, const 
char __user *buffer,
__u8 *buf;
int ret = 0;
 
-   if (!hidraw_table[minor]) {
+   if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
ret = -ENODEV;
goto out;
}
@@ -261,7 +261,7 @@ static int hidraw_open(struct inode *inode, struct file 
*file)
}
 
mutex_lock(_lock);
-   if (!hidraw_table[minor]) {
+   if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
err = -ENODEV;
goto out_unlock;
}
@@ -302,39 +302,38 @@ static int hidraw_fasync(int fd, struct file *file, int 
on)
return fasync_helper(fd, file, on, >fasync);
 }
 
+static void drop_ref(struct hidraw *hidraw, int exists_bit)
+{
+   if (exists_bit) {
+   hid_hw_close(hidraw->hid);
+   hidraw->exist = 0;
+   if (hidraw->open)
+   wake_up_interruptible(>wait);
+   } else {
+   --hidraw->open;
+   }
+
+   if (!hidraw->open && !hidraw->exist) {
+   device_destroy(hidraw_class, MKDEV(hidraw_major, 
hidraw->minor));
+   hidraw_table[hidraw->minor] = NULL;
+   kfree(hidraw);
+   }
+}
+
 static int hidraw_release(struct inode * inode, struct file * file)
 {
unsigned int minor = iminor(inode);
-   struct hidraw *dev;
struct hidraw_list *list = file->private_data;
-   int ret;
-   int i;
 
mutex_lock(_lock);
-   if (!hidraw_table[minor]) {
-   ret = -ENODEV;
-   goto unlock;
-   }
 
list_del(>node);
-   dev = hidraw_table[minor];
-   if (!--dev->open) {
-   if (list->hidraw->exist) {
-   hid_hw_power(dev->hid, PM_HINT_NORMAL);
-   hid_hw_close(dev->hid);
-   } else {
-   kfree(list->hidraw);
-   }
-   }
-
-   for (i = 0; i < HIDRAW_BUFFER_SIZE; ++i)
-   kfree(list->buffer[i].value);
kfree(list);
-   ret = 0;
-unlock:
-   mutex_unlock(_lock);
 
-   return ret;
+   drop_ref(hidraw_table[minor], 0);
+
+   mutex_unlock(_lock);
+   return 0;
 }
 
 static long hidraw_ioctl(struct file *file, unsigned int cmd,
@@ -539,18 +538,9 @@ void hidraw_disconnect(struct hid_device *hid)
struct hidraw *hidraw = hid->hidraw;
 
mutex_lock(_lock);
-   hidraw->exist = 0;
-
-   device_destroy(hidraw_class, MKDEV(hidraw_major, hidraw->minor));
 
-   hidraw_table[hidraw->minor] = NULL;
+   drop_ref(hidraw, 1);
 
-   if (hidraw->open) {
-   hid_hw_close(hid);
-   wake_up_interruptible(>wait);
-   } else {
-   kfree(hidraw);
-   }
mutex_unlock(_lock);
 }
 EXPORT_SYMBOL_GPL(hidraw_disconnect);
-- 
1.8.1.2

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

[PATCH 16/93] xhci-plat: Don't enable legacy PCI interrupts.

[Kamal Mostafa]

3.8.13.10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sarah Sharp 

commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 upstream.

The xHCI platform driver calls into usb_add_hcd to register the irq for
its platform device.  It does not want the xHCI generic driver to
register an interrupt for it at all.  The original code did that by
setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
enable MSI or MSI-X for a PCI host.

Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
the xHCI generic driver will attempt to register a legacy PCI interrupt
for the xHCI platform device in xhci_try_enable_msi().  This will result
in a bogus irq being registered, since the underlying device is a
platform_device, not a pci_device, and thus the pci_device->irq pointer
will be bogus.

Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
distinguish between a PCI device that can't handle MSI or MSI-X, and a
platform device that should not have its interrupts touched at all.
This quirk may be useful in the future, in case other corner cases like
this arise.

This patch should be backported to kernels as old as 3.9, that
contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
correctly enable interrupts".

Signed-off-by: Sarah Sharp 
Reported-by: Yu Y Wang 
Tested-by: Yu Y Wang 
Reviewed-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci-plat.c | 2 +-
 drivers/usb/host/xhci.c  | 7 ++-
 drivers/usb/host/xhci.h  | 1 +
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 93ad67e..6e70ce9 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -24,7 +24,7 @@ static void xhci_plat_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 * here that the generic code does not try to make a pci_dev from our
 * dev struct in order to setup MSI
 */
-   xhci->quirks |= XHCI_BROKEN_MSI;
+   xhci->quirks |= XHCI_PLAT;
 }
 
 /* called during probe() after chip reset completes */
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 661c553..99d68c8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -342,9 +342,14 @@ static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
 static int xhci_try_enable_msi(struct usb_hcd *hcd)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
-   struct pci_dev  *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
+   struct pci_dev  *pdev;
int ret;
 
+   /* The xhci platform device has set up IRQs through usb_add_hcd. */
+   if (xhci->quirks & XHCI_PLAT)
+   return 0;
+
+   pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
/*
 * Some Fresco Logic host controllers advertise MSI, but fail to
 * generate interrupts.  Don't even try to enable MSI.
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index abed254..d0dd206 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1516,6 +1516,7 @@ struct xhci_hcd {
 #define XHCI_SPURIOUS_REBOOT   (1 << 13)
 #define XHCI_COMP_MODE_QUIRK   (1 << 14)
 #define XHCI_AVOID_BEI (1 << 15)
+#define XHCI_PLAT  (1 << 16)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
-- 
1.8.1.2

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

[PATCH] LSM: ModPin LSM for module loading restrictions

[Kees Cook]

This LSM enforces that modules must all come from the same filesystem,
with the expectation that such a filesystem is backed by a read-only
device such as dm-verity or CDROM. This allows systems that have a
verified or unchanging filesystem to enforce module loading restrictions
without needing to sign the modules individually.

Signed-off-by: Kees Cook 
---
 security/Kconfig |6 ++
 security/Makefile|2 +
 security/modpin/Kconfig  |9 +++
 security/modpin/Makefile |1 +
 security/modpin/modpin.c |  197 ++
 5 files changed, 215 insertions(+)
 create mode 100644 security/modpin/Kconfig
 create mode 100644 security/modpin/Makefile
 create mode 100644 security/modpin/modpin.c

diff --git a/security/Kconfig b/security/Kconfig
index e9c6ac7..80172fd 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -121,6 +121,7 @@ source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
 source security/apparmor/Kconfig
+source security/modpin/Kconfig
 source security/yama/Kconfig
 
 source security/integrity/Kconfig
@@ -131,6 +132,7 @@ choice
default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
+   default DEFAULT_SECURITY_MODPIN if SECURITY_MODPIN
default DEFAULT_SECURITY_YAMA if SECURITY_YAMA
default DEFAULT_SECURITY_DAC
 
@@ -150,6 +152,9 @@ choice
config DEFAULT_SECURITY_APPARMOR
bool "AppArmor" if SECURITY_APPARMOR=y
 
+   config DEFAULT_SECURITY_MODPIN
+   bool "ModPin" if SECURITY_MODPIN=y
+
config DEFAULT_SECURITY_YAMA
bool "Yama" if SECURITY_YAMA=y
 
@@ -164,6 +169,7 @@ config DEFAULT_SECURITY
default "smack" if DEFAULT_SECURITY_SMACK
default "tomoyo" if DEFAULT_SECURITY_TOMOYO
default "apparmor" if DEFAULT_SECURITY_APPARMOR
+   default "modpin" if DEFAULT_SECURITY_MODPIN
default "yama" if DEFAULT_SECURITY_YAMA
default "" if DEFAULT_SECURITY_DAC
 
diff --git a/security/Makefile b/security/Makefile
index c26c81e..73d0a05 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -7,6 +7,7 @@ subdir-$(CONFIG_SECURITY_SELINUX)   += selinux
 subdir-$(CONFIG_SECURITY_SMACK)+= smack
 subdir-$(CONFIG_SECURITY_TOMOYO)+= tomoyo
 subdir-$(CONFIG_SECURITY_APPARMOR) += apparmor
+subdir-$(CONFIG_SECURITY_MODPIN)   += modpin
 subdir-$(CONFIG_SECURITY_YAMA) += yama
 
 # always enable default capabilities
@@ -22,6 +23,7 @@ obj-$(CONFIG_SECURITY_SMACK)  += smack/built-in.o
 obj-$(CONFIG_AUDIT)+= lsm_audit.o
 obj-$(CONFIG_SECURITY_TOMOYO)  += tomoyo/built-in.o
 obj-$(CONFIG_SECURITY_APPARMOR)+= apparmor/built-in.o
+obj-$(CONFIG_SECURITY_MODPIN)  += modpin/built-in.o
 obj-$(CONFIG_SECURITY_YAMA)+= yama/built-in.o
 obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o
 
diff --git a/security/modpin/Kconfig b/security/modpin/Kconfig
new file mode 100644
index 000..5be9dd5
--- /dev/null
+++ b/security/modpin/Kconfig
@@ -0,0 +1,9 @@
+config SECURITY_MODPIN
+   bool "Module filesystem origin pinning"
+   depends on SECURITY
+   help
+ Module loading will be pinned to the first filesystem used for
+ loading. Any modules that come from other filesystems will be
+ rejected. This is best used on systems without an initrd that
+ have a root filesystem backed by a read-only device such as
+ dm-verity or a CDROM.
diff --git a/security/modpin/Makefile b/security/modpin/Makefile
new file mode 100644
index 000..9080b29
--- /dev/null
+++ b/security/modpin/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SECURITY_MODPIN) += modpin.o
diff --git a/security/modpin/modpin.c b/security/modpin/modpin.c
new file mode 100644
index 000..107b4d8
--- /dev/null
+++ b/security/modpin/modpin.c
@@ -0,0 +1,197 @@
+/*
+ * Module Pinning Security Module
+ *
+ * Copyright 2011-2013 Google Inc.
+ *
+ * Authors:
+ *  Kees Cook   
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) "ModPin LSM: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void report_load_module(struct path *path, char *operation)
+{
+   char *alloced = NULL;
+   char *pathname; /* Pointer to either static string or "alloced". */
+
+   if (!path)
+   

Re: Drivers: scsi: FLUSH timeout

[Greg KH]

On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
> The SD_FLUSH_TIMEOUT value is currently hardcoded.

Hardcoded where?  Please, more context.

> On our cloud, we sometimes hit this timeout. I was wondering if we
> could make this a module parameter. If this is acceptable, I can send
> you a patch for this.

A module parameter don't make sense for a per-device value, does it?

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/