RE: [PATCH 0/2] Update device tree binding document for pwm-tiehrpwm & pwm-tiecap

2013-04-07 Thread Philip, Avinash
Thierry,

On Mon, Mar 25, 2013 at 12:34:51, Philip, Avinash wrote:
> Update device tree document of pwm-tiehrpwm & pwm-tiecap in order to reflect 
> the
> usage of similar modules in both da850 and am33xx platforms.

Can you accept both documentation update patches with Peter Korsgaard's Ack.

Thanks
Avinash
> 
> Philip Avinash (2):
>   pwm: pwm-tiecap: Update device-tree binding document
>   pwm: pwm-tiehrpwm: Update device-tree binding document
> 
>  .../devicetree/bindings/pwm/pwm-tiecap.txt |   12 ++--
>  .../devicetree/bindings/pwm/pwm-tiehrpwm.txt   |   12 ++--
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 

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


Re: [PATCH 1/2] hfsplus: add error propagation to __hfsplus_ext_write_extent()

2013-04-07 Thread Vyacheslav Dubeyko
Hi Alexey,

On Mon, 2013-04-08 at 01:21 +0400, Alexey Khoroshilov wrote:
> __hfsplus_ext_write_extent() suppresses errors coming from hfs_brec_find().
> The patch implements error code propagation.
> 

Please, prepare a single patch set for all your changes in HFS and HFS+. These 
changes are related to each other, so, it makes sense in one patch set.

Thanks,
Vyacheslav Dubeyko.

> Signed-off-by: Alexey Khoroshilov 
> ---
>  fs/hfsplus/extents.c |   21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c
> index a94f0f7..fed73f7 100644
> --- a/fs/hfsplus/extents.c
> +++ b/fs/hfsplus/extents.c
> @@ -83,7 +83,7 @@ static u32 hfsplus_ext_lastblock(struct hfsplus_extent *ext)
>   return be32_to_cpu(ext->start_block) + be32_to_cpu(ext->block_count);
>  }
>  
> -static void __hfsplus_ext_write_extent(struct inode *inode,
> +static int __hfsplus_ext_write_extent(struct inode *inode,
>   struct hfs_find_data *fd)
>  {
>   struct hfsplus_inode_info *hip = HFSPLUS_I(inode);
> @@ -98,13 +98,13 @@ static void __hfsplus_ext_write_extent(struct inode 
> *inode,
>   res = hfs_brec_find(fd, hfs_find_rec_by_key);
>   if (hip->extent_state & HFSPLUS_EXT_NEW) {
>   if (res != -ENOENT)
> - return;
> + return res;
>   hfs_brec_insert(fd, hip->cached_extents,
>   sizeof(hfsplus_extent_rec));
>   hip->extent_state &= ~(HFSPLUS_EXT_DIRTY | HFSPLUS_EXT_NEW);
>   } else {
>   if (res)
> - return;
> + return res;
>   hfs_bnode_write(fd->bnode, hip->cached_extents,
>   fd->entryoffset, fd->entrylength);
>   hip->extent_state &= ~HFSPLUS_EXT_DIRTY;
> @@ -117,11 +117,13 @@ static void __hfsplus_ext_write_extent(struct inode 
> *inode,
>* to explicily mark the inode dirty, too.
>*/
>   set_bit(HFSPLUS_I_EXT_DIRTY, >flags);
> +
> + return 0;
>  }
>  
>  static int hfsplus_ext_write_extent_locked(struct inode *inode)
>  {
> - int res;
> + int res = 0;
>  
>   if (HFSPLUS_I(inode)->extent_state & HFSPLUS_EXT_DIRTY) {
>   struct hfs_find_data fd;
> @@ -129,10 +131,10 @@ static int hfsplus_ext_write_extent_locked(struct inode 
> *inode)
>   res = hfs_find_init(HFSPLUS_SB(inode->i_sb)->ext_tree, );
>   if (res)
>   return res;
> - __hfsplus_ext_write_extent(inode, );
> + res = __hfsplus_ext_write_extent(inode, );
>   hfs_find_exit();
>   }
> - return 0;
> + return res;
>  }
>  
>  int hfsplus_ext_write_extent(struct inode *inode)
> @@ -175,8 +177,11 @@ static inline int __hfsplus_ext_cache_extent(struct 
> hfs_find_data *fd,
>  
>   WARN_ON(!mutex_is_locked(>extents_lock));
>  
> - if (hip->extent_state & HFSPLUS_EXT_DIRTY)
> - __hfsplus_ext_write_extent(inode, fd);
> + if (hip->extent_state & HFSPLUS_EXT_DIRTY) {
> + res = __hfsplus_ext_write_extent(inode, fd);
> + if (res)
> + return res;
> + }
>  
>   res = __hfsplus_ext_read_extent(fd, hip->cached_extents, inode->i_ino,
>   block, HFSPLUS_IS_RSRC(inode) ?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next] virtio_console: make local symbols static

2013-04-07 Thread Amit Shah
On (Sat) 06 Apr 2013 [11:52:07], Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Those symbols only used within this file, and should be static.
> 
> Signed-off-by: Wei Yongjun 

Acked-by: Amit Shah 

Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: Add hook for kicking in kdump path

2013-04-07 Thread Dave Young
On 04/06/2013 04:16 AM, Don Zickus wrote:
> A common problem with kdump is that during the boot up of the
> second kernel, the hardware watchdog times out and reboots the
> machine before a vmcore can be captured.
> 
> Instead of tellling customers to disable their hardware watchdog
> timers, I hacked up a hook to put in the kdump path that provides
> one last kick before jumping into the second kernel.
> 
> The assumption is the watchdog timeout is at least 10-30 seconds
> long, enough to get the second kernel to userspace to kick the watchdog
> again, if needed.

For kdump kernel some devices need to reset, this might increase the
boot time, it's not so reliable for the 10-30s for us to kicking the
watchdog.

Could we have another option to disable/stop the watchdog while panic
happens? Ie. add a kernel cmdline panic_stop_wd=<0|1> for 1st kernel, if
it's set to 1, then just stop the watchdog or we can kick the watchdog
like what you do in this patch. Of course stopping watchdog should be
lockless as well..

> 
> Of course kdump is usually executed on a panic path, so grabbing the
> watchdog mutexes to communicate with the hardware won't work.  For now,
> I do everything locklessly.
> 
> I can attempt a 'mutex_trylock' but not sure what to do in the failure
> case?  spin up to a second?
> 
> This patch is more of a proof of concept right now.  Hopefully feedback
> will help solve this problem better.
> 
> I have tested this with a machine using iTCO_wdt and the 'watchdog' app.
> The extra kicked happened as expected.
> 
> Signed-off-by: Don Zickus 
> ---
>  drivers/watchdog/watchdog_dev.c |   35 +++
>  include/linux/watchdog.h|7 +++
>  kernel/kexec.c  |6 ++
>  3 files changed, 48 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 08b48bb..6393572 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -84,6 +84,41 @@ out_ping:
>  }
>  
>  /*
> + *   watchdog_kick_for_kdump: kick the watchdog in the kdump path
> + *
> + *   The kdump path needs time to reboot the kernel back into
> + *   userspace.  This window is big enough the hardware watchdog
> + *   may come in and reboot the box.  This hook gives the watchdog
> + *   one final kick to get kdump over the hump.
> + *
> + *   We don't know what devices are open, so just use the legacy
> + *   interface for now.  We have to do this locklessly as we can
> + *   not wait.
> + */
> +
> +void watchdog_kick_for_kdump(void)
> +{
> + struct watchdog_device *wddev = old_wdd;
> +
> + /* FIXME - Perhaps use a mutex_trylock? */
> +
> + if (!wddev)
> + return;
> +
> + if (test_bit(WDOG_UNREGISTERED, >status))
> + return;
> +
> + if (!watchdog_active(wddev))
> + return;
> +
> + if (wddev->ops->ping)
> + wddev->ops->ping(wddev);  /* ping the watchdog */
> + else
> + wddev->ops->start(wddev); /* restart watchdog */
> +}
> +EXPORT_SYMBOL_GPL(watchdog_kick_for_kdump);
> +
> +/*
>   *   watchdog_start: wrapper to start the watchdog.
>   *   @wddev: the watchdog device to start
>   *
> diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
> index 2a3038e..5dff975 100644
> --- a/include/linux/watchdog.h
> +++ b/include/linux/watchdog.h
> @@ -142,4 +142,11 @@ extern int watchdog_init_timeout(struct watchdog_device 
> *wdd,
>  extern int watchdog_register_device(struct watchdog_device *);
>  extern void watchdog_unregister_device(struct watchdog_device *);
>  
> +#ifdef CONFIG_WATCHDOG_CORE
> +/* drivers/watchdog/watchdog_dev.c */
> +extern void watchdog_kick_for_kdump(void);
> +#else
> +static inline void watchdog_kick_for_kdump(void) { };
> +#endif
> +
>  #endif  /* ifndef _LINUX_WATCHDOG_H */
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index bddd3d7..ced7ccd 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1094,6 +1095,11 @@ void crash_kexec(struct pt_regs *regs)
>   if (kexec_crash_image) {
>   struct pt_regs fixed_regs;
>  
> + /*
> +  * Give panic path a chance to do its post processing
> +  */
> + watchdog_kick_for_kdump();
> +
>   crash_setup_regs(_regs, regs);
>   crash_save_vmcoreinfo();
>   machine_crash_shutdown(_regs);
> 


-- 
Thanks
Dave


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


Re: [PATCH v8 1/2] ARM: davinci: dm365: add support for v4l2 video display

2013-04-07 Thread Prabhakar Lad
Sekhar,

On Thu, Apr 4, 2013 at 3:03 PM, Sekhar Nori  wrote:
> On 4/2/2013 5:24 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar 
>>
>> Create platform devices for various video modules like venc,osd,
>> vpbe and v4l2 driver for dm365.
>>
>> Signed-off-by: Lad, Prabhakar 
>
> Minor nits below:
>
>> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
>> index c61dd94..786c860 100644
>> --- a/arch/arm/mach-davinci/dm365.c
>> +++ b/arch/arm/mach-davinci/dm365.c
>> @@ -40,10 +40,14 @@
>>
>>  #define DM365_REF_FREQ   2400/* 24 MHz on the DM365 
>> EVM */
>>
>> +#define DM365_RTC_BASE   0x01c69000
>> +
>>  /* Base of key scan register bank */
>>  #define DM365_KEYSCAN_BASE   0x01c69400
>>
>> -#define DM365_RTC_BASE   0x01c69000
>> +#define DM365_OSD_BASE   0x01c71c00
>> +
>> +#define DM365_VENC_BASE  0x01c71e00
>>
>>  #define DAVINCI_DM365_VC_BASE0x01d0c000
>
> No need of empty lines between these definitions. While at it you can
> also remove the useless comment "/* Base of key scan register bank */"
>
OK

>> +static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
>> + int field)
>> +{
>> + switch (if_type) {
>> + case V4L2_MBUS_FMT_SGRBG8_1X8:
>> + davinci_cfg_reg(DM365_VOUT_FIELD_G81);
>> + davinci_cfg_reg(DM365_VOUT_COUTL_EN);
>> + davinci_cfg_reg(DM365_VOUT_COUTH_EN);
>> + break;
>> +
>
> No need of these empty lines after 'break'. Here and other places below.
>
OK

> The patch looks good overall though so you can fix the nits and add:
>
> Acked-by: Sekhar Nori 

Thanks.

Regards,
--Prabhakar

>
> Thanks,
> Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR

2013-04-07 Thread Jaehoon Chung
Looks good to me.

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 04/05/2013 05:18 PM, Jaehoon Chung wrote:
> Hi Doug,
> 
> You're right..it's something wrong.
> Actually i didn't test with your patch, but your commit message is reasonable.
> 
> I will check until next week after test.
> 
> Best Regards,
> Jaehoon Chung
> 
> On 03/27/2013 03:06 AM, Doug Anderson wrote:
>> Jaehoon,
>>
>> On Mon, Mar 18, 2013 at 3:21 AM, Jaehoon Chung  
>> wrote:
>>> Hi Doug,
>>>
>>> Great..i have found the problem like this.
>>> I will check your patch..and share the result.
>>
>> Did you have any time to check this patch?
>>
>> Thanks!
>>
>> -Doug
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Convert compat_sys_sysinfo to COMPAT_SYSCALL_DEFINE

2013-04-07 Thread Stephen Rothwell

Signed-off-by: Stephen Rothwell 
---
 kernel/timer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

This depends on my previous patch "Make do_sysinfo() static".

diff --git a/kernel/timer.c b/kernel/timer.c
index 06b3245..f0e6588 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1661,8 +1661,7 @@ struct compat_sysinfo {
char _f[20-2*sizeof(u32)-sizeof(int)];
 };
 
-asmlinkage long
-compat_sys_sysinfo(struct compat_sysinfo __user *info)
+COMPAT_SYSCALL_DEFINE1(sysinfo, struct compat_sysinfo __user *, info)
 {
struct sysinfo s;
 
-- 
1.8.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpjZqFC94iWc.pgp
Description: PGP signature


Re: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq

2013-04-07 Thread Viresh Kumar
On 5 April 2013 12:36, Viresh Kumar  wrote:
> On 5 April 2013 12:18, Kukjin Kim  wrote:
>> Basically, this moving looks good to me, but should be re-worked based on
>> for-next of samsung tree because this touches too many samsung stuff so this
>> should be sent to upstream via samsung tree.
>
> Hmm... Its already applied in Rafael's tree. But it doesn't mean that
> it can't be
> moved to your tree if there is a issue.
>
> What tree/branch? I used:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next
>
>> Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
>> error: patch failed: arch/arm/Kconfig:2166
>> error: arch/arm/Kconfig: patch does not apply
>
> above two are obvious as you haven't applied other patches in this series.
>
>> error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28
>> error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply
>> error: patch failed: arch/arm/mach-s3c24xx/Makefile:17
>> error: arch/arm/mach-s3c24xx/Makefile: patch does not apply
>> error: patch failed: drivers/cpufreq/Makefile:63
>> error: drivers/cpufreq/Makefile: patch does not apply
>
> Same here.
>
>> error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index
>
> I can still see it in for-next.
>
> Attached is my patch based of your for-next

Kukjin,

As Rafael has already dropped it, can you apply it at your end and make sure
it doesn't miss the merge cycle?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] Gaurantee spinlocks implicit barrier for !PREEMPT_COUNT

2013-04-07 Thread Linus Torvalds
On Sun, Apr 7, 2013 at 9:20 PM, Vineet Gupta  wrote:
>
> Would you be OK if I send the single patch to ARC by email (for 3.9-rc7) or 
> you'd
> rather have the pull request.

I got distracted by thinking about user-accesses vs preemption, but
yes, sending the ARC patch to fix things by email as a plain patch is
fine.

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


Re: [PATCH] [PATCH] Gaurantee spinlocks implicit barrier for !PREEMPT_COUNT

2013-04-07 Thread Linus Torvalds
On Sun, Apr 7, 2013 at 9:20 PM, Vineet Gupta  wrote:
>
> Christian had already proposed that change - only I was reluctant to take it 
> - as
> local_irq_* is used heavily in a configuration of ARC700 linux where (!SMP) 
> cpu
> doesn't support load-locked/store-conditional instructions - hence atomic 
> R-M-W
> sequences need those routines. Adding a mem clobber would lead to pathetic
> generated code hence the reason it was likely removed by me at some point in 
> time.

Umm. The irq instructions absolutely *HAVE* to have the barriers. And
yes, the R-M-W instructions (if they are protected by them) obviously
need to have the load and the store inside the spinlocked region.

> Also I'd thought that given that barriers are already present in PREEMPT_COUNT
> variant of preempt_* macros we might as well add them to !PREEMPT_COUNT ones.

That's absolutely insane. It's insane for two reasons:

 - it's not SUFFICIENT. Any user of irq-safety needs the loads and
stores to stay inside the irq-safe region, and the preempt macros have
absolutely nothing to do with that.

 - it's POINTLESS and WRONG. If you run on UP, and have preemption
disabled, then there is no reason for a barrier in the preempt code,
since moving code around them doesn't matter - nothing is ever going
to preempt that.

The thing is, the irq disable/enable sequence absolutely has to have a
memory barrier in it, because if the compiler moves a load outside of
the irq-protected region, then that is a bug. Now, if you want to play
games with your atomics and do them with handcoded asm, go right
ahead, but that really isn't an argument for getting everything else
wrong.

That said, thinking about barriers and preemption made me realize that
we do have a potential issue between: (a) non-preemption UP kernel
(with no barriers in the preempt_enable/disable()) and (b)
architectures that use inline asm without a memory clobber for
get_user/put_user(). That includes x86.

The reason is that I could imagine code like

if (get_user(val, addr))
return -EFAULT;
preempt_disable();
... do something percpu ..
preempt_enable();

and it turns out that for non-preempt UP, we don't tell the compiler
anywhere that it can't move the get_user past the preempt_disable. But
the get_user() can cause a preemption point because of a page fault,
obviously.

I suspect that the best way to fix this ends up relying on the gcc
"asm volatile" rules, and make the rule be that:
 - preempt_disable/enable have to generate an asm volatile() string
(preferably just a ASM comment saying "preempt disable/enable")
 - get_user/put_user doesn't need to add a memory clobber, but needs
to be done with an asm volatile too.

Then the gcc "no reordering of volatile asms" should make the above be
ok, without having to add an actual compiler memory barrier.

Ingo? Peter? I'm not sure anybody really uses UP+no-preempt on x86,
but it does seem to be a bug.. Comments?

But the irq disable/enable sequences definitely need the memory
clobber. Because caching memory that could be changed by an interrupt
in registers is not good.

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: linux-next: build failure after merge of the mfd tree

2013-04-07 Thread Alexander Shiyan
Hello.

> After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/regulator/anatop-regulator.c: In function 'anatop_regulator_probe':
> drivers/regulator/anatop-regulator.c:134:2: error: implicit declaration of 
> function 'of_get_parent' [-Werror=implicit-function-declaration]
> 
> Caused by commit 5ab3a89a741f ("mfd: syscon: Add non-DT support").
> 
> I have used the mfd tree from next-20130405 for today.

This means that we do not have empty declarations for the
of_xx functions in linux/of.h for !CONFIG_OF.
OK to declare these functions or any other opinions?

---


[PATCH v2] Make do_sysinfo() static

2013-04-07 Thread Stephen Rothwell
The only use outside of kernel/timer.c was in kernel/compat.c, so move
compat_sys_sysinfo() next to sys_sysinfo() in kernel/timer.c.

Signed-off-by: Stephen Rothwell 
---
 include/linux/kernel.h |  2 --
 kernel/compat.c| 65 --
 kernel/timer.c | 70 +-
 3 files changed, 69 insertions(+), 68 deletions(-)

v2:  I am so embarrassed that I forgot to include linux/compat.h in
kernel/timer.c :-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 79fdd80..a8b579c 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -734,6 +734,4 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
 # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
 #endif
 
-extern int do_sysinfo(struct sysinfo *info);
-
 #endif
diff --git a/kernel/compat.c b/kernel/compat.c
index 19971d8..1e8f145 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -1138,71 +1138,6 @@ asmlinkage long compat_sys_migrate_pages(compat_pid_t 
pid,
 }
 #endif
 
-struct compat_sysinfo {
-   s32 uptime;
-   u32 loads[3];
-   u32 totalram;
-   u32 freeram;
-   u32 sharedram;
-   u32 bufferram;
-   u32 totalswap;
-   u32 freeswap;
-   u16 procs;
-   u16 pad;
-   u32 totalhigh;
-   u32 freehigh;
-   u32 mem_unit;
-   char _f[20-2*sizeof(u32)-sizeof(int)];
-};
-
-asmlinkage long
-compat_sys_sysinfo(struct compat_sysinfo __user *info)
-{
-   struct sysinfo s;
-
-   do_sysinfo();
-
-   /* Check to see if any memory value is too large for 32-bit and scale
-*  down if needed
-*/
-   if ((s.totalram >> 32) || (s.totalswap >> 32)) {
-   int bitcount = 0;
-
-   while (s.mem_unit < PAGE_SIZE) {
-   s.mem_unit <<= 1;
-   bitcount++;
-   }
-
-   s.totalram >>= bitcount;
-   s.freeram >>= bitcount;
-   s.sharedram >>= bitcount;
-   s.bufferram >>= bitcount;
-   s.totalswap >>= bitcount;
-   s.freeswap >>= bitcount;
-   s.totalhigh >>= bitcount;
-   s.freehigh >>= bitcount;
-   }
-
-   if (!access_ok(VERIFY_WRITE, info, sizeof(struct compat_sysinfo)) ||
-   __put_user (s.uptime, >uptime) ||
-   __put_user (s.loads[0], >loads[0]) ||
-   __put_user (s.loads[1], >loads[1]) ||
-   __put_user (s.loads[2], >loads[2]) ||
-   __put_user (s.totalram, >totalram) ||
-   __put_user (s.freeram, >freeram) ||
-   __put_user (s.sharedram, >sharedram) ||
-   __put_user (s.bufferram, >bufferram) ||
-   __put_user (s.totalswap, >totalswap) ||
-   __put_user (s.freeswap, >freeswap) ||
-   __put_user (s.procs, >procs) ||
-   __put_user (s.totalhigh, >totalhigh) ||
-   __put_user (s.freehigh, >freehigh) ||
-   __put_user (s.mem_unit, >mem_unit))
-   return -EFAULT;
-
-   return 0;
-}
-
 COMPAT_SYSCALL_DEFINE2(sched_rr_get_interval,
   compat_pid_t, pid,
   struct compat_timespec __user *, interval)
diff --git a/kernel/timer.c b/kernel/timer.c
index dbf7a78..06b3245 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1567,7 +1568,7 @@ SYSCALL_DEFINE0(gettid)
  * do_sysinfo - fill in sysinfo struct
  * @info: pointer to buffer to fill
  */
-int do_sysinfo(struct sysinfo *info)
+static int do_sysinfo(struct sysinfo *info)
 {
unsigned long mem_total, sav_total;
unsigned int mem_unit, bitcount;
@@ -1642,6 +1643,73 @@ SYSCALL_DEFINE1(sysinfo, struct sysinfo __user *, info)
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+struct compat_sysinfo {
+   s32 uptime;
+   u32 loads[3];
+   u32 totalram;
+   u32 freeram;
+   u32 sharedram;
+   u32 bufferram;
+   u32 totalswap;
+   u32 freeswap;
+   u16 procs;
+   u16 pad;
+   u32 totalhigh;
+   u32 freehigh;
+   u32 mem_unit;
+   char _f[20-2*sizeof(u32)-sizeof(int)];
+};
+
+asmlinkage long
+compat_sys_sysinfo(struct compat_sysinfo __user *info)
+{
+   struct sysinfo s;
+
+   do_sysinfo();
+
+   /* Check to see if any memory value is too large for 32-bit and scale
+*  down if needed
+*/
+   if ((s.totalram >> 32) || (s.totalswap >> 32)) {
+   int bitcount = 0;
+
+   while (s.mem_unit < PAGE_SIZE) {
+   s.mem_unit <<= 1;
+   bitcount++;
+   }
+
+   s.totalram >>= bitcount;
+   s.freeram >>= bitcount;
+   s.sharedram >>= bitcount;
+   s.bufferram >>= bitcount;
+   s.totalswap >>= bitcount;
+   s.freeswap >>= bitcount;
+   s.totalhigh >>= bitcount;

linux-next: manual merge of the omap_dss2 tree with Linus' tree

2013-04-07 Thread Stephen Rothwell
Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/fbmon.c between commit 477fc03f5baa ("fbmon: use
VESA_DMT_VSYNC_HIGH to fix typo") from Linus' tree and commit
06a3307975aa ("videomode: combine videomode dmt_flags and data_flags")
from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

diff --cc drivers/video/fbmon.c
index 7f67099,e5cc2fd..000
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@@ -1398,13 -1398,13 +1398,13 @@@ int fb_videomode_from_videomode(const s
  
fbmode->sync = 0;
fbmode->vmode = 0;
-   if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+   if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
-   if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
 -  if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH)
++  if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH)
fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
-   if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+   if (vm->flags & DISPLAY_FLAGS_INTERLACED)
fbmode->vmode |= FB_VMODE_INTERLACED;
-   if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+   if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
fbmode->vmode |= FB_VMODE_DOUBLE;
fbmode->flag = 0;
  
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpIXnP9EigFA.pgp
Description: PGP signature


Re: [PATCH] Add non-zero module sections to sysfs

2013-04-07 Thread Rusty Russell
Philip Kranz  writes:
> Hello.
>
> On Fri, Apr 05, 2013 at 12:07:15PM +0200, James Bottomley wrote:
>> Just so you know: this isn't a parisc specific problem.  Gcc produces
>> duplicate section names under various circumstances, but the one that
>> bites us is -ffunction-sections.  Note that there are proposals to use
>> -ffunction-sections on all architectures (so we can garbage collect
>> unused functions) in which case you'll induce the bug identified in
>> 35dead4235e2b67da7275b4122fed37099c2f462 on every architecture
>
> I am not able to produce an object file with duplicate section names
> using gcc on x86. Even with -ffunction-sections, every section gets a
> unique name. Is this architecture-specific behaviour of gcc?

Good point.  ld -r will collapse them into the same section (since gcc
produces them they have to have the same section attributes).

You can do it with --unique, but no arch uses that.  PARISC has a
platform-specific toolchain hack which does that for .text sections.
(Thanks to Alan Modra for that clue...)

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Make information about modules available to kgdb.

2013-04-07 Thread Rusty Russell
Greg KH  writes:
> On Sat, Apr 06, 2013 at 03:00:55PM +0200, Sebastian Wankerl wrote:
>> From: Philip Kranz 
>> 
>> To be able to properly debug kernel modules kgbd needs to know all SHF_ALLOC
>> sections of the module. This patch add an array of those sections to struct
>> module. One cannot use sysfs since it does not contain all sections needed.
>
> Why not just add those sections to sysfs so that everyone can see them?

That's what we're going to do, but it breaks PARISC.  So we're debating
the exact method with James.

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


Linux 3.9-rc6

2013-04-07 Thread Linus Torvalds
Things seem to be on track, and it's been a mostly boring week. Lots
of small fixes, a few reverts. Networking, some small arch fixes (arm,
mips, s390, alpha, tile, x86), drivers, minor filesystem updates
(gfs2, ext4, tiny reiserfs xattr fix). Nothing really exciting stands
out, I think the appended ShortLog gives a good overview for people
who want to wallow in the details..

Things seem to be on track, which means that unless something comes
up, rc7 will probably be the last rc as usual,

Linus


---

Aaro Koskinen (1):
  ARM: OMAP1: fix USB host on 1710

Adam Jackson (1):
  drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

Akinobu Mita (1):
  GFS2: use memchr_inv

Alex Shi (1):
  cpuidle / ACPI: recover percpu ACPI processor cstate

Alexander Clouter (2):
  arm: orion5x: fix orion5x.dtsi gpio parameters
  arm: orion5x: correct IRQ used in dtsi for mv_cesa

Alexey Klimov (2):
  HID: fix Masterkit MA901 hid quirks
  media: radio-ma901: return ENODEV in probe if usb_device doesn't match

Amit Shah (2):
  virtio: console: rename cvq_lock to c_ivq_lock
  virtio: console: add locking around c_ovq operations

Anatol Pomozov (1):
  loop: prevent bdev freeing while device in use

Anatolij Gustschin (1):
  spi/mpc512x-psc: optionally keep PSC SS asserted across xfer segmensts

Andrew Honig (1):
  KVM: Allow cross page reads and writes from cached translations.

Artem Bityutskiy (1):
  UBIFS: make space fixup work in the remount case

Avinash Patil (1):
  mwifiex: reset skb->data after processing PCIe sleep confirm cmd respose

Axel Lin (1):
  ASoC: si476x: Add missing break for SNDRV_PCM_FORMAT_S8 switch case

Balakumaran Kannan (1):
  net IPv6 : Fix broken IPv6 routing table after loopback down-up

Ben Greear (1):
  mac80211: Don't restart sta-timer if not associated.

Ben Hutchings (1):
  MIPS: Add dependencies for HAVE_ARCH_TRANSPARENT_HUGEPAGE

Benjamin Tissoires (1):
  HID: magicmouse: fix race between input_register() and probe()

Bjorn Helgaas (1):
  Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"

Bob Peterson (1):
  GFS2: Issue discards in 512b sectors

Borislav Petkov (1):
  cpufreq: Correct header guards typo

Bryan Freed (1):
  spi: Unlock a spinlock before calling into the controller driver.

Catalin Marinas (1):
  ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181
(TLBI/DSB operations)

Chris Metcalf (1):
  tile: expect new initramfs name from hypervisor file system

Christoph Paasch (3):
  e1000: ethtool: Add missing dma_mapping_error-call in
e1000_setup_desc_rings
  ixgb: Add missing dma_mapping_error-call in ixgb_alloc_rx_buffers
  e1000e: Add missing dma_mapping_error-call in e1000_alloc_jumbo_rx_buffers

Colin Ian King (1):
  iwlegacy: 4965-rs: avoid null pointer dereference error

Dan Williams (1):
  libertas: drop maintainership

Daniel Vetter (2):
  drm/i915: duct-tape locking when eDP init fails
  drm: don't unlock in the addfb error paths

Darrick J. Wong (1):
  dm cache: fix writes to cache device in writethrough mode

David Daney (2):
  MIPS: Fix logic errors in bitops.c
  MIPS: Unbreak function tracer for 64-bit kernel.

David Henningsson (1):
  ALSA: hda - fix typo in proc output

David Howells (1):
  Fix breakage in MIPS siginfo handling

David Teigland (1):
  GFS2: use kmalloc for lvb bitmap

Deng-Cheng Zhu (1):
  MIPS: Fix ISA level which causes secondary cache init bypassing and more

Dimitris Papastamos (1):
  regmap: Initialize `map->debugfs' before regcache

Dmitry Kravkov (1):
  line up comment for ndo_bridge_getlink

Emmanuel Grumbach (3):
  iwlwifi: fix length check in multi-TB HCMD
  iwlwifi: set rfkill in internal state of the transport
  iwlwifi: dvm: don't send HCMD in restart flow

Eric Dumazet (2):
  aoe: reserve enough headroom on skbs
  net: add a synchronize_net() in netdev_rx_handler_unregister()

Eric Hutter (1):
  ARM: kirkwood: Fix chip-delay for GoFlex Net

Eric W. Biederman (2):
  Revert "af_unix: dont send SCM_CREDENTIAL when dest socket is NULL"
  af_unix: If we don't care about credentials coallesce all messages

EunBong Song (1):
  MIPS: Fix build error cavium-octeon without CONFIG_SMP

Florian Fainelli (1):
  MIPS: Fix code generation for non-DSP capable CPUs

Frank Li (1):
  enet: fec: fix fail resume from suspend state

Gabor Juhos (1):
  MIPS: Use CONFIG_CPU_MIPSR2 in csum_partial.S

Gabriel Fernandez (1):
  gpio: stmpe: pass DT node to irqdomain

Gao feng (1):
  netfilter: reset nf_trace in nf_reset

Girish K S (1):
  spi/s3c64xx: modified error interrupt handling and init

Grazvydas Ignotas (1):
  ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb

Gregory CLEMENT (1):
  arm: mvebu: Use local interrupt only for the timer 0

H Hartley Sweeten 

Re: [PATCH] [PATCH] Gaurantee spinlocks implicit barrier for !PREEMPT_COUNT

2013-04-07 Thread Vineet Gupta
Hi Linus,

On 04/06/2013 09:43 PM, Linus Torvalds wrote:
> This is all *COMPLETELY* wrong.
>
> Neither the normal preempt macros, nor the plain spinlocks, should
> protect anything at all against interrupts.
>
> The real protection should come from the  spin_lock_irqsave() in
> lock_timer_base(), not from spinlocks, and not from preemption.
>
> It sounds like ARC is completely buggered, and hasn't made the irq
> disable be a compiler barrier. That's an ARC bug, and it's a big one,
> and can affect a lot more than just the timers.
>
> So the real fix is to add a "memory" clobber to
> arch_local_irq_save/restore() and friends, so that the compiler
> doesn't get to cache memory state from the irq-enabled region into the
> irq-disabled one.
>
> Fix ARC, don't try to blame generic code. You should have asked
> yourself why only ARC saw this bug, when the code apparently works
> fine for everybody else!
>
>Linus

Christian had already proposed that change - only I was reluctant to take it - 
as
local_irq_* is used heavily in a configuration of ARC700 linux where (!SMP) cpu
doesn't support load-locked/store-conditional instructions - hence atomic R-M-W
sequences need those routines. Adding a mem clobber would lead to pathetic
generated code hence the reason it was likely removed by me at some point in 
time.

Also I'd thought that given that barriers are already present in PREEMPT_COUNT
variant of preempt_* macros we might as well add them to !PREEMPT_COUNT ones.

But thinking about it more - you are right (as you always are) - the situation I
saw with timers code, could very well show up with vanilla 
local_irq_save/restore
when a piece of code races with itself (specially for our mostly !SMP configs).
Would you be OK if I send the single patch to ARC by email (for 3.9-rc7) or 
you'd
rather have the pull request.

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


linux-next: build failure after merge of the mfd tree

2013-04-07 Thread Stephen Rothwell
Hi Samuel,

After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/regulator/anatop-regulator.c: In function 'anatop_regulator_probe':
drivers/regulator/anatop-regulator.c:134:2: error: implicit declaration of 
function 'of_get_parent' [-Werror=implicit-function-declaration]

Caused by commit 5ab3a89a741f ("mfd: syscon: Add non-DT support").

I have used the mfd tree from next-20130405 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp5qbf1Qgtuh.pgp
Description: PGP signature


Re: [patch v7 20/21] sched: don't do power balance on share cpu power domain

2013-04-07 Thread Alex Shi
On 04/08/2013 11:25 AM, Preeti U Murthy wrote:
> Hi Alex,
> 
> I am sorry I overlooked the changes you have made to the power
> scheduling policies.Now you have just two : performance and powersave.
> 
> Hence you can ignore my below comments.But if you use group->capacity
> instead of group->weight for threshold,like you did for balance policy
> in your version5 of this patchset, dont you think the below patch can be
> avoided? group->capacity being the threshold will automatically ensure
> that you dont pack onto domains that share cpu power.


this patch is different from balance policy, the powersave still try to
move 2 busy tasks into one cpu core on Intel cpu. It is just don't keep
packing in cpu core, like if there are 2 half busy tasks in one cpu
core, with this patch, each of SMT thread has one half busy task,
without this patch, 2 half busy task are packed into one thread.

The removed balance policy just pack one busy task per cpu core.  Yes,
the 'balance' policy has its meaning. but that is different.

-- 
Thanks Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel: trace: ftrace: strncpy, using strlcpy instead of strncpy

2013-04-07 Thread Chen Gang

  for NUL terminated string, need always set '\0' at the end.

Signed-off-by: Chen Gang 
---
 kernel/trace/ftrace.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index dfd33f0..fa984b7 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3492,14 +3492,14 @@ static char ftrace_filter_buf[FTRACE_FILTER_SIZE] 
__initdata;
 
 static int __init set_ftrace_notrace(char *str)
 {
-   strncpy(ftrace_notrace_buf, str, FTRACE_FILTER_SIZE);
+   strlcpy(ftrace_notrace_buf, str, FTRACE_FILTER_SIZE);
return 1;
 }
 __setup("ftrace_notrace=", set_ftrace_notrace);
 
 static int __init set_ftrace_filter(char *str)
 {
-   strncpy(ftrace_filter_buf, str, FTRACE_FILTER_SIZE);
+   strlcpy(ftrace_filter_buf, str, FTRACE_FILTER_SIZE);
return 1;
 }
 __setup("ftrace_filter=", set_ftrace_filter);
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: MT - handle semi-mt devices in core

2013-04-07 Thread Dmitry Torokhov
On Sun, Apr 07, 2013 at 09:41:32PM +0200, Henrik Rydberg wrote:
> Most semi-mt drivers use the slots in a manual way, but really only
> need to treat the finger count manually. With this patch, a semi-mt
> driver may use the input-mt core for everything else.
> 
> Signed-off-by: Henrik Rydberg 

Applied, thank you Henrik.

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


[PATCH] kernel: trace: strncpy, using strlcpy instead of strncpy

2013-04-07 Thread Chen Gang

  for NUL terminated string, need always set '\0' at the end.

Signed-off-by: Chen Gang 
---
 kernel/trace/trace.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 829b2be..07860b9 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -125,7 +125,7 @@ static bool allocate_snapshot;
 
 static int __init set_cmdline_ftrace(char *str)
 {
-   strncpy(bootup_tracer_buf, str, MAX_TRACER_SIZE);
+   strlcpy(bootup_tracer_buf, str, MAX_TRACER_SIZE);
default_bootup_tracer = bootup_tracer_buf;
/* We are using ftrace early, expand it */
ring_buffer_expanded = true;
@@ -164,7 +164,7 @@ static char *trace_boot_options __initdata;
 
 static int __init set_trace_boot_options(char *str)
 {
-   strncpy(trace_boot_options_buf, str, MAX_TRACER_SIZE);
+   strlcpy(trace_boot_options_buf, str, MAX_TRACER_SIZE);
trace_boot_options = trace_boot_options_buf;
return 0;
 }
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] kernel: tsacct: strncpy, always be sure of NUL terminated.

2013-04-07 Thread Chen Gang
On 2013年04月08日 11:52, KOSAKI Motohiro wrote:
> On Sun, Apr 7, 2013 at 11:27 PM, Chen Gang  wrote:
>> >
>> >   for NUL terminated string, always set '\0' at the end.
>> >
>> > Signed-off-by: Chen Gang 
>> > ---
>> >  kernel/tsacct.c |3 ++-
>> >  1 files changed, 2 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/kernel/tsacct.c b/kernel/tsacct.c
>> > index a1dd9a1..01bcc4e 100644
>> > --- a/kernel/tsacct.c
>> > +++ b/kernel/tsacct.c
>> > @@ -78,7 +78,8 @@ void bacct_add_tsk(struct user_namespace *user_ns,
>> > stats->ac_minflt = tsk->min_flt;
>> > stats->ac_majflt = tsk->maj_flt;
>> >
>> > -   strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm));
>> > +   strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm) - 1);
>> > +   stats->ac_comm[sizeof(stats->ac_comm) - 1] = '\0';
> sizeof(tsk->comm) is 16 and sizeof(stats->ac_comm) is 32. then this statement
> is strange. and set_task_comm ensure tsk->comm is nul-terminated.
> 
> so your code never change the behavior, right?
> 

  right.

  thank you for your information:
originally, I really did not check the sizeof details.


> And, If buggy driver change tsk->comm not to use set_task_comm and tsk->comm
> is not nul-terminated, strncpy() still touch unrelated memory and ac_comm may
> expose kernel internal info. that's bad.
> 
> 

  really, that's bad !

  thank you for your information:
originally, I did not think of a buggy driver can change tsk->comm.


  :-)

-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: add helper to set flags for clk-provider

2013-04-07 Thread Mike Turquette
Quoting Sebastian Hesselbarth (2013-04-04 22:22:12)
> Clock providers are not allowed to mess with struct clk internals directly
> but using helpers provided by clk-provider.h. This patch adds a helper to
> allow to set flags of a clock after registration. This is useful, if clock
> flags change during runtime, e.g. ability to set parent clock after mux
> switch.

Hi Sebastian,

I do not like this change.  There are a few reasons why.  Firstly the
clk flags have never been advertised as changing at runtime.  On that
note, can you expand your example of "ability to set parent clock after
mux switch"?  I do not follow what you mean.

Secondly, it is possible to need flags during __clk_init.  This exists
today for root clocks that use the CLK_IS_ROOT flag.  So setting that
flag after registration is too late.

Finally, how can we make sure that this api is not abused?  I'm
concerned about drivers which use __clk_set_flags in a hacky way, when
in fact the flags are supposed to be permanent properties of that clock.

Do you truly need the ability to change clock flags at runtime, or do
you instead need a way to express flags in DT?  I'm sure the clock
bindings are not the first binding to run up against flags or properties
that do not strictly match the hardware description.  Maybe solving that
problem is the right way?

Regards,
Mike

> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Mike Turquette 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/clk/clk.c|8 
>  include/linux/clk-provider.h |1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index ed87b24..780a0c0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -451,6 +451,14 @@ unsigned long __clk_get_flags(struct clk *clk)
> return !clk ? 0 : clk->flags;
>  }
>  
> +void __clk_set_flags(struct clk *clk, unsigned long flags)
> +{
> +   if (!clk)
> +   return;
> +
> +   clk->flags = flags;
> +}
> +
>  bool __clk_is_enabled(struct clk *clk)
>  {
> int ret;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 7f197d7..e862d9c 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -351,6 +351,7 @@ unsigned int __clk_get_enable_count(struct clk *clk);
>  unsigned int __clk_get_prepare_count(struct clk *clk);
>  unsigned long __clk_get_rate(struct clk *clk);
>  unsigned long __clk_get_flags(struct clk *clk);
> +void __clk_set_flags(struct clk *clk, unsigned long flags);
>  bool __clk_is_enabled(struct clk *clk);
>  struct clk *__clk_lookup(const char *name);
>  
> -- 
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] kernel: tsacct: strncpy, always be sure of NUL terminated.

2013-04-07 Thread KOSAKI Motohiro
On Sun, Apr 7, 2013 at 11:27 PM, Chen Gang  wrote:
>
>   for NUL terminated string, always set '\0' at the end.
>
> Signed-off-by: Chen Gang 
> ---
>  kernel/tsacct.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/tsacct.c b/kernel/tsacct.c
> index a1dd9a1..01bcc4e 100644
> --- a/kernel/tsacct.c
> +++ b/kernel/tsacct.c
> @@ -78,7 +78,8 @@ void bacct_add_tsk(struct user_namespace *user_ns,
> stats->ac_minflt = tsk->min_flt;
> stats->ac_majflt = tsk->maj_flt;
>
> -   strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm));
> +   strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm) - 1);
> +   stats->ac_comm[sizeof(stats->ac_comm) - 1] = '\0';

sizeof(tsk->comm) is 16 and sizeof(stats->ac_comm) is 32. then this statement
is strange. and set_task_comm ensure tsk->comm is nul-terminated.

so your code never change the behavior, right?

And, If buggy driver change tsk->comm not to use set_task_comm and tsk->comm
is not nul-terminated, strncpy() still touch unrelated memory and ac_comm may
expose kernel internal info. that's bad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] extcon fixes for 3.9-rc6

2013-04-07 Thread Chanwoo Choi
On 04/08/2013 11:36 AM, Greg KH wrote:
> On Mon, Apr 08, 2013 at 11:02:14AM +0900, Chanwoo Choi wrote:
>> Hi Greg,
>>
>> This is extcon fixes for 3.9-rc6
>> Please pull extcon with following updates.
>>
>> Best Regards and thanks,
>> Chanwoo Choi
>>
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
>> tags/extcon-3.9-rc6
>>
>> for you to fetch changes up to 2fbeb4347e02078828510e5fe43ab4bea21b20d1:
>>
>>   extcon: max8997: Fix return value (2013-04-08 09:13:18 +0900)
>>
>> 
>> This is small fixes for extcon driver.
>>
>> MAX77693 extcon driver
>> - Add 'static' keryword to internal data structure
>> - Fix return value using 'ret' instead of hardcoding
>>
>> MAX8997 extcon driver
>> - Use dev_err() instead of pr_err()
>> - Fix return value using 'ret' instead of hardcoding
> None of these should go into 3.9-final, they are all trivial cleanups.
> Only major bug fixes or regressions should be sent right now for 3.9,
> sorry.
>
> I will be glad to pull these into my -next branch for 3.10 if you want.
>
> greg k-h
>
OK, I agree completely with your opinion. Thanks.

Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel: events: strncpy, always be sure of NUL terminated.

2013-04-07 Thread Chen Gang

  for NUL terminated string, always be sure of '\0' at the end.
  
  in our case, need return value, so still use strncpy
(strlcpy return the size, not the pointer)

Signed-off-by: Chen Gang 
---
 kernel/events/core.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4757941..bdc0e25 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4752,7 +4752,8 @@ static void perf_event_mmap_event(struct perf_mmap_event 
*mmap_event)
} else {
if (arch_vma_name(mmap_event->vma)) {
name = strncpy(tmp, arch_vma_name(mmap_event->vma),
-  sizeof(tmp));
+  sizeof(tmp) - 1);
+   tmp[sizeof(tmp) - 1] = '\0';
goto got_name;
}
 
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fix sortextable building on non-Linux systems

2013-04-07 Thread Daniel Tang
Hi,

Is there any reason why 'tools/include/tools/be_byteshift.h' and 
'tools/include/tools/le_byteshift.h' needs to include 'linux/types.h'? It 
breaks compilation of ARM kernels on OS X since sortextable, which uses those 
headers, fails to build because 'linux/types.h' doesn't exist.

Included is a patch that fixes building on non-Linux systems.

Cheers,
tangrs

Signed-off-by: Daniel Tang 
---
 tools/include/tools/be_byteshift.h | 34 +-
 tools/include/tools/le_byteshift.h | 34 +-
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/tools/include/tools/be_byteshift.h 
b/tools/include/tools/be_byteshift.h
index f4912e2..d51fe26 100644
--- a/tools/include/tools/be_byteshift.h
+++ b/tools/include/tools/be_byteshift.h
@@ -1,68 +1,68 @@
 #ifndef _TOOLS_BE_BYTESHIFT_H
 #define _TOOLS_BE_BYTESHIFT_H
 
-#include 
+#include 
 
-static inline __u16 __get_unaligned_be16(const __u8 *p)
+static inline uint16_t __get_unaligned_be16(const uint8_t *p)
 {
return p[0] << 8 | p[1];
 }
 
-static inline __u32 __get_unaligned_be32(const __u8 *p)
+static inline uint32_t __get_unaligned_be32(const uint8_t *p)
 {
return p[0] << 24 | p[1] << 16 | p[2] << 8 | p[3];
 }
 
-static inline __u64 __get_unaligned_be64(const __u8 *p)
+static inline uint64_t __get_unaligned_be64(const uint8_t *p)
 {
-   return (__u64)__get_unaligned_be32(p) << 32 |
+   return (uint64_t)__get_unaligned_be32(p) << 32 |
   __get_unaligned_be32(p + 4);
 }
 
-static inline void __put_unaligned_be16(__u16 val, __u8 *p)
+static inline void __put_unaligned_be16(uint16_t val, uint8_t *p)
 {
*p++ = val >> 8;
*p++ = val;
 }
 
-static inline void __put_unaligned_be32(__u32 val, __u8 *p)
+static inline void __put_unaligned_be32(uint32_t val, uint8_t *p)
 {
__put_unaligned_be16(val >> 16, p);
__put_unaligned_be16(val, p + 2);
 }
 
-static inline void __put_unaligned_be64(__u64 val, __u8 *p)
+static inline void __put_unaligned_be64(uint64_t val, uint8_t *p)
 {
__put_unaligned_be32(val >> 32, p);
__put_unaligned_be32(val, p + 4);
 }
 
-static inline __u16 get_unaligned_be16(const void *p)
+static inline uint16_t get_unaligned_be16(const void *p)
 {
-   return __get_unaligned_be16((const __u8 *)p);
+   return __get_unaligned_be16((const uint8_t *)p);
 }
 
-static inline __u32 get_unaligned_be32(const void *p)
+static inline uint32_t get_unaligned_be32(const void *p)
 {
-   return __get_unaligned_be32((const __u8 *)p);
+   return __get_unaligned_be32((const uint8_t *)p);
 }
 
-static inline __u64 get_unaligned_be64(const void *p)
+static inline uint64_t get_unaligned_be64(const void *p)
 {
-   return __get_unaligned_be64((const __u8 *)p);
+   return __get_unaligned_be64((const uint8_t *)p);
 }
 
-static inline void put_unaligned_be16(__u16 val, void *p)
+static inline void put_unaligned_be16(uint16_t val, void *p)
 {
__put_unaligned_be16(val, p);
 }
 
-static inline void put_unaligned_be32(__u32 val, void *p)
+static inline void put_unaligned_be32(uint32_t val, void *p)
 {
__put_unaligned_be32(val, p);
 }
 
-static inline void put_unaligned_be64(__u64 val, void *p)
+static inline void put_unaligned_be64(uint64_t val, void *p)
 {
__put_unaligned_be64(val, p);
 }
diff --git a/tools/include/tools/le_byteshift.h 
b/tools/include/tools/le_byteshift.h
index c99d45a..259a132 100644
--- a/tools/include/tools/le_byteshift.h
+++ b/tools/include/tools/le_byteshift.h
@@ -1,68 +1,68 @@
 #ifndef _TOOLS_LE_BYTESHIFT_H
 #define _TOOLS_LE_BYTESHIFT_H
 
-#include 
+#include 
 
-static inline __u16 __get_unaligned_le16(const __u8 *p)
+static inline uint16_t __get_unaligned_le16(const uint8_t *p)
 {
return p[0] | p[1] << 8;
 }
 
-static inline __u32 __get_unaligned_le32(const __u8 *p)
+static inline uint32_t __get_unaligned_le32(const uint8_t *p)
 {
return p[0] | p[1] << 8 | p[2] << 16 | p[3] << 24;
 }
 
-static inline __u64 __get_unaligned_le64(const __u8 *p)
+static inline uint64_t __get_unaligned_le64(const uint8_t *p)
 {
-   return (__u64)__get_unaligned_le32(p + 4) << 32 |
+   return (uint64_t)__get_unaligned_le32(p + 4) << 32 |
   __get_unaligned_le32(p);
 }
 
-static inline void __put_unaligned_le16(__u16 val, __u8 *p)
+static inline void __put_unaligned_le16(uint16_t val, uint8_t *p)
 {
*p++ = val;
*p++ = val >> 8;
 }
 
-static inline void __put_unaligned_le32(__u32 val, __u8 *p)
+static inline void __put_unaligned_le32(uint32_t val, uint8_t *p)
 {
__put_unaligned_le16(val >> 16, p + 2);
__put_unaligned_le16(val, p);
 }
 
-static inline void __put_unaligned_le64(__u64 val, __u8 *p)
+static inline void __put_unaligned_le64(uint64_t val, uint8_t *p)
 {
__put_unaligned_le32(val >> 32, p + 4);
__put_unaligned_le32(val, p);
 }
 
-static inline __u16 get_unaligned_le16(const void *p)
+static inline 

[PATCH] clk: mvebu: Fix valid value range checking for cpu_freq_select

2013-04-07 Thread Axel Lin
cpu_freq_select is used as array subscript, thus the valid value range
is 0 ... ARRAY_SIZE() - 1.

Signed-off-by: Axel Lin 
---
 drivers/clk/mvebu/clk-core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mvebu/clk-core.c b/drivers/clk/mvebu/clk-core.c
index 1b4e333..0a53edb 100644
--- a/drivers/clk/mvebu/clk-core.c
+++ b/drivers/clk/mvebu/clk-core.c
@@ -156,7 +156,7 @@ static u32 __init armada_370_get_cpu_freq(void __iomem *sar)
 
cpu_freq_select = ((readl(sar) >> SARL_A370_PCLK_FREQ_OPT) &
   SARL_A370_PCLK_FREQ_OPT_MASK);
-   if (cpu_freq_select > ARRAY_SIZE(armada_370_cpu_frequencies)) {
+   if (cpu_freq_select >= ARRAY_SIZE(armada_370_cpu_frequencies)) {
pr_err("CPU freq select unsupported %d\n", cpu_freq_select);
cpu_freq = 0;
} else
@@ -278,7 +278,7 @@ static u32 __init armada_xp_get_cpu_freq(void __iomem *sar)
cpu_freq_select |= (((readl(sar+4) >> SARH_AXP_PCLK_FREQ_OPT) &
 SARH_AXP_PCLK_FREQ_OPT_MASK)
<< SARH_AXP_PCLK_FREQ_OPT_SHIFT);
-   if (cpu_freq_select > ARRAY_SIZE(armada_xp_cpu_frequencies)) {
+   if (cpu_freq_select >= ARRAY_SIZE(armada_xp_cpu_frequencies)) {
pr_err("CPU freq select unsupported: %d\n", cpu_freq_select);
cpu_freq = 0;
} else
-- 
1.7.10.4



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


Re: [patch v7 20/21] sched: don't do power balance on share cpu power domain

2013-04-07 Thread Preeti U Murthy
Hi Alex,

I am sorry I overlooked the changes you have made to the power
scheduling policies.Now you have just two : performance and powersave.

Hence you can ignore my below comments.But if you use group->capacity
instead of group->weight for threshold,like you did for balance policy
in your version5 of this patchset, dont you think the below patch can be
avoided? group->capacity being the threshold will automatically ensure
that you dont pack onto domains that share cpu power.

Regards
Preeti U Murthy

On 04/08/2013 08:47 AM, Preeti U Murthy wrote:
> Hi Alex,
> 
> On 04/04/2013 07:31 AM, Alex Shi wrote:
>> Packing tasks among such domain can't save power, just performance
>> losing. So no power balance on them.
> 
> As far as my understanding goes, powersave policy is the one that tries
> to pack tasks onto a SIBLING domain( domain where SD_SHARE_CPUPOWER is
> set).balance policy does not do that,meaning it does not pack on the
> domain that shares CPU power,but packs across all other domains.So the
> change you are making below results in nothing but the default behaviour
> of balance policy.
> 
> Correct me if I am wrong but my point is,looks to me,that the powersave
> policy is introduced in this patchset,and with the below patch its
> characteristic behaviour of packing onto domains sharing cpu power is
> removed,thus making it default to balance policy.Now there are two
> policies which behave the same way:balance and powersave.
> 
>>
>> Signed-off-by: Alex Shi 
>> ---
>>  kernel/sched/fair.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 047a1b3..3a0284b 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -3503,7 +3503,7 @@ static int get_cpu_for_power_policy(struct 
>> sched_domain *sd, int cpu,
>>
>>  policy = get_sd_sched_balance_policy(sd, cpu, p, sds);
>>  if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader) {
>> -if (wakeup)
>> +if (wakeup && !(sd->flags & SD_SHARE_CPUPOWER))
>>  new_cpu = find_leader_cpu(sds->group_leader,
>>  p, cpu, policy);
>>  /* for fork balancing and a little busy task */
>> @@ -4410,8 +4410,9 @@ static unsigned long task_h_load(struct task_struct *p)
>>  static inline void init_sd_lb_power_stats(struct lb_env *env,
>>  struct sd_lb_stats *sds)
>>  {
>> -if (sched_balance_policy == SCHED_POLICY_PERFORMANCE ||
>> -env->idle == CPU_NOT_IDLE) {
>> +if (sched_balance_policy == SCHED_POLICY_PERFORMANCE
>> +|| env->sd->flags & SD_SHARE_CPUPOWER
>> +|| env->idle == CPU_NOT_IDLE) {
>>  env->flags &= ~LBF_POWER_BAL;
>>  env->flags |= LBF_PERF_BAL;
>>  return;
>>
> 
> Regards
> Preeti U Murthy
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel: tsacct: strncpy, always be sure of NUL terminated.

2013-04-07 Thread Chen Gang

  for NUL terminated string, always set '\0' at the end.

Signed-off-by: Chen Gang 
---
 kernel/tsacct.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index a1dd9a1..01bcc4e 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -78,7 +78,8 @@ void bacct_add_tsk(struct user_namespace *user_ns,
stats->ac_minflt = tsk->min_flt;
stats->ac_majflt = tsk->maj_flt;
 
-   strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm));
+   strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm) - 1);
+   stats->ac_comm[sizeof(stats->ac_comm) - 1] = '\0';
 }
 
 
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch v7 20/21] sched: don't do power balance on share cpu power domain

2013-04-07 Thread Preeti U Murthy
Hi Alex,

On 04/04/2013 07:31 AM, Alex Shi wrote:
> Packing tasks among such domain can't save power, just performance
> losing. So no power balance on them.

As far as my understanding goes, powersave policy is the one that tries
to pack tasks onto a SIBLING domain( domain where SD_SHARE_CPUPOWER is
set).balance policy does not do that,meaning it does not pack on the
domain that shares CPU power,but packs across all other domains.So the
change you are making below results in nothing but the default behaviour
of balance policy.

Correct me if I am wrong but my point is,looks to me,that the powersave
policy is introduced in this patchset,and with the below patch its
characteristic behaviour of packing onto domains sharing cpu power is
removed,thus making it default to balance policy.Now there are two
policies which behave the same way:balance and powersave.

> 
> Signed-off-by: Alex Shi 
> ---
>  kernel/sched/fair.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 047a1b3..3a0284b 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3503,7 +3503,7 @@ static int get_cpu_for_power_policy(struct sched_domain 
> *sd, int cpu,
> 
>   policy = get_sd_sched_balance_policy(sd, cpu, p, sds);
>   if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader) {
> - if (wakeup)
> + if (wakeup && !(sd->flags & SD_SHARE_CPUPOWER))
>   new_cpu = find_leader_cpu(sds->group_leader,
>   p, cpu, policy);
>   /* for fork balancing and a little busy task */
> @@ -4410,8 +4410,9 @@ static unsigned long task_h_load(struct task_struct *p)
>  static inline void init_sd_lb_power_stats(struct lb_env *env,
>   struct sd_lb_stats *sds)
>  {
> - if (sched_balance_policy == SCHED_POLICY_PERFORMANCE ||
> - env->idle == CPU_NOT_IDLE) {
> + if (sched_balance_policy == SCHED_POLICY_PERFORMANCE
> + || env->sd->flags & SD_SHARE_CPUPOWER
> + || env->idle == CPU_NOT_IDLE) {
>   env->flags &= ~LBF_POWER_BAL;
>   env->flags |= LBF_PERF_BAL;
>   return;
> 

Regards
Preeti U Murthy

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

2013-04-07 Thread Stephen Rothwell
Hi Al,

On Mon, 8 Apr 2013 03:00:11 +0100 Al Viro  wrote:
>
> On Mon, Apr 08, 2013 at 11:53:25AM +1000, Stephen Rothwell wrote:
> > The only use outside of kernel/timer.c was in kernel/compat.c, so move
> > compat_sys_sysinfo() next to sys_sysinfo() in kernel/timer.c.
> 
> Please, switch it to COMPAT_SYSCALL_DEFINE, while you are at it.

I would prefer someone do that as a separate patch as this is a "no
logical change" patch.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpqPW4cZ2DQH.pgp
Description: PGP signature


Re: [PATCH] kernel: module: strncpy issue, using strlcpy instead of strncpy

2013-04-07 Thread Chen Gang
On 2013年04月08日 10:48, Chen Gang wrote:
> On 2013年04月07日 22:28, Geert Uytterhoeven wrote:
>> On Sun, Apr 7, 2013 at 1:38 PM, Chen Gang  wrote:
   ownername and namebuf are all NUL terminated string.

   need always let them ended by '\0'.

 Signed-off-by: Chen Gang 
 ---
  kernel/module.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/kernel/module.c b/kernel/module.c
 index 3c2c72d..597efd8 100644
 --- a/kernel/module.c
 +++ b/kernel/module.c
 @@ -3464,7 +3464,7 @@ const char *module_address_lookup(unsigned long addr,
 }
 /* Make a copy in here where it's safe */
 if (ret) {
 -   strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
 +   strlcpy(namebuf, ret, KSYM_NAME_LEN);
 ret = namebuf;
 }
 preempt_enable();
>> Is this buffer ever copied to userspace?
> 
> 

  the key words is:
if it knows the length of namebuf, it may need initialized namebuf.
if it can not know the length of namebuf
  it can not initialize namebuf.
  (in our case, it only know, the namebuf length >= KSYM_NAME_LEN)

  so, it need not initialize it.

  :-)

  thanks.

gchen.


> at lease now:
>   I think, it is not, the reason is:
> it is only a tool function for kallsyms using.
> it has no duty to let namebuf initialized.
> 
>   please reference the related comments in include/linux/module.h
> 
> 493 /* For kallsyms to ask for address resolution.  namebuf should be at
> 494  * least KSYM_NAME_LEN long: a pointer to namebuf is returned if
> 495  * found, otherwise NULL. */
> 496 const char *module_address_lookup(unsigned long addr,
> 497 unsigned long *symbolsize,
> 498 unsigned long *offset,
> 499 char **modname,
> 500 char *namebuf);
> 
> 
> originally:
>   it will not cause issue (the upper caller has noticed it).
>   but we really need let it '\0' ended within module_address_lookup.
> (so, maybe for subject: "strncpy issue" need be deleted)
> 
> 
> in the future:
>   since it is an extern function, it can be used by others.
>   since it is a tool function, it can not be used directly by user mode.
>   according to the api definition:
> if it is necessary to initialize (such as return to user mode)
>   the caller should perform it.
> if it is not necessary to initialize (not return to user mode)
>   still prefer the caller to initialize it.
>   but should understand if the caller will not initialize it.
> (if caller does not initialize it, it should not cause issue)
> 
> 
>   thanks.
> 
>   :-)
> 
> 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM/reboot: call syscore_shutdown() after disable_nonboot_cpus()

2013-04-07 Thread chenhc
> On Sunday, April 07, 2013 08:29:32 AM Greg KH wrote:
>> On Sun, Apr 07, 2013 at 10:46:00AM +0200, Rafael J. Wysocki wrote:
>> > On Sunday, April 07, 2013 10:14:14 AM Huacai Chen wrote:
>> > > As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
>> > > subsystems PM) say, syscore_ops operations should be carried with
>> one
>> > > CPU on-line and interrupts disabled. However, after commit f96972f2d
>> > > (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
>> > > syscore_shutdown() is called before disable_nonboot_cpus(), so break
>> > > the rules. We have a MIPS machine with a 8259A PIC, and there is an
>> > > external timer (HPET) linked at 8259A. Since 8259A has been shutdown
>> > > too early (by syscore_shutdown()), disable_nonboot_cpus() runs
>> without
>> > > timer interrupt, so it hangs and reboot fails. This patch call
>> > > syscore_shutdown() a little later (after disable_nonboot_cpus()) to
>> > > avoid reboot failure, this is the same way as poweroff does.
>> > >
>> > > BTW, add disable_nonboot_cpus() in kernel_halt() for consistency.
>> > >
>> > > Signed-off-by: Huacai Chen 
>> > > Cc: 
>> >
>> > While I agree with the changes, I'm not sure if I'm the right
>> maintainer,
>> > as this isn't really PM code.
>> >
>> > Andrew, should I take this?
>>
>> Andrew is on vacation for a few weeks, so you might need to take this
>> through your tree.
>
> OK
>
> But, it looks like we should actually disable interrupts on the remaining
> CPU after we've called disable_nonboot_cpus() so that the
> syscore_shutdown()
> assumptions are satisfied which the patch doesn't do.
>
> Chen (I apologize if that's not the right part of your full name to use
> here),
> do you think that's not necessary and if so, then for what reason?

Reboot and poweroff are both OK after I move syscore_shutdown(), I also don't
know whether we should disable interrupts. Since you are the author of
commit 40dc166c (PM / Core: Introduce struct syscore_ops for core subsystems
 PM), please tell me why syscore_shutdown() need interrupt disabled? (I just
know that syscore_shutdown() will cause disable_nonboot_cpus() hang)

BTW, Chen is my last name and you needn't worry about this.

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


Re: [PATCH] kernel: module: strncpy issue, using strlcpy instead of strncpy

2013-04-07 Thread Chen Gang
On 2013年04月07日 22:28, Geert Uytterhoeven wrote:
> On Sun, Apr 7, 2013 at 1:38 PM, Chen Gang  wrote:
>> >   ownername and namebuf are all NUL terminated string.
>> >
>> >   need always let them ended by '\0'.
>> >
>> > Signed-off-by: Chen Gang 
>> > ---
>> >  kernel/module.c |4 ++--
>> >  1 files changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/kernel/module.c b/kernel/module.c
>> > index 3c2c72d..597efd8 100644
>> > --- a/kernel/module.c
>> > +++ b/kernel/module.c
>> > @@ -3464,7 +3464,7 @@ const char *module_address_lookup(unsigned long addr,
>> > }
>> > /* Make a copy in here where it's safe */
>> > if (ret) {
>> > -   strncpy(namebuf, ret, KSYM_NAME_LEN - 1);
>> > +   strlcpy(namebuf, ret, KSYM_NAME_LEN);
>> > ret = namebuf;
>> > }
>> > preempt_enable();
> Is this buffer ever copied to userspace?


at lease now:
  I think, it is not, the reason is:
it is only a tool function for kallsyms using.
it has no duty to let namebuf initialized.

  please reference the related comments in include/linux/module.h

493 /* For kallsyms to ask for address resolution.  namebuf should be at
494  * least KSYM_NAME_LEN long: a pointer to namebuf is returned if
495  * found, otherwise NULL. */
496 const char *module_address_lookup(unsigned long addr,
497 unsigned long *symbolsize,
498 unsigned long *offset,
499 char **modname,
500 char *namebuf);


originally:
  it will not cause issue (the upper caller has noticed it).
  but we really need let it '\0' ended within module_address_lookup.
(so, maybe for subject: "strncpy issue" need be deleted)


in the future:
  since it is an extern function, it can be used by others.
  since it is a tool function, it can not be used directly by user mode.
  according to the api definition:
if it is necessary to initialize (such as return to user mode)
  the caller should perform it.
if it is not necessary to initialize (not return to user mode)
  still prefer the caller to initialize it.
  but should understand if the caller will not initialize it.
(if caller does not initialize it, it should not cause issue)


  thanks.

  :-)


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: af_unix udev startup regression

2013-04-07 Thread Lai Jiangshan
On 04/05/2013 02:03 AM, Linus Torvalds wrote:
> [ Fixed odd legacy subject line that has nothing to do with the actual bug ]
> 
> Hmm. Can you double-check and verify that reverting that commit makes
> things work again for you?

reverting 14134f6584212d585b310ce95428014b653dfaf6 works.

14134f6584212d585b310ce95428014b653dfaf6 is already reverted in upstream.
(and sorry for so late reply)

> 
> Also, what's your distribution and setup? 

Fedora 16

Thanks,
Lai

> I'd like this to get
> verified, just to see that it's not some timing-dependent thing or a
> bisection mistake, but if so, then the LSB test-cases obviously have
> to be fixed, and the commit that causes the problem needs to be
> reverted. Test-cases count for nothing compared to actual users.
> 
> Linus
> 
> On Thu, Apr 4, 2013 at 9:17 AM, Lai Jiangshan  wrote:
>> Hi, ALL
>>
>> I also encountered the same problem.
>>
>> git bisect:
>>
>> 14134f6584212d585b310ce95428014b653dfaf6 is the first bad commit
>> commit 14134f6584212d585b310ce95428014b653dfaf6
>> Author: dingtianhong 
>> Date:   Mon Mar 25 17:02:04 2013 +
>>
>> af_unix: dont send SCM_CREDENTIAL when dest socket is NULL
>>
>> SCM_SCREDENTIALS should apply to write() syscalls only either source or
>> destination
>> socket asserted SOCK_PASSCRED. The original implememtation in
>> maybe_add_creds is wrong,
>> and breaks several LSB testcases ( i.e.
>> /tset/LSB.os/netowkr/recvfrom/T.recvfrom).
>>
>> Origionally-authored-by: Karel Srot 
>> Signed-off-by: Ding Tianhong 
>> Acked-by: Eric Dumazet 
>> Signed-off-by: David S. Miller 
>>
>> :04 04 ef0356cc0fc168a39c0f94cff0ba27c46c4d0048
>> ae34e59f235c379f04d6145f0103cccd5b3a307a M net
>>
>> ===
>> Like Brian Gerst, no obvious bug, but the system can't boot, "service udev
>> start" fails when boot
>> (also DEBUG_PAGEALLOC=n, I did not try to test with it=y)
>>
>> [   11.022976] systemd[1]: udev-control.socket failed to listen on sockets:
>> Address already in use
>> [   11.023293] systemd[1]: Unit udev-control.socket entered failed state.
>> [   11.182478] systemd-readahead-replay[399]: Bumped block_nr parameter of
>> 8:16 to 16384. This is a temporary hack and should be removed one day.
>> [   14.473283] udevd[410]: bind failed: Address already in use
>> [   14.478630] udevd[410]: error binding udev control socket
>> [   15.201158] systemd[1]: udev.service: main process exited, code=exited,
>> status=1
>> [   16.900792] udevd[427]: error binding udev control socket
>> [   18.356484] EXT4-fs (sdb7): re-mounted. Opts: (null)
>> [   19.738401] systemd[1]: udev.service holdoff time over, scheduling
>> restart.
>> [   19.742494] systemd[1]: Job pending for unit, delaying automatic restart.
>> [   19.747764] systemd[1]: Unit udev.service entered failed state.
>> [   19.752303] systemd[1]: udev-control.socket failed to listen on sockets:
>> Address already in use
>> [   19.770723] udevd[459]: bind failed: Address already in use
>> [   19.771027] udevd[459]: error binding udev control socket
>> [   19.771175] udevd[459]: error binding udev control socket
>> [   19.813256] systemd[1]: udev.service: main process exited, code=exited,
>> status=1
>> [   19.914450] systemd[1]: udev.service holdoff time over, scheduling
>> restart.
>> [   19.918374] systemd[1]: Job pending for unit, delaying automatic restart.
>> [   19.923392] systemd[1]: Unit udev.service entered failed state.
>> [   19.923808] systemd[1]: udev-control.socket failed to listen on sockets:
>> Address already in use
>> [   19.943792] udevd[465]: bind failed: Address already in use
>> [   19.944056] udevd[465]: error binding udev control socket
>> [   19.944210] udevd[465]: error binding udev control socket
>> [   19.946071] systemd[1]: udev.service: main process exited, code=exited,
>> status=1
>> [   20.047524] systemd[1]: udev.service holdoff time over, scheduling
>> restart.
>> [   20.051939] systemd[1]: Job pending for unit, delaying automatic restart.
>> [   20.057539] systemd[1]: Unit udev.service entered failed state.
>> [   20.058069] systemd[1]: udev-control.socket failed to listen on sockets:
>> Address already in use
>> [   20.081141] udevd[467]: bind failed: Address already in use
>> [   20.087120] udevd[467]: error binding udev control socket
>> [   20.092040] udevd[467]: error binding udev control socket
>> [   20.096519] systemd[1]: udev.service: main process exited, code=exited,
>> status=1
>> [   20.184910] systemd[1]: udev.service holdoff time over, scheduling
>> restart.
>> [   20.189863] systemd[1]: Job pending for unit, delaying automatic restart.
>> [   20.195440] systemd[1]: Unit udev.service entered failed state.
>> [   20.196012] systemd[1]: udev-control.socket failed to listen on sockets:
>> Address already in use
>> [   20.220543] udevd[469]: bind failed: Address already in use
>> [   20.220584] udevd[469]: error binding udev control socket
>> [   20.220780] udevd[469]: error binding udev control 

Re: [GIT PULL] extcon fixes for 3.9-rc6

2013-04-07 Thread Greg KH
On Mon, Apr 08, 2013 at 11:02:14AM +0900, Chanwoo Choi wrote:
> Hi Greg,
> 
> This is extcon fixes for 3.9-rc6
> Please pull extcon with following updates.
> 
> Best Regards and thanks,
> Chanwoo Choi
> 
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> tags/extcon-3.9-rc6
> 
> for you to fetch changes up to 2fbeb4347e02078828510e5fe43ab4bea21b20d1:
> 
>   extcon: max8997: Fix return value (2013-04-08 09:13:18 +0900)
> 
> 
> This is small fixes for extcon driver.
> 
> MAX77693 extcon driver
> - Add 'static' keryword to internal data structure
> - Fix return value using 'ret' instead of hardcoding
> 
> MAX8997 extcon driver
> - Use dev_err() instead of pr_err()
> - Fix return value using 'ret' instead of hardcoding

None of these should go into 3.9-final, they are all trivial cleanups.
Only major bug fixes or regressions should be sent right now for 3.9,
sorry.

I will be glad to pull these into my -next branch for 3.10 if you want.

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/


[PATCH] bitmap: speedup in bitmap_find_free_region when order is 0

2013-04-07 Thread Chanho Min
If bitmap_find_free_region() is called with order=0, We can reduce
for-loops to find 1 free bit. First, It scans bitmap array by the
increment of long type, then find 1 free bit within 1 long type value.

In 32 bits system and 1024 bits size, in the worst case, We need 1024
for-loops to find 1 free bit. But, If This is applied, it takes
64 for-loops. Instead, if free bit is in the first index of the bitmaps,
It will be needed additional 1 for-loop. But from second index, It
will be speed up significantly.

Signed-off-by: Chanho Min 
---
 lib/bitmap.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 06f7e4f..0c1f03a 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1099,6 +1099,37 @@ done:
 }
 
 /**
+ * bitmap_find_free_one - find a mem region
+ * @bitmap: array of unsigned longs corresponding to the bitmap
+ * @bits: number of bits in the bitmap
+ *
+ * Find one of free (zero) bits in a @bitmap of @bits bits and
+ * allocate them (set them to one).
+ *
+ * Return the bit offset in bitmap of the allocated region,
+ * or -errno on failure.
+ */
+static int __bitmap_find_free_one(unsigned long *bitmap, int bits)
+{
+   int pos, i;
+   unsigned long mask = (unsigned long)(~((unsigned long) 0));
+   int nlongs_reg = BITS_TO_LONGS(bits);
+
+   for (i = 0 ; i < nlongs_reg ; i++) {
+   if ((bitmap[i] & mask) != mask) {
+   for (pos = 0 ; pos < BITS_PER_LONG ; pos++) {
+   if (!__reg_op([i], pos, 0,
+   REG_OP_ISFREE))
+   continue;
+   __reg_op([i], pos, 0, REG_OP_ALLOC);
+   return pos;
+   }
+   }
+   }
+   return -ENOMEM;
+}
+
+/**
  * bitmap_find_free_region - find a contiguous aligned mem region
  * @bitmap: array of unsigned longs corresponding to the bitmap
  * @bits: number of bits in the bitmap
@@ -1116,6 +1147,9 @@ int bitmap_find_free_region(unsigned long *bitmap, int 
bits, int order)
 {
int pos, end;   /* scans bitmap by regions of size order */
 
+   if (order == 0)
+   return __bitmap_find_free_one(bitmap, bits);
+
for (pos = 0 ; (end = pos + (1 << order)) <= bits; pos = end) {
if (!__reg_op(bitmap, pos, order, REG_OP_ISFREE))
continue;
-- 
1.7.9.5

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


Re: [RFC PATCH] wfcqueue: implement __wfcq_enqueue_head() (v3)

2013-04-07 Thread Eric Wong
Mathieu Desnoyers  wrote:
> Changes since v2:
> * Only issue cmpxchg() if queue was empty.
> * Add missing memory barrier.

Thanks!

There's a slight drop in performance either from the barrier or larger
code, but I'm not worried (it was around 9-10s before wfcqueue).

$ time ./eponeshotmt -c 100 -w 4 -t 4 -f 10
real0m 5.83s
user0m 1.35s
sys 0m 21.95s

I also ran v2 on Davide Libenzi's totalmess epoll stresser for a few
hours yesterday without failures.  Running totalmess right now on v3,
so far so good :)

Tested-by: Eric Wong 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: wake-affine throttle

2013-04-07 Thread Michael Wang
On 03/25/2013 01:24 PM, Michael Wang wrote:
> Recently testing show that wake-affine stuff cause regression on pgbench, the
> hiding rat was finally catched out.
> 
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will benefit us if waker's cpu cached hot data for wakee, or the extreme
> ping-pong case.
> 
> However, the whole stuff is somewhat blindly, there is no examining on the
> relationship between waker and wakee, and since the stuff itself
> is time-consuming, some workload suffered, pgbench is just the one who
> has been found.
> 
> Thus, throttle the wake-affine stuff for such workload is necessary.
> 
> This patch introduced a new knob 'sysctl_sched_wake_affine_interval' with the
> default value 1ms, which means wake-affine stuff only effect once per 1ms, 
> which
> usually the minimum balance interval (the idea is that the rapid of 
> wake-affine
> should lower than the rapid of load-balance at least).
> 
> By turning the new knob, those workload who suffered will have the chance to
> stop the regression.

My recently testing show this idea still works well after the
wake-affine itself was optimized.

Throttle seems to be an easy and efficient way to stop the regression of
pgbench caused by wake-affine stuff, should we adopt this approach?

Please let me know if there are still any concerns ;-)

Regards,
Michael Wang

> 
> Test:
>   Test with 12 cpu X86 server and tip 3.9.0-rc2.
> 
>   Default 1ms interval bring limited performance improvement(<5%) for
>   pgbench, significant improvement start to show when turning the
>   knob to 100ms.
> 
>   original100ms   
> 
>   | db_size | clients |  tps  |   |  tps  |
>   +-+-+---+   +---+
>   | 21 MB   |   1 | 10572 |   | 10675 |
>   | 21 MB   |   2 | 21275 |   | 21228 |
>   | 21 MB   |   4 | 41866 |   | 41946 |
>   | 21 MB   |   8 | 53931 |   | 55176 |
>   | 21 MB   |  12 | 50956 |   | 54457 |   +6.87%
>   | 21 MB   |  16 | 49911 |   | 55468 |   +11.11%
>   | 21 MB   |  24 | 46046 |   | 56446 |   +22.59%
>   | 21 MB   |  32 | 43405 |   | 55177 |   +27.12%
>   | 7483 MB |   1 |  7734 |   |  7721 |
>   | 7483 MB |   2 | 19375 |   | 19277 |
>   | 7483 MB |   4 | 37408 |   | 37685 |
>   | 7483 MB |   8 | 49033 |   | 49152 |
>   | 7483 MB |  12 | 45525 |   | 49241 |   +8.16%
>   | 7483 MB |  16 | 45731 |   | 51425 |   +12.45%
>   | 7483 MB |  24 | 41533 |   | 52349 |   +26.04%
>   | 7483 MB |  32 | 36370 |   | 51022 |   +40.28%
>   | 15 GB   |   1 |  7576 |   |  7422 |
>   | 15 GB   |   2 | 19157 |   | 19176 |
>   | 15 GB   |   4 | 37285 |   | 36982 |
>   | 15 GB   |   8 | 48718 |   | 48413 |
>   | 15 GB   |  12 | 45167 |   | 48497 |   +7.37%
>   | 15 GB   |  16 | 45270 |   | 51276 |   +13.27%
>   | 15 GB   |  24 | 40984 |   | 51628 |   +25.97%
>   | 15 GB   |  32 | 35918 |   | 51060 |   +42.16%
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Michael Wang 
> ---
>  include/linux/sched.h |5 +
>  kernel/sched/fair.c   |   33 -
>  kernel/sysctl.c   |   10 ++
>  3 files changed, 47 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index d35d2b6..e9efd3a 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1197,6 +1197,10 @@ enum perf_event_task_context {
>   perf_nr_task_contexts,
>  };
> 
> +#ifdef CONFIG_SMP
> +extern unsigned int sysctl_sched_wake_affine_interval;
> +#endif
> +
>  struct task_struct {
>   volatile long state;/* -1 unrunnable, 0 runnable, >0 stopped */
>   void *stack;
> @@ -1207,6 +1211,7 @@ struct task_struct {
>  #ifdef CONFIG_SMP
>   struct llist_node wake_entry;
>   int on_cpu;
> + unsigned long next_wake_affine;
>  #endif
>   int on_rq;
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7a33e59..00d7f45 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3087,6 +3087,22 @@ static inline unsigned long effective_load(struct 
> task_group *tg, int cpu,
> 
>  #endif
> 
> +/*
> + * Default is 1ms, to prevent the wake_affine() stuff working too frequently.
> + */
> +unsigned int sysctl_sched_wake_affine_interval = 1U;
> +
> +static inline int wake_affine_throttled(struct task_struct *p)
> +{
> + return time_before(jiffies, p->next_wake_affine);
> +}
> +
> +static inline void wake_affine_throttle(struct task_struct *p)
> +{
> + p->next_wake_affine = jiffies +
> + msecs_to_jiffies(sysctl_sched_wake_affine_interval);
> +}
> +
>  static int wake_affine(struct sched_domain *sd, struct task_struct *p, int 
> sync)
>  {
>   s64 this_load, load;
> @@ -3096,6 +3112,9 @@ static int 

[GIT PULL] extcon fixes for 3.9-rc6

2013-04-07 Thread Chanwoo Choi
Hi Greg,

This is extcon fixes for 3.9-rc6
Please pull extcon with following updates.

Best Regards and thanks,
Chanwoo Choi

The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-3.9-rc6

for you to fetch changes up to 2fbeb4347e02078828510e5fe43ab4bea21b20d1:

  extcon: max8997: Fix return value (2013-04-08 09:13:18 +0900)


This is small fixes for extcon driver.

MAX77693 extcon driver
- Add 'static' keryword to internal data structure
- Fix return value using 'ret' instead of hardcoding

MAX8997 extcon driver
- Use dev_err() instead of pr_err()
- Fix return value using 'ret' instead of hardcoding


Jingoo Han (1):
  extcon: max8997: use dev_err() instead of pr_err()

Sachin Kamat (3):
  extcon: max77693: Staticize default_init_data
  extcon: max77693: Fix return value
  extcon: max8997: Fix return value

 drivers/extcon/extcon-max77693.c | 10 +-
 drivers/extcon/extcon-max8997.c  | 12 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [UPDATE][PATCH 2/3] resource: Add release_mem_region_adjustable()

2013-04-07 Thread Yasuaki Ishimatsu
Hi Toshi,

2013/04/04 8:23, Toshi Kani wrote:
> Added release_mem_region_adjustable(), which releases a requested
> region from a currently busy memory resource.  This interface
> adjusts the matched memory resource accordingly if the requested
> region does not match exactly but still fits into.
> 
> This new interface is intended for memory hot-delete.  During
> bootup, memory resources are inserted from the boot descriptor
> table, such as EFI Memory Table and e820.  Each memory resource
> entry usually covers the whole contigous memory range.  Memory
> hot-delete request, on the other hand, may target to a particular
> range of memory resource, and its size can be much smaller than
> the whole contiguous memory.  Since the existing release interfaces
> like __release_region() require a requested region to be exactly
> matched to a resource entry, they do not allow a partial resource
> to be released.
> 
> There is no change to the existing interfaces since their restriction
> is valid for I/O resources.
> 
> Signed-off-by: Toshi Kani 

Reviewed-by : Yasuaki Ishimatsu 

One nitpick below.

> ---
> 
> Updated per code reviews from Yasuaki Ishimatsu, Ram Pai and
> Gu Zheng.
> 
> ---
>   include/linux/ioport.h |2 +
>   kernel/resource.c  |   93 
> 
>   2 files changed, 95 insertions(+)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 85ac9b9b..0fe1a82 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -192,6 +192,8 @@ extern struct resource * __request_region(struct resource 
> *,
>   extern int __check_region(struct resource *, resource_size_t, 
> resource_size_t);
>   extern void __release_region(struct resource *, resource_size_t,
>   resource_size_t);
> +extern int release_mem_region_adjustable(struct resource *, resource_size_t,
> + resource_size_t);
>   
>   static inline int __deprecated check_region(resource_size_t s,
>   resource_size_t n)
> diff --git a/kernel/resource.c b/kernel/resource.c
> index ae246f9..c7966c3 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1021,6 +1021,99 @@ void __release_region(struct resource *parent, 
> resource_size_t start,
>   }
>   EXPORT_SYMBOL(__release_region);
>   
> +/**
> + * release_mem_region_adjustable - release a previously reserved memory 
> region
> + * @parent: parent resource descriptor
> + * @start: resource start address
> + * @size: resource region size
> + *
> + * The requested region is released from a currently busy memory resource.
> + * It adjusts the matched busy memory resource accordingly if the requested
> + * region does not match exactly but still fits into.  Existing children of
> + * the busy memory resource must be immutable in this request.
> + *
> + * Note, when the busy memory resource gets split into two entries, the code
> + * assumes that all children remain in the lower address entry for 
> simplicity.
> + * Enhance this logic when necessary.
> + */
> +int release_mem_region_adjustable(struct resource *parent,
> + resource_size_t start, resource_size_t size)
> +{
> + struct resource **p;
> + struct resource *res, *new;
> + resource_size_t end;
> + int ret = -EINVAL;
> +

> + end = start + size - 1;
> + if ((start < parent->start) || (end > parent->end))
> + return -EINVAL;

"ret" is initialized to -EINVAL. So how about use it?

Thanks,
Yasuaki Ishimatsu

> +
> + p = >child;
> + write_lock(_lock);
> +
> + while ((res = *p)) {
> + if (res->start >= end)
> + break;
> +
> + /* look for the next resource if it does not fit into */
> + if (res->start > start || res->end < end) {
> + p = >sibling;
> + continue;
> + }
> +
> + if (!(res->flags & IORESOURCE_MEM))
> + break;
> +
> + if (!(res->flags & IORESOURCE_BUSY)) {
> + p = >child;
> + continue;
> + }
> +
> + /* found the target resource; let's adjust accordingly */
> + if (res->start == start && res->end == end) {
> + /* free the whole entry */
> + *p = res->sibling;
> + kfree(res);
> + ret = 0;
> + } else if (res->start == start && res->end != end) {
> + /* adjust the start */
> + ret = __adjust_resource(res, end + 1,
> + res->end - end);
> + } else if (res->start != start && res->end == end) {
> + /* adjust the end */
> + ret = __adjust_resource(res, res->start,
> + start - res->start);
> + } 

Re: [PATCH] Make do_sysinfo() static

2013-04-07 Thread Al Viro
On Mon, Apr 08, 2013 at 11:53:25AM +1000, Stephen Rothwell wrote:
> The only use outside of kernel/timer.c was in kernel/compat.c, so move
> compat_sys_sysinfo() next to sys_sysinfo() in kernel/timer.c.

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


[PATCH] Make do_sysinfo() static

2013-04-07 Thread Stephen Rothwell
The only use outside of kernel/timer.c was in kernel/compat.c, so move
compat_sys_sysinfo() next to sys_sysinfo() in kernel/timer.c.

Signed-off-by: Stephen Rothwell 
---
 include/linux/kernel.h |  2 --
 kernel/compat.c| 65 ---
 kernel/timer.c | 69 +-
 3 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 79fdd80..a8b579c 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -734,6 +734,4 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
 # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD
 #endif
 
-extern int do_sysinfo(struct sysinfo *info);
-
 #endif
diff --git a/kernel/compat.c b/kernel/compat.c
index 19971d8..1e8f145 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -1138,71 +1138,6 @@ asmlinkage long compat_sys_migrate_pages(compat_pid_t 
pid,
 }
 #endif
 
-struct compat_sysinfo {
-   s32 uptime;
-   u32 loads[3];
-   u32 totalram;
-   u32 freeram;
-   u32 sharedram;
-   u32 bufferram;
-   u32 totalswap;
-   u32 freeswap;
-   u16 procs;
-   u16 pad;
-   u32 totalhigh;
-   u32 freehigh;
-   u32 mem_unit;
-   char _f[20-2*sizeof(u32)-sizeof(int)];
-};
-
-asmlinkage long
-compat_sys_sysinfo(struct compat_sysinfo __user *info)
-{
-   struct sysinfo s;
-
-   do_sysinfo();
-
-   /* Check to see if any memory value is too large for 32-bit and scale
-*  down if needed
-*/
-   if ((s.totalram >> 32) || (s.totalswap >> 32)) {
-   int bitcount = 0;
-
-   while (s.mem_unit < PAGE_SIZE) {
-   s.mem_unit <<= 1;
-   bitcount++;
-   }
-
-   s.totalram >>= bitcount;
-   s.freeram >>= bitcount;
-   s.sharedram >>= bitcount;
-   s.bufferram >>= bitcount;
-   s.totalswap >>= bitcount;
-   s.freeswap >>= bitcount;
-   s.totalhigh >>= bitcount;
-   s.freehigh >>= bitcount;
-   }
-
-   if (!access_ok(VERIFY_WRITE, info, sizeof(struct compat_sysinfo)) ||
-   __put_user (s.uptime, >uptime) ||
-   __put_user (s.loads[0], >loads[0]) ||
-   __put_user (s.loads[1], >loads[1]) ||
-   __put_user (s.loads[2], >loads[2]) ||
-   __put_user (s.totalram, >totalram) ||
-   __put_user (s.freeram, >freeram) ||
-   __put_user (s.sharedram, >sharedram) ||
-   __put_user (s.bufferram, >bufferram) ||
-   __put_user (s.totalswap, >totalswap) ||
-   __put_user (s.freeswap, >freeswap) ||
-   __put_user (s.procs, >procs) ||
-   __put_user (s.totalhigh, >totalhigh) ||
-   __put_user (s.freehigh, >freehigh) ||
-   __put_user (s.mem_unit, >mem_unit))
-   return -EFAULT;
-
-   return 0;
-}
-
 COMPAT_SYSCALL_DEFINE2(sched_rr_get_interval,
   compat_pid_t, pid,
   struct compat_timespec __user *, interval)
diff --git a/kernel/timer.c b/kernel/timer.c
index dbf7a78..98c9d8c 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1567,7 +1567,7 @@ SYSCALL_DEFINE0(gettid)
  * do_sysinfo - fill in sysinfo struct
  * @info: pointer to buffer to fill
  */
-int do_sysinfo(struct sysinfo *info)
+static int do_sysinfo(struct sysinfo *info)
 {
unsigned long mem_total, sav_total;
unsigned int mem_unit, bitcount;
@@ -1642,6 +1642,73 @@ SYSCALL_DEFINE1(sysinfo, struct sysinfo __user *, info)
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+struct compat_sysinfo {
+   s32 uptime;
+   u32 loads[3];
+   u32 totalram;
+   u32 freeram;
+   u32 sharedram;
+   u32 bufferram;
+   u32 totalswap;
+   u32 freeswap;
+   u16 procs;
+   u16 pad;
+   u32 totalhigh;
+   u32 freehigh;
+   u32 mem_unit;
+   char _f[20-2*sizeof(u32)-sizeof(int)];
+};
+
+asmlinkage long
+compat_sys_sysinfo(struct compat_sysinfo __user *info)
+{
+   struct sysinfo s;
+
+   do_sysinfo();
+
+   /* Check to see if any memory value is too large for 32-bit and scale
+*  down if needed
+*/
+   if ((s.totalram >> 32) || (s.totalswap >> 32)) {
+   int bitcount = 0;
+
+   while (s.mem_unit < PAGE_SIZE) {
+   s.mem_unit <<= 1;
+   bitcount++;
+   }
+
+   s.totalram >>= bitcount;
+   s.freeram >>= bitcount;
+   s.sharedram >>= bitcount;
+   s.bufferram >>= bitcount;
+   s.totalswap >>= bitcount;
+   s.freeswap >>= bitcount;
+   s.totalhigh >>= bitcount;
+   s.freehigh >>= bitcount;
+   }
+
+   if (!access_ok(VERIFY_WRITE, info, sizeof(struct compat_sysinfo)) ||
+   __put_user (s.uptime, >uptime) 

Re: [RFC] mm: remove swapcache page early

2013-04-07 Thread Simon Jeons

On 04/08/2013 09:48 AM, Minchan Kim wrote:

Hello Simon,

On Sun, Apr 07, 2013 at 03:26:12PM +0800, Simon Jeons wrote:

Ping Minchan.
On 04/02/2013 09:40 PM, Simon Jeons wrote:

Hi Hugh,
On 03/28/2013 05:41 AM, Hugh Dickins wrote:

On Wed, 27 Mar 2013, Minchan Kim wrote:


Swap subsystem does lazy swap slot free with expecting the page
would be swapped out again so we can't avoid unnecessary write.

  so we can avoid unnecessary write.

If page can be swap out again, which codes can avoid unnecessary
write? Could you point out to me? Thanks in advance. ;-)

Look at shrink_page_list.

1) PageAnon(page) && !PageSwapCache()
2) add_to_swap's SetPageDirty
3) __remove_mapping

P.S)
It seems you are misunderstanding. Here isn't proper place to ask a
question for your understanding the code. As I know, there are some
project(ex, kernelnewbies) and books for study and sharing the
knowledge linux kernel.

I recommend Mel's "Understand the Linux Virtual Memory Manager".
It's rather outdated but will be very helpful to understand VM of
linux kernel. You can get it freely but I hope you pay for.
So if author become a billionaire by selecting best book in Amazon,
he might print out second edition which covers all of new VM features
and may solve all of you curiosity.

It would be a another method to contribute open source project. :)

I believe you talented developers can catch it up with reading the
code enoughly and find more bonus knowledge. I think it's why our senior
developers yell out RTFM and I follow them.


What's the meaning of RTFM?



Cheers!




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: remove swapcache page early

2013-04-07 Thread Minchan Kim
Hello Simon,

On Sun, Apr 07, 2013 at 03:26:12PM +0800, Simon Jeons wrote:
> Ping Minchan.
> On 04/02/2013 09:40 PM, Simon Jeons wrote:
> >Hi Hugh,
> >On 03/28/2013 05:41 AM, Hugh Dickins wrote:
> >>On Wed, 27 Mar 2013, Minchan Kim wrote:
> >>
> >>>Swap subsystem does lazy swap slot free with expecting the page
> >>>would be swapped out again so we can't avoid unnecessary write.
> >>  so we can avoid unnecessary write.
> >
> >If page can be swap out again, which codes can avoid unnecessary
> >write? Could you point out to me? Thanks in advance. ;-)

Look at shrink_page_list.

1) PageAnon(page) && !PageSwapCache() 
2) add_to_swap's SetPageDirty
3) __remove_mapping

P.S)
It seems you are misunderstanding. Here isn't proper place to ask a
question for your understanding the code. As I know, there are some
project(ex, kernelnewbies) and books for study and sharing the
knowledge linux kernel.

I recommend Mel's "Understand the Linux Virtual Memory Manager".
It's rather outdated but will be very helpful to understand VM of
linux kernel. You can get it freely but I hope you pay for.
So if author become a billionaire by selecting best book in Amazon,
he might print out second edition which covers all of new VM features
and may solve all of you curiosity.

It would be a another method to contribute open source project. :)

I believe you talented developers can catch it up with reading the
code enoughly and find more bonus knowledge. I think it's why our senior
developers yell out RTFM and I follow them.

Cheers!


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


[PATCH] Staging: omap-thermal: remove trailing whitespace from omap-bandgap.c

2013-04-07 Thread Tyrel Datwyler
This patch removes trailing whitespace from a blank line in omap-bandgap.c as
detected by the checkpatch.pl tool.

Signed-off-by: Tyrel Datwyler 
---
 drivers/staging/omap-thermal/omap-bandgap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/omap-thermal/omap-bandgap.c 
b/drivers/staging/omap-thermal/omap-bandgap.c
index dcc1448..e507d17 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -823,7 +823,7 @@ static struct omap_bandgap *omap_bandgap_build(struct 
platform_device *pdev)
bg_ptr->base = chunk;
if (IS_ERR(chunk))
return ERR_CAST(chunk);
-   
+
i++;
} while (res);
 
-- 
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/


[PATCH 2/5 V2] mmc: core: call pm_runtime_put_noidle in pm_runtime_get_sync failed case

2013-04-07 Thread Li Fei

Even in failed case of pm_runtime_get_sync, the usage_count
is incremented. In order to keep the usage_count with correct
value and runtime power management to behave correctly, call
pm_runtime_put_noidle in such case.

Signed-off-by Liu Chuansheng 
Signed-off-by: Li Fei 
---
 drivers/mmc/core/sdio.c |4 +++-
 drivers/mmc/core/sdio_bus.c |3 +--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index aa0719a..6889a82 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -861,8 +861,10 @@ static void mmc_sdio_detect(struct mmc_host *host)
/* Make sure card is powered before detecting it */
if (host->caps & MMC_CAP_POWER_OFF_CARD) {
err = pm_runtime_get_sync(>card->dev);
-   if (err < 0)
+   if (err < 0) {
+   pm_runtime_put_noidle(>card->dev);
goto out;
+   }
}
 
mmc_claim_host(host);
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 5e57048..7bfefb5 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -137,7 +137,7 @@ static int sdio_bus_probe(struct device *dev)
if (func->card->host->caps & MMC_CAP_POWER_OFF_CARD) {
ret = pm_runtime_get_sync(dev);
if (ret < 0)
-   goto out;
+   goto disable_runtimepm;
}
 
/* Set the default block size so the driver is sure it's something
@@ -157,7 +157,6 @@ static int sdio_bus_probe(struct device *dev)
 disable_runtimepm:
if (func->card->host->caps & MMC_CAP_POWER_OFF_CARD)
pm_runtime_put_noidle(dev);
-out:
return ret;
 }
 
-- 
1.7.4.1




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


RE: [PATCH 2/5] mmc: core: call pm_runtime_put_sync in pm_runtime_get_sync failed case

2013-04-07 Thread Li, Fei
> 
> Hi Li,
> 
> On Thu, Feb 28, 2013 at 9:44 AM, Li Fei  wrote:
> > Even in failed case of pm_runtime_get_sync, the usage_count
> > is incremented. In order to keep the usage_count with correct
> > value and runtime power management to behave correctly, call
> > pm_runtime_put(_sync) in such case.
> 
> As with the remoteproc case, it is probably better to call the
> put_noidle variant here. This way you are sure not to erroneously
> invoke any underlying pm handler where your only intention is to fix
> usage_count.

Thanks for your check and feedback, and will update it in V2 soon.

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


Re: [PATCH v4, part3 24/41] mm/m68k: prepare for removing num_physpages and simplify mem_init()

2013-04-07 Thread Greg Ungerer
On 07/04/13 00:32, Jiang Liu wrote:
> Prepare for removing num_physpages and simplify mem_init().
> 
> Signed-off-by: Jiang Liu 
> Cc: Geert Uytterhoeven 
> Cc: Greg Ungerer 

Acked-by: Greg Ungerer  Cc: linux-m...@lists.linux-m68k.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/m68k/mm/init.c |   31 ++-
>  1 file changed, 2 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
> index 2485a8c..0723141 100644
> --- a/arch/m68k/mm/init.c
> +++ b/arch/m68k/mm/init.c
> @@ -149,33 +149,11 @@ void __init print_memmap(void)
>  void __init mem_init(void)
>  {
>   pg_data_t *pgdat;
> - int codepages = 0;
> - int datapages = 0;
> - int initpages = 0;
>   int i;
>  
>   /* this will put all memory onto the freelists */
> - num_physpages = 0;
> - for_each_online_pgdat(pgdat) {
> - num_physpages += pgdat->node_present_pages;
> -
> + for_each_online_pgdat(pgdat)
>   free_all_bootmem_node(pgdat);
> - for (i = 0; i < pgdat->node_spanned_pages; i++) {
> - struct page *page = pgdat->node_mem_map + i;
> - char *addr = page_to_virt(page);
> -
> - if (!PageReserved(page))
> - continue;
> - if (addr >= _text &&
> - addr < _etext)
> - codepages++;
> - else if (addr >= __init_begin &&
> -  addr < __init_end)
> - initpages++;
> - else
> - datapages++;
> - }
> - }
>  
>  #if defined(CONFIG_MMU) && !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
>   /* insert pointer tables allocated so far into the tablelist */
> @@ -190,12 +168,7 @@ void __init mem_init(void)
>   init_pointer_table((unsigned long)zero_pgtable);
>  #endif
>  
> - pr_info("Memory: %luk/%luk available (%dk kernel code, %dk data, %dk 
> init)\n",
> -nr_free_pages() << (PAGE_SHIFT-10),
> -totalram_pages << (PAGE_SHIFT-10),
> -codepages << (PAGE_SHIFT-10),
> -datapages << (PAGE_SHIFT-10),
> -initpages << (PAGE_SHIFT-10));
> + mem_init_print_info(NULL);
>   print_memmap();
>  }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: update gpio Chinese documentation

2013-04-07 Thread Chen Baozi
Since the GENERIC_GPIO has been removed and the documentation of it
has been modified, this patch updates the corresponding documentation of
gpio in Chinese.

Signed-off-by: Chen Baozi 
---
 Documentation/zh_CN/gpio.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
index 4fa7b4e..d5b8f01 100644
--- a/Documentation/zh_CN/gpio.txt
+++ b/Documentation/zh_CN/gpio.txt
@@ -84,10 +84,10 @@ GPIO 公约
 控制器的抽象函数来实现它。(有一些可选的代码能支持这种策略的实现,本文档
 后面会介绍,但作为 GPIO 接口的客户端驱动程序必须与它的实现无关。)
 
-也就是说,如果在他们的平台上支持这个公约,驱动应尽可能的使用它。平台
-必须在 Kconfig 中声明对 GENERIC_GPIO的支持 (布尔型 true),并提供
-一个  文件。那些调用标准 GPIO 函数的驱动应该在 Kconfig
-入口中声明依赖GENERIC_GPIO。当驱动包含文件:
+也就是说,如果在他们的平台上支持这个公约,驱动应尽可能的使用它。同时,平台
+必须在 Kconfig 中选择 ARCH_REQUIRE_GPIOLIB 或者 ARCH_WANT_OPTIONAL_GPIOLIB
+选项。那些调用标准 GPIO 函数的驱动应该在 Kconfig 入口中声明依赖GENERIC_GPIO。
+当驱动包含文件:
 
#include 
 
-- 
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/


linux-next: build failure after merge of the vfs tree

2013-04-07 Thread Stephen Rothwell
Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function 'kvm_init':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2990:2: error: assignment of 
member 'owner' in read-only object
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2991:2: error: assignment of 
member 'owner' in read-only object
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2992:2: error: assignment of 
member 'owner' in read-only object

Caused by commit d612df096dce ("constify a bunch of struct
file_operations instances").  Grep is your friend ...

I have used the vfs tree from next-230130405 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgphmzrAek2LD.pgp
Description: PGP signature


Re: Linux 3.8.6

2013-04-07 Thread Lucas

On 07/04/13 15:28, Daniel Vetter wrote:

On Sun, Apr 7, 2013 at 12:56 AM, Lucas  wrote:

Thanks for reporting in.

Somehow the thread got all messed up in LKML. It didn't parse correctly
there, but it seems that Gmane did. Here is the link:

http://comments.gmane.org/gmane.linux.kernel.stable/48872


Those patches still have an unresolved regression against them.
Unfortunately  I can't reproduce it despite that I have a very similar
system, and obviously a bunch of other people like you reported that
the exact same patches which regressed actually fix the lvds panel
fitter. So for now this stays in limbo :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Ok, if you need any help with testing or anything, just tell me.
For me every release candidate of 3.9 from rc1 onwards is able to boot 
X. Hope you can hunt this regresion down.


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


Re: [RFC PATCH 0/4] Support vranges on files

2013-04-07 Thread Minchan Kim
Hello John,

As you know, userland people wanted to handle vrange with mmaped
pointer rather than fd-based and see the SIGBUS so I thought more
about semantic of vrange and want to make it very clear and easy.
So I suggest below semantic(Of course, it's not rock solid).

mvrange(start_addr, lengh, mode, behavior)

It's same with that I suggested lately but different name, just
adding prefix "m". It's per-process model(ie, mm_struct vrange)
so if process is exited, "volatility" isn't valid any more.
It isn't a problem in anonymous but could be in file-vrange so let's
introduce fvrange for covering the problem.

fvrange(int fd, start_offset, length, mode, behavior)

First of all, let's see mvrange with anonymous and file page POV.

1) anon-mvrange

The page in volaitle range will be purged only if all of processes
marked the range as volatile.

If A process calls mvrange and is forked, vrange could be copied
from parent to child so not-yet-COWed pages could be purged
unless either one of both processes marks NO_VOLATILE explicitly.

Of course, COWed page could be purged easily because there is no link
any more.

2) file-mvrange

A page in volatile range will be purged only if all of processes mapped
the page marked it as volatile AND there is no process mapped the page
as "private". IOW, all of the process mapped the page should map it
with "shared" for purging.

So, all of processes should mark each address range in own process
context if they want to collaborate with shared mapped file and gaurantee
there is no process mapped the range with "private".

Of course, volatility state will be terminated as the process is gone.

3) fvrange

It's same with 2) but volatility state could be persistent in address_space
until someone calls fvrange(NO_VOLATILE).
So it could remove the weakness of 2).
 
What do you think about above semantic?

If you don't have any problem, we could implement it. I think 1) and 2) could
be handled with my base code for anon-vrange handling with tweaking
file-vrange and need your new patches in address_space for handling 3).

On Fri, Apr 05, 2013 at 04:55:04PM +0900, Minchan Kim wrote:
> Hi John,
> 
> On Thu, Apr 04, 2013 at 10:37:52AM -0700, John Stultz wrote:
> > On 04/03/2013 11:55 PM, Minchan Kim wrote:
> > >On Wed, Apr 03, 2013 at 04:52:19PM -0700, John Stultz wrote:
> > >>Next we introduce a parallel fvrange() syscall for creating
> > >>volatile ranges directly against files.
> > >Okay. It seems you want to replace ashmem interface with fvrange.
> > >I dobut we have to eat a slot for system call. Can't we add "int fd"
> > >in vrange systemcall without inventing new wheel?
> > 
> > Sure, that would be doable. I just added the new syscall to make the
> > differences in functionality clear.
> > Once the subtleties are understood, we can condense things down if
> > we think its best.
> 
> Fair enough.
> 
> > 
> > 
> > >>And finally, we change the range pruging logic to be able to
> > >>handle both anonymous and file volatile ranges.
> > >Okay. Then, what's the semantic file-vrange?
> > >
> > >There is a file F. Process A mapped some part of file into his
> > >address space. Then, Process B calls fvrange same part.
> > >As I looked over your code, it purges the range although process B
> > >is using now. Right? Is it your intention? Maybe isn't.
> > 
> > Not sure if you're example has a type-o and you meant "process A is
> > using it"?  If so, yes. The point is the volatility is shared and
> > consistent across all users of the file, in the same way the data in
> > the file is shared. If process B punched a hole in the file, process
> > A would see the effect immediately. With volatile ranges, the hole
> > punching is just delayed and possibly done later by the kernel, in
> > effect on behalf of process B, so the behavior is the same.
> > 
> > Consider the case where we could have two processes mmap a tmpfs
> > file in order to create a circular buffer shared between them. You
> > could then have a producer/consumer relationship with two processes
> > where any data not between the head & tail offsets were marked
> > volatile. The producer would mark tail+size non-volatile, write the
> > data, and update the tail offset. The consumer would read data from
> > the head offset, mark the just-read range as volatile, and update
> > the offset.
> > 
> > In this example, the producer would be the only process to mark data
> > non-volatile, while the consumer would be the only one marking
> > ranges volatile. Thus the state of volatility would need to be an
> > attribute of the file, not the process, in the same way the shared
> > data is.
> > 
> > Is that clear?
> 
> Yes, I got your point that you meant shared mapping.
> Let's enumerate more examples.
> 
> 1. Process A mapped FILE A with MAP_SHARED
>Process B mapped FILE A with MAP_SHARED
>Process C calls fvrange
>Discard all pages of process A and B -> Make sense to me.
> 
> 2. Process A mapped FILE A with 

Re: [v5] clk: add si5351 i2c common clock driver

2013-04-07 Thread Guenter Roeck
On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:
> >>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >>i2c programmable clock generators. Currently, the driver supports
> >>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >>bindings selectively allow to overwrite stored Si5351 configuration
> >>which is very helpful for clock generators with empty eeprom
> >>configuration. Corresponding device tree binding documentation is
> >>also added.
> >>
> >>Signed-off-by: Sebastian Hesselbarth
> >>Tested-by: Daniel Mack
> >>
> >[ ... ]
> >
> >>+static inline void _si5351_msynth_set_pll_master(
> >>+   struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >>+{
> >>+   unsigned long flags;
> >>+
> >>+   if (num>  8 ||
> >>+   (drvdata->variant == SI5351_VARIANT_A3&&  num>  3))
> >>+   return;
> >>+
> >>+   flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >>+   if (is_master)
> >>+   flags |= CLK_SET_RATE_PARENT;
> >>+   else
> >>+   flags&= ~CLK_SET_RATE_PARENT;
> >>+   __clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >>+}
> >>+
> >Unless I am missing something, neither __clk_get_flags() nor the new
> >__clk_set_flags is exported.
> >
> >Did you try to build and load the driver as module ?
> 
> Well, good catch. I didn't try to build v5 as a module, but I guess it
> will fail. But I consider this as something that has to be addressed in
> clk framework itself, not in this patch. There will be other
> clk-providers built as module in the future for sure.
> 
Sure, but you provided the patch to make __clk_set_flags global. To avoid
build failures, I would suggest to either submit a patch to export the
missing functions, or to remove the ability to build the driver as module.

On a side note, do you happen to know anyone working on drivers for Si5319 or
Si5368 ?

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


[ANNOUNCE] Git v1.8.2.1

2013-04-07 Thread Junio C Hamano
The latest maintenance release Git v1.8.2.1 is now available at
the usual places.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

ad9f833e509ba31c83efe336fd3599e89a39394b  git-1.8.2.1.tar.gz
bf4abd0e020d24ee47c64760e9fe4372c596d354  git-htmldocs-1.8.2.1.tar.gz
6c40ace4682188d0c01b1091b37276151bc77a74  git-manpages-1.8.2.1.tar.gz

Also the following public repositories all have a copy of the v1.8.2.1
tag and the maint branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v1.8.2.1 Release Notes
==

Fixes since v1.8.2
--

 * An earlier change to the attribute system introduced at v1.8.1.2 by
   mistake stopped a pattern "dir" (without trailing slash) from
   matching a directory "dir" (it only wanted to allow pattern "dir/"
   to also match).

 * Verification of signed tags were not done correctly when not in C
   or en/US locale.

 * 'git commit -m "$msg"' used to add an extra newline even when
   $msg already ended with one.

 * The "--match=" option of "git describe", when used with
   "--all" to allow refs that are not annotated tags to be used as a
   base of description, did not restrict the output from the command
   to those that match the given pattern.

 * An aliased command spawned from a bare repository that does not say
   it is bare with "core.bare = yes" is treated as non-bare by mistake.

 * When "format-patch" quoted a non-ascii strings on the header files,
   it incorrectly applied rfc2047 and chopped a single character in
   the middle of it.

 * "git archive" reports a failure when asked to create an archive out
   of an empty tree.  It would be more intuitive to give an empty
   archive back in such a case.

 * "git tag -f " always said "Updated tag ''" even when
   creating a new tag (i.e. not overwriting nor updating).

 * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and
   instead the parser kept reading beyond the end of the string.

 * Annotated tags outside refs/tags/ hierarchy were not advertised
   correctly to the ls-remote and fetch with recent version of Git.

 * The code to keep track of what directory names are known to Git on
   platforms with case insensitive filesystems can get confused upon a
   hash collision between these pathnames and looped forever.

 * The logic used by "git diff -M --stat" to shorten the names of
   files before and after a rename did not work correctly when the
   common prefix and suffix between the two filenames overlapped.

 * "git submodule update", when recursed into sub-submodules, did not
   acccumulate the prefix paths.

 * "git am $maildir/" applied messages in an unexpected order; sort
   filenames read from the maildir/ in a way that is more likely to
   sort messages in the order the writing MUA meant to, by sorting
   numeric segment in numeric order and non-numeric segment in
   alphabetical order.

 * When export-subst is used, "zip" output recorded incorrect
   size of the file.

 * Some platforms and users spell UTF-8 differently; retry with the
   most official "UTF-8" when the system does not understand the
   user-supplied encoding name that are the common alternative
   spellings of UTF-8.

 * "git branch" did not bother to check nonsense command line
   parameters and issue errors in many cases.

 * "git update-index -h" did not do the usual "-h(elp)" thing.

 * perl/Git.pm::cat_blob slurped everything in core only to write it
   out to a file descriptor, which was not a very smart thing to do.

 * The SSL peer verification done by "git imap-send" did not ask for
   Server Name Indication (RFC 4366), failing to connect SSL/TLS
   sites that serve multiple hostnames on a single IP.

 * "git index-pack" had a buffer-overflow while preparing an
   informational message when the translated version of it was too
   long.

 * Clarify in the documentation "what" gets pushed to "where" when the
   command line to "git push" does not say these explicitly.

 * In "git reflog expire", REACHABLE bit was not cleared from the
   correct objects.

 * The "--color=" argument to the commands in the diff family
   was described poorly.

 * The arguments given to pre-rebase hook were not documented.

 * The v4 index format was not documented.

 * The "--match=" argument "git describe" takes uses glob
   pattern but it wasn't obvious from the documentation.

 * Some sources failed to compile on systems that lack NI_MAXHOST in
   their system header (e.g. z/OS).

 * Add an example use of "--env-filter" in "filter-branch"
   documentation.

 * "git bundle verify" did not say "records a complete history" for a
   bundle that does not have 

[ANNOUNCE] Git v1.8.1.6

2013-04-07 Thread Junio C Hamano
A maintenance release Git v1.8.1.6 is now available at the
usual places.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

135a4fd6c025ab16560694da110a1476a9b83de2  git-1.8.1.6.tar.gz
a9b004bf1b1922f09cb45a7a388bd452399db30c  git-htmldocs-1.8.1.6.tar.gz
41822cdd469fde30d419819e43ed57f3e73a404b  git-manpages-1.8.1.6.tar.gz

Also the following public repositories all have a copy of the v1.8.1.6
tag and the maint-1.8.1 branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git 1.8.1.6 Release Notes
=

Fixes since v1.8.1.5


 * An earlier change to the attribute system introduced at v1.8.1.2 by
   mistake stopped a pattern "dir" (without trailing slash) from
   matching a directory "dir" (it only wanted to allow pattern "dir/"
   to also match).

 * The code to keep track of what directory names are known to Git on
   platforms with case insensitive filesystems can get confused upon a
   hash collision between these pathnames and looped forever.

 * When the "--prefix" option is used to "checkout-index", the code
   did not pick the correct output filter based on the attribute
   setting.

 * Annotated tags outside refs/tags/ hierarchy were not advertised
   correctly to the ls-remote and fetch with recent version of Git.

 * The logic used by "git diff -M --stat" to shorten the names of
   files before and after a rename did not work correctly when the
   common prefix and suffix between the two filenames overlapped.

 * "git update-index -h" did not do the usual "-h(elp)" thing.

 * perl/Git.pm::cat_blob slurped everything in core only to write it
   out to a file descriptor, which was not a very smart thing to do.

 * The SSL peer verification done by "git imap-send" did not ask for
   Server Name Indication (RFC 4366), failing to connect SSL/TLS
   sites that serve multiple hostnames on a single IP.

 * "git bundle verify" did not say "records a complete history" for a
   bundle that does not have any prerequisites.

Also contains various documentation fixes.



Changes since v1.8.1.5 are as follows:

Antoine Pelisse (4):
  update-index: allow "-h" to also display options
  diff: Fix rename pretty-print when suffix and prefix overlap
  tests: make sure rename pretty print works
  perf: update documentation of GIT_PERF_REPEAT_COUNT

Christian Helmuth (1):
  git-commit doc: describe use of multiple `-m` options

Dan Bornstein (1):
  Correct the docs about GIT_SSH.

David Michael (1):
  git-compat-util.h: Provide missing netdb.h definitions

Fredrik Gustafsson (1):
  gitweb/README: remove reference to git.kernel.org

Greg Price (1):
  describe: Document --match pattern format

Jeff King (6):
  avoid segfaults on parse_object failure
  use parse_object_or_die instead of die("bad object")
  pack-refs: write peeled entry for non-tags
  dir.c::match_pathname(): adjust patternlen when shifting pattern
  dir.c::match_pathname(): pay attention to the length of string parameters
  t: check that a pattern without trailing slash matches a directory

Johannes Sixt (1):
  t2003: work around path mangling issue on Windows

John Keeping (3):
  t2003: modernize style
  entry: fix filter lookup
  merge-tree: fix typo in merge-tree.c::unresolved

Joshua Clayton (1):
  Git.pm: fix cat_blob crashes on large files

Junio C Hamano (8):
  imap-send: support Server Name Indication (RFC4366)
  diff-options: unconfuse description of --color
  Documentation: merging a tag is a special case
  attr.c::path_matches(): the basename is part of the pathname
  attr.c::path_matches(): special case paths that end with a slash
  dir.c::match_basename(): pay attention to the length of string parameters
  Start preparing for 1.8.1.6
  Git 1.8.1.6

Kacper Kornet (3):
  rev-parse: clarify documentation of $name@{upstream} syntax
  t1507: Test that branchname@{upstream} is interpreted as branch
  Fix revision walk for commits with the same dates

Karsten Blees (1):
  name-hash.c: fix endless loop with core.ignorecase=true

Kevin Bracey (2):
  Translate git_more_info_string consistently
  git.c: make usage match manual page

Lukas Fleischer (2):
  bundle: Fix "verify" output if history is complete
  bundle: Add colons to list headings in "verify"

Matthias Krüger (1):
  git help config: s/insn/instruction/

Michael Haggerty (2):
  Provide a mechanism to turn off symlink resolution in ceiling paths
  pack-refs: add fully-peeled trait

Mihai 

[PATCH] ALSA: hda: fix mute led on HP Envy 15

2013-04-07 Thread Dan Savilonis
This laptop reports the string HP_Mute_LED_P_G in DMI, but the guess made in
hp_set_mute_led() is wrong. So, hard-code the GPIO id.

Signed-off-by: Dan Savilonis 
---
 sound/pci/hda/patch_sigmatel.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 1d9d642..3a6b111 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -100,6 +100,7 @@ enum {
STAC_92HD83XXX_HEADSET_JACK,
STAC_92HD83XXX_HP,
STAC_HP_ENVY_BASS,
+   STAC_HP_ENVY_15,
STAC_92HD83XXX_MODELS
 };
 
@@ -2092,6 +2093,15 @@ static void stac92hd83xxx_fixup_hp_mic_led(struct 
hda_codec *codec,
spec->mic_mute_led_gpio = 0x08; /* GPIO3 */
 }
 
+static void stac92hd83xxx_fixup_hp_envy_15(struct hda_codec *codec,
+  const struct hda_fixup *fix, int action)
+{
+   struct sigmatel_spec *spec = codec->spec;
+
+   if (action == HDA_FIXUP_ACT_PRE_PROBE)
+   spec->gpio_led = 0x01; /* GPIO0 */
+}
+
 static void stac92hd83xxx_fixup_headset_jack(struct hda_codec *codec,
   const struct hda_fixup *fix, int action)
 {
@@ -2101,6 +2111,7 @@ static void stac92hd83xxx_fixup_headset_jack(struct 
hda_codec *codec,
spec->headset_jack = 1;
 }
 
+
 static const struct hda_fixup stac92hd83xxx_fixups[] = {
[STAC_92HD83XXX_REF] = {
.type = HDA_FIXUP_PINS,
@@ -2169,6 +2180,12 @@ static const struct hda_fixup stac92hd83xxx_fixups[] = {
{}
},
},
+   [STAC_HP_ENVY_15] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = stac92hd83xxx_fixup_hp_envy_15,
+   .chained = true,
+   .chain_id = STAC_92HD83XXX_HP,
+   },
 };
 
 static const struct hda_model_fixup stac92hd83xxx_models[] = {
@@ -2184,6 +2201,7 @@ static const struct hda_model_fixup 
stac92hd83xxx_models[] = {
{ .id = STAC_92HD83XXX_HP_MIC_LED, .name = "hp-mic-led" },
{ .id = STAC_92HD83XXX_HEADSET_JACK, .name = "headset-jack" },
{ .id = STAC_HP_ENVY_BASS, .name = "hp-envy-bass" },
+   { .id = STAC_HP_ENVY_15, .name = "hp-envy-15" },
{}
 };
 
@@ -2269,6 +2287,8 @@ static const struct snd_pci_quirk 
stac92hd83xxx_fixup_tbl[] = {
  "HP Pavilion dv5", STAC_92HD83XXX_HP_INV_LED),
SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x148a,
  "HP Mini", STAC_92HD83XXX_HP_LED),
+   SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1688,
+ "HP Envy 15", STAC_HP_ENVY_15),
SND_PCI_QUIRK_VENDOR(PCI_VENDOR_ID_HP, "HP", STAC_92HD83XXX_HP),
{} /* terminator */
 };
@@ -3968,6 +3988,7 @@ static int patch_stac92hd83xxx(struct hda_codec *codec)
 
snd_hda_add_verbs(codec, stac92hd83xxx_core_init);
 
+
snd_hda_pick_fixup(codec, stac92hd83xxx_models, stac92hd83xxx_fixup_tbl,
   stac92hd83xxx_fixups);
snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_PRE_PROBE);
-- 
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: [v5] clk: add si5351 i2c common clock driver

2013-04-07 Thread Sebastian Hesselbarth

On 04/08/2013 12:50 AM, Guenter Roeck wrote:

On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarth
Tested-by: Daniel Mack


[ ... ]


+static inline void _si5351_msynth_set_pll_master(
+   struct si5351_driver_data *drvdata, unsigned char num, int is_master)
+{
+   unsigned long flags;
+
+   if (num>  8 ||
+   (drvdata->variant == SI5351_VARIANT_A3&&  num>  3))
+   return;
+
+   flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
+   if (is_master)
+   flags |= CLK_SET_RATE_PARENT;
+   else
+   flags&= ~CLK_SET_RATE_PARENT;
+   __clk_set_flags(drvdata->msynth[num].hw.clk, flags);
+}
+

Unless I am missing something, neither __clk_get_flags() nor the new
__clk_set_flags is exported.

Did you try to build and load the driver as module ?


Well, good catch. I didn't try to build v5 as a module, but I guess it
will fail. But I consider this as something that has to be addressed in
clk framework itself, not in this patch. There will be other
clk-providers built as module in the future for sure.

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/


[53/74] sky2: Threshold for Pause Packet is set wrong

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mirko Lindner 

[ Upstream commit 74f9f42c1c1650e74fb464f76644c9041f996851 ]

The sky2 driver sets the Rx Upper Threshold for Pause Packet generation to a
wrong value which leads to only 2kB of RAM remaining space. This can lead to
Rx overflow errors even with activated flow-control.

Fix: We should increase the value to 8192/8

Signed-off-by: Mirko Lindner 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/marvell/sky2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/sky2.c 
b/drivers/net/ethernet/marvell/sky2.c
index 69fc888..94f9a8f 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -1066,7 +1066,7 @@ static void sky2_ramset(struct sky2_hw *hw, u16 q, u32 
start, u32 space)
sky2_write32(hw, RB_ADDR(q, RB_RX_UTHP), tp);
sky2_write32(hw, RB_ADDR(q, RB_RX_LTHP), space/2);
 
-   tp = space - 2048/8;
+   tp = space - 8192/8;
sky2_write32(hw, RB_ADDR(q, RB_RX_UTPP), tp);
sky2_write32(hw, RB_ADDR(q, RB_RX_LTPP), space/4);
} else {

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


[32/74] vt: synchronize_rcu() under spinlock is not nice...

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Al Viro 

commit e8cd8169315db57d3c9aa7dd90eda4842874 upstream.

vcs_poll_data_free() calls unregister_vt_notifier(), which calls
atomic_notifier_chain_unregister(), which calls synchronize_rcu().
Do it *after* we'd dropped ->f_lock.

Signed-off-by: Al Viro 
Signed-off-by: Ben Hutchings 
---
 drivers/tty/vt/vc_screen.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index e4ca345..d7799de 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -93,7 +93,7 @@ vcs_poll_data_free(struct vcs_poll_data *poll)
 static struct vcs_poll_data *
 vcs_poll_data_get(struct file *file)
 {
-   struct vcs_poll_data *poll = file->private_data;
+   struct vcs_poll_data *poll = file->private_data, *kill = NULL;
 
if (poll)
return poll;
@@ -122,10 +122,12 @@ vcs_poll_data_get(struct file *file)
file->private_data = poll;
} else {
/* someone else raced ahead of us */
-   vcs_poll_data_free(poll);
+   kill = poll;
poll = file->private_data;
}
spin_unlock(>f_lock);
+   if (kill)
+   vcs_poll_data_free(kill);
 
return poll;
 }

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


[29/74] staging: comedi: s626: fix continuous acquisition

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ian Abbott 

commit e4317ce877a31dbb9d96375391c1c4ad2210d637 upstream.

For the s626 driver, there is a bug in the handling of asynchronous
commands on the AI subdevice when the stop source is `TRIG_NONE`.  The
command should run continuously until cancelled, but the interrupt
handler stops the command running after the first scan.

The command set-up function `s626_ai_cmd()` contains this code:

switch (cmd->stop_src) {
case TRIG_COUNT:
/*  data arrives as one packet */
devpriv->ai_sample_count = cmd->stop_arg;
devpriv->ai_continous = 0;
break;
case TRIG_NONE:
/*  continous acquisition */
devpriv->ai_continous = 1;
devpriv->ai_sample_count = 0;
break;
}

The interrupt handler `s626_irq_handler()` contains this code:

if (!(devpriv->ai_continous))
devpriv->ai_sample_count--;
if (devpriv->ai_sample_count <= 0) {
devpriv->ai_cmd_running = 0;
/* ... */
}

So `devpriv->ai_sample_count` is only decremented for the `TRIG_COUNT`
case, but `devpriv->ai_cmd_running` is set to 0 (and the command
stopped) regardless.

Fix this in `s626_ai_cmd()` by setting `devpriv->ai_sample_count = 1`
for the `TRIG_NONE` case.  The interrupt handler will not decrement it
so it will remain greater than 0 and the check for stopping the
acquisition will fail.

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/comedi/drivers/s626.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -1882,7 +1882,7 @@ static int s626_ai_cmd(struct comedi_dev
case TRIG_NONE:
/*  continous acquisition */
devpriv->ai_continous = 1;
-   devpriv->ai_sample_count = 0;
+   devpriv->ai_sample_count = 1;
break;
}
 

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


[48/74] key: Fix resource leak

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alan Cox 

commit a84a921978b7d56e0e4b87ffaca6367429b4d8ff upstream.

On an error iov may still have been reallocated and need freeing

Signed-off-by: Alan Cox 
Signed-off-by: David Howells 
Signed-off-by: Ben Hutchings 
---
 security/keys/keyctl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1067,12 +1067,12 @@ long keyctl_instantiate_key_iov(key_seri
ret = rw_copy_check_uvector(WRITE, _payload_iov, ioc,
ARRAY_SIZE(iovstack), iovstack, , 1);
if (ret < 0)
-   return ret;
+   goto err;
if (ret == 0)
goto no_payload_free;
 
ret = keyctl_instantiate_key_common(id, iov, ioc, ret, ringid);
-
+err:
if (iov != iovstack)
kfree(iov);
return ret;

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


[26/74] IPoIB: Fix send lockup due to missed TX completion

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mike Marciniszyn 

commit 1ee9e2aa7b31427303466776f455d43e5e3c9275 upstream.

Commit f0dc117abdfa ("IPoIB: Fix TX queue lockup with mixed UD/CM
traffic") attempts to solve an issue where unprocessed UD send
completions can deadlock the netdev.

The patch doesn't fully resolve the issue because if more than half
the tx_outstanding's were UD and all of the destinations are RC
reachable, arming the CQ doesn't solve the issue.

This patch uses the IB_CQ_REPORT_MISSED_EVENTS on the
ib_req_notify_cq().  If the rc is above 0, the UD send cq completion
callback is called directly to re-arm the send completion timer.

This issue is seen in very large parallel filesystem deployments
and the patch has been shown to correct the issue.

Reviewed-by: Dean Luick 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Roland Dreier 
Signed-off-by: Ben Hutchings 
---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -755,9 +755,13 @@ void ipoib_cm_send(struct net_device *de
if (++priv->tx_outstanding == ipoib_sendq_size) {
ipoib_dbg(priv, "TX ring 0x%x full, stopping kernel net 
queue\n",
  tx->qp->qp_num);
-   if (ib_req_notify_cq(priv->send_cq, IB_CQ_NEXT_COMP))
-   ipoib_warn(priv, "request notify on send CQ 
failed\n");
netif_stop_queue(dev);
+   rc = ib_req_notify_cq(priv->send_cq,
+   IB_CQ_NEXT_COMP | IB_CQ_REPORT_MISSED_EVENTS);
+   if (rc < 0)
+   ipoib_warn(priv, "request notify on send CQ 
failed\n");
+   else if (rc)
+   ipoib_send_comp_handler(priv->send_cq, dev);
}
}
 }

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


[42/74] virtio: console: add locking around c_ovq operations

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Amit Shah 

commit 9ba5c80b1aea8648a3efe5f22dc1f7cacdfbeeb8 upstream.

When multiple ovq operations are being performed (lots of open/close
operations on virtio_console fds), the __send_control_msg() function can
get confused without locking.

A simple recipe to cause badness is:
* create a QEMU VM with two virtio-serial ports
* in the guest, do
  while true;do echo abc >/dev/vport0p1;done
  while true;do echo edf >/dev/vport0p2;done

In one run, this caused a panic in __send_control_msg().  In another, I
got

   virtio_console virtio0: control-o:id 0 is not a head!

This also results repeated messages similar to these on the host:

  qemu-kvm: virtio-serial-bus: Unexpected port id 478762112 for device 
virtio-serial-bus.0
  qemu-kvm: virtio-serial-bus: Unexpected port id 478762368 for device 
virtio-serial-bus.0

Reported-by: FuXiangChun 
Signed-off-by: Amit Shah 
Reviewed-by: Wanlong Gao 
Reviewed-by: Asias He 
Signed-off-by: Rusty Russell 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/char/virtio_console.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -132,6 +132,7 @@ struct ports_device {
 
/* To protect the vq operations for the control channel */
spinlock_t c_ivq_lock;
+   spinlock_t c_ovq_lock;
 
/* The current config space is stored here */
struct virtio_console_config config;
@@ -457,11 +458,14 @@ static ssize_t __send_control_msg(struct
vq = portdev->c_ovq;
 
sg_init_one(sg, , sizeof(cpkt));
+
+   spin_lock(>c_ovq_lock);
if (virtqueue_add_buf(vq, sg, 1, 0, ) >= 0) {
virtqueue_kick(vq);
while (!virtqueue_get_buf(vq, ))
cpu_relax();
}
+   spin_unlock(>c_ovq_lock);
return 0;
 }
 
@@ -1722,6 +1726,7 @@ static int __devinit virtcons_probe(stru
unsigned int nr_added_bufs;
 
spin_lock_init(>c_ivq_lock);
+   spin_lock_init(>c_ovq_lock);
INIT_WORK(>control_work, _work_handler);
 
nr_added_bufs = fill_queue(portdev->c_ivq,

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


[33/74] iommu/amd: Make sure dma_ops are set for hotplug devices

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Joerg Roedel 

commit c2a2876e863356b092967ea62bebdb4dd663af80 upstream.

There is a bug introduced with commit 27c2127 that causes
devices which are hot unplugged and then hot-replugged to
not have per-device dma_ops set. This causes these devices
to not function correctly. Fixed with this patch.

Reported-by: Andreas Degert 
Signed-off-by: Joerg Roedel 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1874,16 +1874,16 @@ static int device_change_notifier(struct
 
/* allocate a protection domain if a device is added */
dma_domain = find_protection_domain(devid);
-   if (dma_domain)
-   goto out;
-   dma_domain = dma_ops_domain_alloc();
-   if (!dma_domain)
-   goto out;
-   dma_domain->target_dev = devid;
+   if (!dma_domain) {
+   dma_domain = dma_ops_domain_alloc();
+   if (!dma_domain)
+   goto out;
+   dma_domain->target_dev = devid;
 
-   spin_lock_irqsave(_pd_list_lock, flags);
-   list_add_tail(_domain->list, _pd_list);
-   spin_unlock_irqrestore(_pd_list_lock, flags);
+   spin_lock_irqsave(_pd_list_lock, flags);
+   list_add_tail(_domain->list, _pd_list);
+   spin_unlock_irqrestore(_pd_list_lock, flags);
+   }
 
dev->archdata.dma_ops = _iommu_dma_ops;
 

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


[10/74] Bluetooth: Device 0cf3:3008 should map AR 3012

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sunguk Lee 

commit 94a32d10f47b637ae24b78b1ddc7ef0e8396fda4 upstream.

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=3008 Rev= 0.01
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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

Signed-off-by: Sunguk Lee 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Ben Hutchings 
---
 drivers/bluetooth/ath3k.c |2 ++
 drivers/bluetooth/btusb.c |1 +
 2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -73,6 +73,7 @@ static struct usb_device_id ath3k_table[
 
/* Atheros AR3012 with sflash firmware*/
{ USB_DEVICE(0x0CF3, 0x3004) },
+   { USB_DEVICE(0x0CF3, 0x3008) },
{ USB_DEVICE(0x0CF3, 0x311D) },
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3004) },
@@ -106,6 +107,7 @@ static struct usb_device_id ath3k_blist_
 
/* Atheros AR3012 with sflash firmware*/
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -140,6 +140,7 @@ static struct usb_device_id blacklist_ta
 
/* Atheros 3012 with sflash firmware */
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },

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


[25/74] ASoC: dma-sh7760: Fix compile error

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit 417a1178f1bf3cdc606376b3ded3a22489fbb3eb upstream.

The dma-sh7760 currently fails with the following compile error:
sound/soc/sh/dma-sh7760.c:346:2: error: unknown field 'pcm_ops' 
specified in initializer
sound/soc/sh/dma-sh7760.c:346:2: warning: initialization from 
incompatible pointer type
sound/soc/sh/dma-sh7760.c:347:2: error: unknown field 'pcm_new' 
specified in initializer
sound/soc/sh/dma-sh7760.c:347:2: warning: initialization makes integer 
from pointer without a cast
sound/soc/sh/dma-sh7760.c:348:2: error: unknown field 'pcm_free' 
specified in initializer
sound/soc/sh/dma-sh7760.c:348:2: warning: initialization from 
incompatible pointer type
sound/soc/sh/dma-sh7760.c: In function 'sh7760_soc_platform_probe':
sound/soc/sh/dma-sh7760.c:353:2: warning: passing argument 2 of 
'snd_soc_register_platform' from incompatible pointer type
include/sound/soc.h:368:5: note: expected 'struct 
snd_soc_platform_driver *' but argument is of type 'struct snd_soc_platform *'

This is due the misnaming of the snd_soc_platform_driver type name and 'ops'
field. The issue was introduced in commit f0fba2a("ASoC: multi-component - ASoC
Multi-Component Support").

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings 
---
 sound/soc/sh/dma-sh7760.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/dma-sh7760.c b/sound/soc/sh/dma-sh7760.c
index 19eff8f..1a8b03e 100644
--- a/sound/soc/sh/dma-sh7760.c
+++ b/sound/soc/sh/dma-sh7760.c
@@ -342,8 +342,8 @@ static int camelot_pcm_new(struct snd_soc_pcm_runtime *rtd)
return 0;
 }
 
-static struct snd_soc_platform sh7760_soc_platform = {
-   .pcm_ops= _pcm_ops,
+static struct snd_soc_platform_driver sh7760_soc_platform = {
+   .ops= _pcm_ops,
.pcm_new= camelot_pcm_new,
.pcm_free   = camelot_pcm_free,
 };

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


[37/74] Btrfs: limit the global reserve to 512mb

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Josef Bacik 

commit fdf30d1c1b386e1b73116cc7e0fb14e962b763b0 upstream.

A user reported a problem where he was getting early ENOSPC with hundreds of
gigs of free data space and 6 gigs of free metadata space.  This is because the
global block reserve was taking up the entire free metadata space.  This is
ridiculous, we have infrastructure in place to throttle if we start using too
much of the global reserve, so instead of letting it get this huge just limit it
to 512mb so that users can still get work done.  This allowed the user to
complete his rsync without issues.  Thanks

Reported-and-tested-by: Stefan Priebe 
Signed-off-by: Josef Bacik 
Signed-off-by: Ben Hutchings 
---
 fs/btrfs/extent-tree.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3996,7 +3996,7 @@ static void update_global_block_rsv(stru
spin_lock(_rsv->lock);
spin_lock(>lock);
 
-   block_rsv->size = num_bytes;
+   block_rsv->size = min_t(u64, num_bytes, 512 * 1024 * 1024);
 
num_bytes = sinfo->bytes_used + sinfo->bytes_pinned +
sinfo->bytes_reserved + sinfo->bytes_readonly +

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


[41/74] virtio: console: rename cvq_lock to c_ivq_lock

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Amit Shah 

commit 165b1b8bbc17c9469b053bab78b11b7cbce6d161 upstream.

The cvq_lock was taken for the c_ivq.  Rename the lock to make that
obvious.

We'll also add a lock around the c_ovq in the next commit, so there's no
ambiguity.

Signed-off-by: Amit Shah 
Reviewed-by: Asias He 
Reviewed-by: Wanlong Gao 
Signed-off-by: Rusty Russell 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change to virtcons_restore()]
Signed-off-by: Ben Hutchings 
---
 drivers/char/virtio_console.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -131,7 +131,7 @@ struct ports_device {
spinlock_t ports_lock;
 
/* To protect the vq operations for the control channel */
-   spinlock_t cvq_lock;
+   spinlock_t c_ivq_lock;
 
/* The current config space is stored here */
struct virtio_console_config config;
@@ -1466,23 +1466,23 @@ static void control_work_handler(struct
portdev = container_of(work, struct ports_device, control_work);
vq = portdev->c_ivq;
 
-   spin_lock(>cvq_lock);
+   spin_lock(>c_ivq_lock);
while ((buf = virtqueue_get_buf(vq, ))) {
-   spin_unlock(>cvq_lock);
+   spin_unlock(>c_ivq_lock);
 
buf->len = len;
buf->offset = 0;
 
handle_control_message(portdev, buf);
 
-   spin_lock(>cvq_lock);
+   spin_lock(>c_ivq_lock);
if (add_inbuf(portdev->c_ivq, buf) < 0) {
dev_warn(>vdev->dev,
 "Error adding buffer to queue\n");
free_buf(buf);
}
}
-   spin_unlock(>cvq_lock);
+   spin_unlock(>c_ivq_lock);
 }
 
 static void out_intr(struct virtqueue *vq)
@@ -1721,10 +1721,11 @@ static int __devinit virtcons_probe(stru
if (multiport) {
unsigned int nr_added_bufs;
 
-   spin_lock_init(>cvq_lock);
+   spin_lock_init(>c_ivq_lock);
INIT_WORK(>control_work, _work_handler);
 
-   nr_added_bufs = fill_queue(portdev->c_ivq, >cvq_lock);
+   nr_added_bufs = fill_queue(portdev->c_ivq,
+  >c_ivq_lock);
if (!nr_added_bufs) {
dev_err(>dev,
"Error allocating buffers for control queue\n");

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


[20/74] net/irda: add missing error path release_sock call

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kees Cook 

commit 896ee0eee6261e30c3623be931c3f621428947df upstream.

This makes sure that release_sock is called for all error conditions in
irda_getsockopt.

Signed-off-by: Kees Cook 
Reported-by: Brad Spengler 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/irda/af_irda.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -2584,8 +2584,10 @@ bed:
NULL, NULL, NULL);
 
/* Check if the we got some results */
-   if (!self->cachedaddr)
-   return -EAGAIN; /* Didn't find any devices */
+   if (!self->cachedaddr) {
+   err = -EAGAIN;  /* Didn't find any devices */
+   goto out;
+   }
daddr = self->cachedaddr;
/* Cleanup */
self->cachedaddr = 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/


[21/74] sysfs: fix race between readdir and lseek

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ming Lei 

commit 991f76f837bf22c5bb07261cfd86525a0a96650c upstream.

While readdir() is running, lseek() may set filp->f_pos as zero,
then may leave filp->private_data pointing to one sysfs_dirent
object without holding its reference counter, so the sysfs_dirent
object may be used after free in next readdir().

This patch holds inode->i_mutex to avoid the problem since
the lock is always held in readdir path.

Reported-by: Dave Jones 
Tested-by: Sasha Levin 
Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: open-code file_inode() which we don't have]
Signed-off-by: Ben Hutchings 
---
 fs/sysfs/dir.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -1023,10 +1023,21 @@ static int sysfs_readdir(struct file * f
return 0;
 }
 
+static loff_t sysfs_dir_llseek(struct file *file, loff_t offset, int whence)
+{
+   struct inode *inode = file->f_path.dentry->d_inode;
+   loff_t ret;
+
+   mutex_lock(>i_mutex);
+   ret = generic_file_llseek(file, offset, whence);
+   mutex_unlock(>i_mutex);
+
+   return ret;
+}
 
 const struct file_operations sysfs_dir_operations = {
.read   = generic_read_dir,
.readdir= sysfs_readdir,
.release= sysfs_dir_release,
-   .llseek = generic_file_llseek,
+   .llseek = sysfs_dir_llseek,
 };

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


[30/74] nfsd4: reject "negative" acl lengths

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "J. Bruce Fields" 

commit 64a817cfbded8674f345d1117b117f942a351a69 upstream.

Since we only enforce an upper bound, not a lower bound, a "negative"
length can get through here.

The symptom seen was a warning when we attempt to a kmalloc with an
excessive size.

Reported-by: Toralf Förster 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Ben Hutchings 
---
 fs/nfsd/nfs4xdr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -280,7 +280,7 @@ nfsd4_decode_fattr(struct nfsd4_compound
iattr->ia_valid |= ATTR_SIZE;
}
if (bmval[0] & FATTR4_WORD0_ACL) {
-   int nace;
+   u32 nace;
struct nfs4_ace *ace;
 
READ_BUF(4); len += 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/


[34/74] can: sja1000: fix define conflict on SH

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Marc Kleine-Budde 

commit f901b6bc404b67d96eca739857c097e022727b71 upstream.

Thias patch fixes a define conflict between the SH architecture and the sja1000
driver:

drivers/net/can/sja1000/sja1000.h:59:0: warning:
"REG_SR" redefined [enabled by default]
arch/sh/include/asm/ptrace_32.h:25:0: note:
 this is the location of the previous definition

A SJA1000_ prefix is added to the offending sja1000 define only, to make a
minimal patch suited for stable. A later patch will add a SJA1000_ prefix to
all defines in sja1000.h.

Reported-by: Fengguang Wu 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings 
---
 drivers/net/can/sja1000/plx_pci.c |4 ++--
 drivers/net/can/sja1000/sja1000.c |6 +++---
 drivers/net/can/sja1000/sja1000.h |2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -309,7 +309,7 @@ static inline int plx_pci_check_sja1000(
 */
if ((priv->read_reg(priv, REG_CR) & REG_CR_BASICCAN_INITIAL_MASK) ==
REG_CR_BASICCAN_INITIAL &&
-   (priv->read_reg(priv, REG_SR) == REG_SR_BASICCAN_INITIAL) &&
+   (priv->read_reg(priv, SJA1000_REG_SR) == REG_SR_BASICCAN_INITIAL) &&
(priv->read_reg(priv, REG_IR) == REG_IR_BASICCAN_INITIAL))
flag = 1;
 
@@ -321,7 +321,7 @@ static inline int plx_pci_check_sja1000(
 * See states on p. 23 of the Datasheet.
 */
if (priv->read_reg(priv, REG_MOD) == REG_MOD_PELICAN_INITIAL &&
-   priv->read_reg(priv, REG_SR) == REG_SR_PELICAN_INITIAL &&
+   priv->read_reg(priv, SJA1000_REG_SR) == REG_SR_PELICAN_INITIAL &&
priv->read_reg(priv, REG_IR) == REG_IR_PELICAN_INITIAL)
return flag;
 
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -91,7 +91,7 @@ static void sja1000_write_cmdreg(struct
 */
spin_lock_irqsave(>cmdreg_lock, flags);
priv->write_reg(priv, REG_CMR, val);
-   priv->read_reg(priv, REG_SR);
+   priv->read_reg(priv, SJA1000_REG_SR);
spin_unlock_irqrestore(>cmdreg_lock, flags);
 }
 
@@ -497,7 +497,7 @@ irqreturn_t sja1000_interrupt(int irq, v
 
while ((isrc = priv->read_reg(priv, REG_IR)) && (n < SJA1000_MAX_IRQ)) {
n++;
-   status = priv->read_reg(priv, REG_SR);
+   status = priv->read_reg(priv, SJA1000_REG_SR);
/* check for absent controller due to hw unplug */
if (status == 0xFF && sja1000_is_absent(priv))
return IRQ_NONE;
@@ -516,7 +516,7 @@ irqreturn_t sja1000_interrupt(int irq, v
/* receive interrupt */
while (status & SR_RBS) {
sja1000_rx(dev);
-   status = priv->read_reg(priv, REG_SR);
+   status = priv->read_reg(priv, SJA1000_REG_SR);
/* check for absent controller */
if (status == 0xFF && sja1000_is_absent(priv))
return IRQ_NONE;
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -56,7 +56,7 @@
 /* SJA1000 registers - manual section 6.4 (Pelican Mode) */
 #define REG_MOD0x00
 #define REG_CMR0x01
-#define REG_SR 0x02
+#define SJA1000_REG_SR 0x02
 #define REG_IR 0x03
 #define REG_IER0x04
 #define REG_ALC0x0B

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


[19/74] xen-blkback: fix dispatch_rw_block_io() error path

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 

commit 0e5e098ac22dae38f957e951b70d3cf73beff0f7 upstream.

Commit 7708992 ("xen/blkback: Seperate the bio allocation and the bio
submission") consolidated the pendcnt updates to just a single write,
neglecting the fact that the error path relied on it getting set to 1
up front (such that the decrement in __end_block_io_op() would actually
drop the count to zero, triggering the necessary cleanup actions).

Also remove a misleading and a stale (after said commit) comment.

Signed-off-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings 
---
 drivers/block/xen-blkback/blkback.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -758,13 +758,7 @@ static int dispatch_rw_block_io(struct x
}
}
 
-   /*
-* We set it one so that the last submit_bio does not have to call
-* atomic_inc.
-*/
atomic_set(_req->pendcnt, nbio);
-
-   /* Get a reference count for the disk queue and start sending I/O */
blk_start_plug();
 
for (i = 0; i < nbio; i++)
@@ -792,6 +786,7 @@ static int dispatch_rw_block_io(struct x
  fail_put_bio:
for (i = 0; i < nbio; i++)
bio_put(biolist[i]);
+   atomic_set(_req->pendcnt, 1);
__end_block_io_op(pending_req, -EINVAL);
msleep(1); /* back off a bit */
return -EIO;

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


[40/74] tile: expect new initramfs name from hypervisor file system

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Chris Metcalf 

commit ff7f3efb9abf986f4ecd8793a9593f7ca4d6431a upstream.

The current Tilera boot infrastructure now provides the initramfs
to Linux as a Tilera-hypervisor file named "initramfs", rather than
"initramfs.cpio.gz", as before.  (This makes it reasonable to use
other compression techniques than gzip on the file without having to
worry about the name causing confusion.)  Adapt to use the new name,
but also fall back to checking for the old name.

Cc'ing to stable so that older kernels will remain compatible with
newer Tilera boot infrastructure.

Signed-off-by: Chris Metcalf 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 arch/tile/kernel/setup.c |   25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -914,7 +914,7 @@ void __cpuinit setup_cpu(int boot)
 #ifdef CONFIG_BLK_DEV_INITRD
 
 static int __initdata set_initramfs_file;
-static char __initdata initramfs_file[128] = "initramfs.cpio.gz";
+static char __initdata initramfs_file[128] = "initramfs";
 
 static int __init setup_initramfs_file(char *str)
 {
@@ -928,9 +928,9 @@ static int __init setup_initramfs_file(c
 early_param("initramfs_file", setup_initramfs_file);
 
 /*
- * We look for an additional "initramfs.cpio.gz" file in the hvfs.
- * If there is one, we allocate some memory for it and it will be
- * unpacked to the initramfs after any built-in initramfs_data.
+ * We look for a file called "initramfs" in the hvfs.  If there is one, we
+ * allocate some memory for it and it will be unpacked to the initramfs.
+ * If it's compressed, the initd code will uncompress it first.
  */
 static void __init load_hv_initrd(void)
 {
@@ -940,10 +940,16 @@ static void __init load_hv_initrd(void)
 
fd = hv_fs_findfile((HV_VirtAddr) initramfs_file);
if (fd == HV_ENOENT) {
-   if (set_initramfs_file)
+   if (set_initramfs_file) {
pr_warning("No such hvfs initramfs file '%s'\n",
   initramfs_file);
-   return;
+   return;
+   } else {
+   /* Try old backwards-compatible name. */
+   fd = hv_fs_findfile((HV_VirtAddr)"initramfs.cpio.gz");
+   if (fd == HV_ENOENT)
+   return;
+   }
}
BUG_ON(fd < 0);
stat = hv_fs_fstat(fd);

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


[51/74] loop: prevent bdev freeing while device in use

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Anatol Pomozov 

commit c1681bf8a7b1b98edee8b862a42c19c4e53205fd upstream.

struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
block_device allocated first time we access /dev/loopXX and deallocated on
bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
we want that block_device stay alive until we destroy the loop device
with "losetup -d".

But because we do not hold /dev/loopXX inode its counter goes 0, and
inode/bdev can be destroyed at any moment. Usually it happens at memory
pressure or when user drops inode cache (like in the test below). When later in
loop_clr_fd() we want to use bdev we have use-after-free error with following
stack:

BUG: unable to handle kernel NULL pointer dereference at 0280
  bd_set_size+0x10/0xa0
  loop_clr_fd+0x1f8/0x420 [loop]
  lo_ioctl+0x200/0x7e0 [loop]
  lo_compat_ioctl+0x47/0xe0 [loop]
  compat_blkdev_ioctl+0x341/0x1290
  do_filp_open+0x42/0xa0
  compat_sys_ioctl+0xc1/0xf20
  do_sys_open+0x16e/0x1d0
  sysenter_dispatch+0x7/0x1a

To prevent use-after-free we need to grab the device in loop_set_fd()
and put it later in loop_clr_fd().

The issue is reprodusible on current Linus head and v3.3. Here is the test:

  dd if=/dev/zero of=loop.file bs=1M count=1
  while [ true ]; do
losetup /dev/loop0 loop.file
echo 2 > /proc/sys/vm/drop_caches
losetup -d /dev/loop0
  done

[ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
  time we call loop_set_fd() we check that loop_device->lo_state is
  Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
  it will get EBUSY.  And if we try to loop_clr_fd() on unbound loop
  device we'll get ENXIO.

  loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
  loop_device->lo_ctl_mutex. ]

Signed-off-by: Anatol Pomozov 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 drivers/block/loop.c |9 -
 fs/block_dev.c   |1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -907,6 +907,11 @@ static int loop_set_fd(struct loop_devic
lo->lo_flags |= LO_FLAGS_PARTSCAN;
if (lo->lo_flags & LO_FLAGS_PARTSCAN)
ioctl_by_bdev(bdev, BLKRRPART, 0);
+
+   /* Grab the block_device to prevent its destruction after we
+* put /dev/loopXX inode. Later in loop_clr_fd() we bdput(bdev).
+*/
+   bdgrab(bdev);
return 0;
 
 out_clr:
@@ -1003,8 +1008,10 @@ static int loop_clr_fd(struct loop_devic
memset(lo->lo_encrypt_key, 0, LO_KEY_SIZE);
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
-   if (bdev)
+   if (bdev) {
+   bdput(bdev);
invalidate_bdev(bdev);
+   }
set_capacity(lo->lo_disk, 0);
loop_sysfs_exit(lo);
if (bdev) {
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -587,6 +587,7 @@ struct block_device *bdgrab(struct block
ihold(bdev->bd_inode);
return bdev;
 }
+EXPORT_SYMBOL(bdgrab);
 
 long nr_blockdev_pages(void)
 {

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


[27/74] SUNRPC: Add barriers to ensure read ordering in rpc_wake_up_task_queue_locked

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit 1166fde6a923c30f4351515b6a9a1efc513e7d00 upstream.

We need to be careful when testing task->tk_waitqueue in
rpc_wake_up_task_queue_locked, because it can be changed while we
are holding the queue->lock.
By adding appropriate memory barriers, we can ensure that it is safe to
test task->tk_waitqueue for equality if the RPC_TASK_QUEUED bit is set.

Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings 
---
 net/sunrpc/sched.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -139,6 +139,8 @@ static void __rpc_add_wait_queue(struct
list_add_tail(>u.tk_wait.list, >tasks[0]);
task->tk_waitqueue = queue;
queue->qlen++;
+   /* barrier matches the read in rpc_wake_up_task_queue_locked() */
+   smp_wmb();
rpc_set_queued(task);
 
dprintk("RPC: %5u added to queue %p \"%s\"\n",
@@ -389,8 +391,11 @@ static void __rpc_do_wake_up_task(struct
  */
 static void rpc_wake_up_task_queue_locked(struct rpc_wait_queue *queue, struct 
rpc_task *task)
 {
-   if (RPC_IS_QUEUED(task) && task->tk_waitqueue == queue)
-   __rpc_do_wake_up_task(queue, task);
+   if (RPC_IS_QUEUED(task)) {
+   smp_rmb();
+   if (task->tk_waitqueue == queue)
+   __rpc_do_wake_up_task(queue, task);
+   }
 }
 
 /*

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


[28/74] usb: xhci: Fix TRB transfer length macro used for Event TRB.

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Vivek Gautam 

commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f upstream.

Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci:
Bulk transfer support".  This patch will have issues applying to older
kernels.

Signed-off-by: Vivek gautam 
Signed-off-by: Sarah Sharp 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/xhci-ring.c |   24 
 drivers/usb/host/xhci.h  |4 
 2 files changed, 16 insertions(+), 12 deletions(-)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1964,8 +1964,8 @@ static int process_ctrl_td(struct xhci_h
if (event_trb != ep_ring->dequeue &&
event_trb != td->last_trb)
td->urb->actual_length =
-   td->urb->transfer_buffer_length
-   - TRB_LEN(le32_to_cpu(event->transfer_len));
+   td->urb->transfer_buffer_length -
+   EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
else
td->urb->actual_length = 0;
 
@@ -1997,7 +1997,7 @@ static int process_ctrl_td(struct xhci_h
/* Maybe the event was for the data stage? */
td->urb->actual_length =
td->urb->transfer_buffer_length -
-   TRB_LEN(le32_to_cpu(event->transfer_len));
+   EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
xhci_dbg(xhci, "Waiting for status "
"stage event\n");
return 0;
@@ -2033,7 +2033,7 @@ static int process_isoc_td(struct xhci_h
/* handle completion code */
switch (trb_comp_code) {
case COMP_SUCCESS:
-   if (TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
+   if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
frame->status = 0;
break;
}
@@ -2078,7 +2078,7 @@ static int process_isoc_td(struct xhci_h
len += 
TRB_LEN(le32_to_cpu(cur_trb->generic.field[2]));
}
len += TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
-   TRB_LEN(le32_to_cpu(event->transfer_len));
+   EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
 
if (trb_comp_code != COMP_STOP_INVAL) {
frame->actual_length = len;
@@ -2136,7 +2136,7 @@ static int process_bulk_intr_td(struct x
case COMP_SUCCESS:
/* Double check that the HW transferred everything. */
if (event_trb != td->last_trb ||
-   TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) 
{
+   EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
xhci_warn(xhci, "WARN Successful completion "
"on short TX\n");
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
@@ -2164,18 +2164,18 @@ static int process_bulk_intr_td(struct x
"%d bytes untransferred\n",
td->urb->ep->desc.bEndpointAddress,
td->urb->transfer_buffer_length,
-   TRB_LEN(le32_to_cpu(event->transfer_len)));
+   
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
/* Fast path - was this the last TRB in the TD for this URB? */
if (event_trb == td->last_trb) {
-   if (TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
+   if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
td->urb->actual_length =
td->urb->transfer_buffer_length -
-   TRB_LEN(le32_to_cpu(event->transfer_len));
+   EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
if (td->urb->transfer_buffer_length <
td->urb->actual_length) {
xhci_warn(xhci, "HC gave bad length "
"of %d bytes left\n",
- 
TRB_LEN(le32_to_cpu(event->transfer_len)));
+ 
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
td->urb->actual_length = 0;

[35/74] b43: A fix for DMA transmission sequence errors

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Iestyn C. Elfick" 

commit b251412db99ccd4495ce372fec7daee27bf06923 upstream.

Intermittently, b43 will report "Out of order TX status report on DMA ring".
When this happens, the driver must be reset before communication can resume.
The cause of the problem is believed to be an error in the closed-source
firmware; however, all versions of the firmware are affected.

This change uses the observation that the expected status is always 2 less
than the observed value, and supplies a fake status report to skip one
header/data pair.

Not all devices suffer from this problem, but it can occur several times
per second under heavy load. As each occurence kills the unmodified driver,
this patch makes if possible for the affected devices to function. The patch
logs only the first instance of the reset operation to prevent spamming
the logs.

Tested-by: Chris Vine 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/b43/dma.c |   65 
 1 file changed, 53 insertions(+), 12 deletions(-)

--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1482,8 +1482,12 @@ void b43_dma_handle_txstatus(struct b43_
const struct b43_dma_ops *ops;
struct b43_dmaring *ring;
struct b43_dmadesc_meta *meta;
+   static const struct b43_txstatus fake; /* filled with 0 */
+   const struct b43_txstatus *txstat;
int slot, firstused;
bool frame_succeed;
+   int skip;
+   static u8 err_out1, err_out2;
 
ring = parse_cookie(dev, status->cookie, );
if (unlikely(!ring))
@@ -1496,13 +1500,36 @@ void b43_dma_handle_txstatus(struct b43_
firstused = ring->current_slot - ring->used_slots + 1;
if (firstused < 0)
firstused = ring->nr_slots + firstused;
+
+   skip = 0;
if (unlikely(slot != firstused)) {
/* This possibly is a firmware bug and will result in
-* malfunction, memory leaks and/or stall of DMA functionality. 
*/
-   b43dbg(dev->wl, "Out of order TX status report on DMA ring %d. "
-  "Expected %d, but got %d\n",
-  ring->index, firstused, slot);
-   return;
+* malfunction, memory leaks and/or stall of DMA functionality.
+*/
+   if (slot == next_slot(ring, next_slot(ring, firstused))) {
+   /* If a single header/data pair was missed, skip over
+* the first two slots in an attempt to recover.
+*/
+   slot = firstused;
+   skip = 2;
+   if (!err_out1) {
+   /* Report the error once. */
+   b43dbg(dev->wl,
+  "Skip on DMA ring %d slot %d.\n",
+  ring->index, slot);
+   err_out1 = 1;
+   }
+   } else {
+   /* More than a single header/data pair were missed.
+* Report this error once.
+*/
+   if (!err_out2)
+   b43dbg(dev->wl,
+  "Out of order TX status report on DMA 
ring %d. Expected %d, but got %d\n",
+  ring->index, firstused, slot);
+   err_out2 = 1;
+   return;
+   }
}
 
ops = ring->ops;
@@ -1517,11 +1544,13 @@ void b43_dma_handle_txstatus(struct b43_
   slot, firstused, ring->index);
break;
}
+
if (meta->skb) {
struct b43_private_tx_info *priv_info =
-   
b43_get_priv_tx_info(IEEE80211_SKB_CB(meta->skb));
+b43_get_priv_tx_info(IEEE80211_SKB_CB(meta->skb));
 
-   unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 
1);
+   unmap_descbuffer(ring, meta->dmaaddr,
+meta->skb->len, 1);
kfree(priv_info->bouncebuffer);
priv_info->bouncebuffer = NULL;
} else {
@@ -1533,8 +1562,9 @@ void b43_dma_handle_txstatus(struct b43_
struct ieee80211_tx_info *info;
 
if (unlikely(!meta->skb)) {
-   /* This is a scatter-gather fragment of a 
frame, so
-* the skb pointer must not be NULL. */
+   /* This is a scatter-gather fragment of a frame,
+* so the skb 

[22/74] sysfs: handle failure path correctly for readdir()

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ming Lei 

commit e5110f411d2ee35bf8d202ccca2e89c633060dca upstream.

In case of 'if (filp->f_pos ==  0 or 1)' of sysfs_readdir(),
the failure from filldir() isn't handled, and the reference counter
of the sysfs_dirent object pointed by filp->private_data will be
released without clearing filp->private_data, so use after free
bug will be triggered later.

This patch returns immeadiately under the situation for fixing the bug,
and it is reasonable to return from readdir() when filldir() fails.

Reported-by: Dave Jones 
Tested-by: Sasha Levin 
Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 fs/sysfs/dir.c |4 
 1 file changed, 4 insertions(+)

--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -985,6 +985,8 @@ static int sysfs_readdir(struct file * f
ino = parent_sd->s_ino;
if (filldir(dirent, ".", 1, filp->f_pos, ino, DT_DIR) == 0)
filp->f_pos++;
+   else
+   return 0;
}
if (filp->f_pos == 1) {
if (parent_sd->s_parent)
@@ -993,6 +995,8 @@ static int sysfs_readdir(struct file * f
ino = parent_sd->s_ino;
if (filldir(dirent, "..", 2, filp->f_pos, ino, DT_DIR) == 0)
filp->f_pos++;
+   else
+   return 0;
}
mutex_lock(_mutex);
for (pos = sysfs_dir_pos(ns, parent_sd, filp->f_pos, pos);

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


[07/74] Bluetooth: Add support for Foxconn / Hon Hai [0489:e056]

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: AceLan Kao 

commit 2582d529c44d12502a700f1c3db062b9f44679bc upstream.

Add support for the AR9462 chip

T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e056 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: AceLan Kao 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Ben Hutchings 
---
 drivers/bluetooth/ath3k.c |2 ++
 drivers/bluetooth/btusb.c |1 +
 2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -83,6 +83,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0489, 0xe057) },
{ USB_DEVICE(0x13d3, 0x3393) },
{ USB_DEVICE(0x0489, 0xe04e) },
+   { USB_DEVICE(0x0489, 0xe056) },
 
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -113,6 +114,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
 
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -150,6 +150,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
 
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },

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


[23/74] pnfs-block: removing DM device maybe cause oops when call dev_remove

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: fanchaoting 

commit 4376c94618c26225e69e17b7c91169c45a90b292 upstream.

when pnfs block using device mapper,if umounting later,it maybe
cause oops. we apply "1 + sizeof(bl_umount_request)" memory for
msg->data, the memory maybe overflow when we do "memcpy(
[sizeof(bl_msg)], _umount_request, sizeof(bl_umount_request))",
because the size of bl_msg is more than 1 byte.

Signed-off-by: fanchaoting
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2:
 - In dev_remove(), msg is a structure not a pointer to it]
Signed-off-by: Ben Hutchings 
---
 fs/nfs/blocklayout/blocklayoutdm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/nfs/blocklayout/blocklayoutdm.c
+++ b/fs/nfs/blocklayout/blocklayoutdm.c
@@ -52,7 +52,8 @@ static void dev_remove(dev_t dev)
dprintk("Entering %s\n", __func__);
 
memset(, 0, sizeof(msg));
-   msg.data = kzalloc(1 + sizeof(bl_umount_request), GFP_NOFS);
+   msg.len = sizeof(bl_msg) + bl_msg.totallen;
+   msg.data = kzalloc(msg.len, GFP_NOFS);
if (!msg.data)
goto out;
 
@@ -63,7 +64,6 @@ static void dev_remove(dev_t dev)
memcpy(msg.data, _msg, sizeof(bl_msg));
dataptr = (uint8_t *) msg.data;
memcpy([sizeof(bl_msg)], _umount_request, 
sizeof(bl_umount_request));
-   msg.len = sizeof(bl_msg) + bl_msg.totallen;
 
add_wait_queue(_wq, );
if (rpc_queue_upcall(bl_device_pipe->d_inode, ) < 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/


[02/74] ASoC: imx-ssi: Fix occasional AC97 reset failure

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sascha Hauer 

commit b6e51600f4e983e757b1b6942becaa1ae7d82e67 upstream.

Signed-off-by: Sascha Hauer 
Signed-off-by: Markus Pargmann 
Signed-off-by: Mark Brown 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 sound/soc/imx/imx-ssi.c |5 +
 1 file changed, 5 insertions(+)

--- a/sound/soc/imx/imx-ssi.c
+++ b/sound/soc/imx/imx-ssi.c
@@ -573,6 +573,8 @@ static void imx_ssi_ac97_reset(struct sn
 
if (imx_ssi->ac97_reset)
imx_ssi->ac97_reset(ac97);
+   /* First read sometimes fails, do a dummy read */
+   imx_ssi_ac97_read(ac97, 0);
 }
 
 static void imx_ssi_ac97_warm_reset(struct snd_ac97 *ac97)
@@ -581,6 +583,9 @@ static void imx_ssi_ac97_warm_reset(stru
 
if (imx_ssi->ac97_warm_reset)
imx_ssi->ac97_warm_reset(ac97);
+
+   /* First read sometimes fails, do a dummy read */
+   imx_ssi_ac97_read(ac97, 0);
 }
 
 struct snd_ac97_bus_ops soc_ac97_ops = {

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


[04/74] Bluetooth: Add support for IMC Networks [13d3:3393]

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: AceLan Kao 

commit eed307e290b96636def331375e065aca43f9069a upstream.

Add support for the AR9462 chip

T:  Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3393 Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: AceLan Kao 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Ben Hutchings 
---
 drivers/bluetooth/ath3k.c |2 ++
 drivers/bluetooth/btusb.c |1 +
 2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -80,6 +80,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0489, 0xe057) },
+   { USB_DEVICE(0x13d3, 0x3393) },
 
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -107,6 +108,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
 
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -147,6 +147,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
 
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },

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


[61/74] bonding: fix disabling of arp_interval and miimon

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "niko...@redhat.com" 

[ Upstream commit 1bc7db16782c2a581fb4d53ca853631050f31611 ]

Currently if either arp_interval or miimon is disabled, they both get
disabled, and upon disabling they get executed once more which is not
the proper behaviour. Also when doing a no-op and disabling an already
disabled one, the other again gets disabled.
Also fix the error messages with the proper valid ranges, and a small
typo fix in the up delay error message (outputting "down delay", instead
of "up delay").

Signed-off-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/bonding/bond_sysfs.c | 92 +---
 1 file changed, 48 insertions(+), 44 deletions(-)

diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 8d923d3..8ed48c2 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -528,7 +528,7 @@ static ssize_t bonding_store_arp_interval(struct device *d,
goto out;
}
if (new_value < 0) {
-   pr_err("%s: Invalid arp_interval value %d not in range 1-%d; 
rejected.\n",
+   pr_err("%s: Invalid arp_interval value %d not in range 0-%d; 
rejected.\n",
   bond->dev->name, new_value, INT_MAX);
ret = -EINVAL;
goto out;
@@ -543,14 +543,15 @@ static ssize_t bonding_store_arp_interval(struct device 
*d,
pr_info("%s: Setting ARP monitoring interval to %d.\n",
bond->dev->name, new_value);
bond->params.arp_interval = new_value;
-   if (bond->params.miimon) {
-   pr_info("%s: ARP monitoring cannot be used with MII monitoring. 
%s Disabling MII monitoring.\n",
-   bond->dev->name, bond->dev->name);
-   bond->params.miimon = 0;
-   }
-   if (!bond->params.arp_targets[0]) {
-   pr_info("%s: ARP monitoring has been set up, but no ARP targets 
have been specified.\n",
-   bond->dev->name);
+   if (new_value) {
+   if (bond->params.miimon) {
+   pr_info("%s: ARP monitoring cannot be used with MII 
monitoring. %s Disabling MII monitoring.\n",
+   bond->dev->name, bond->dev->name);
+   bond->params.miimon = 0;
+   }
+   if (!bond->params.arp_targets[0])
+   pr_info("%s: ARP monitoring has been set up, but no ARP 
targets have been specified.\n",
+   bond->dev->name);
}
if (bond->dev->flags & IFF_UP) {
/* If the interface is up, we may need to fire off
@@ -558,10 +559,13 @@ static ssize_t bonding_store_arp_interval(struct device 
*d,
 * timer will get fired off when the open function
 * is called.
 */
-   cancel_delayed_work_sync(>mii_work);
-   queue_delayed_work(bond->wq, >arp_work, 0);
+   if (!new_value) {
+   cancel_delayed_work_sync(>arp_work);
+   } else {
+   cancel_delayed_work_sync(>mii_work);
+   queue_delayed_work(bond->wq, >arp_work, 0);
+   }
}
-
 out:
rtnl_unlock();
return ret;
@@ -703,7 +707,7 @@ static ssize_t bonding_store_downdelay(struct device *d,
}
if (new_value < 0) {
pr_err("%s: Invalid down delay value %d not in range %d-%d; 
rejected.\n",
-  bond->dev->name, new_value, 1, INT_MAX);
+  bond->dev->name, new_value, 0, INT_MAX);
ret = -EINVAL;
goto out;
} else {
@@ -758,8 +762,8 @@ static ssize_t bonding_store_updelay(struct device *d,
goto out;
}
if (new_value < 0) {
-   pr_err("%s: Invalid down delay value %d not in range %d-%d; 
rejected.\n",
-  bond->dev->name, new_value, 1, INT_MAX);
+   pr_err("%s: Invalid up delay value %d not in range %d-%d; 
rejected.\n",
+  bond->dev->name, new_value, 0, INT_MAX);
ret = -EINVAL;
goto out;
} else {
@@ -969,37 +973,37 @@ static ssize_t bonding_store_miimon(struct device *d,
}
if (new_value < 0) {
pr_err("%s: Invalid miimon value %d not in range %d-%d; 
rejected.\n",
-  bond->dev->name, new_value, 1, INT_MAX);
+  bond->dev->name, new_value, 0, INT_MAX);
ret = -EINVAL;
goto out;
-   } else {
-   pr_info("%s: Setting MII monitoring interval to %d.\n",
-   bond->dev->name, new_value);
-   bond->params.miimon = new_value;
-   if 

[14/74] HID: usbhid: quirk for MSI GX680R led panel

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Josh Boyer 

commit 620ae90ed8ca8b6e40cb9e10279b4f5ef9f0ab81 upstream.

This keyboard backlight device causes a 10 second delay to boot.  Add it
to the quirk list with HID_QUIRK_NO_INIT_REPORTS.

This fixes Red Hat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=907221

Signed-off-by: Josh Boyer 
Signed-off-by: Jiri Kosina 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/hid/hid-ids.h   |3 +++
 drivers/hid/usbhid/hid-quirks.c |1 +
 2 files changed, 4 insertions(+)

--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -539,6 +539,9 @@
 #define USB_VENDOR_ID_MONTEREY 0x0566
 #define USB_DEVICE_ID_GENIUS_KB29E 0x3004
 
+#define USB_VENDOR_ID_MSI  0x1770
+#define USB_DEVICE_ID_MSI_GX680R_LED_PANEL 0xff00
+
 #define USB_VENDOR_ID_NATIONAL_SEMICONDUCTOR 0x0400
 #define USB_DEVICE_ID_N_S_HARMONY  0xc359
 
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -71,6 +71,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, 
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
+   { USB_VENDIR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2, 
HID_QUIRK_NO_INIT_REPORTS },

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


[55/74] tcp: undo spurious timeout after SACK reneging

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Yuchung Cheng 

[ Upstream commit 7ebe183c6d444ef5587d803b64a1f4734b18c564 ]

On SACK reneging the sender immediately retransmits and forces a
timeout but disables Eifel (undo). If the (buggy) receiver does not
drop any packet this can trigger a false slow-start retransmit storm
driven by the ACKs of the original packets. This can be detected with
undo and TCP timestamps.

Signed-off-by: Yuchung Cheng 
Acked-by: Neal Cardwell 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv4/tcp_input.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1b1f7af..3124e17 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2265,11 +2265,8 @@ void tcp_enter_loss(struct sock *sk, int how)
if (tcp_is_reno(tp))
tcp_reset_reno_sack(tp);
 
-   if (!how) {
-   /* Push undo marker, if it was plain RTO and nothing
-* was retransmitted. */
-   tp->undo_marker = tp->snd_una;
-   } else {
+   tp->undo_marker = tp->snd_una;
+   if (how) {
tp->sacked_out = 0;
tp->fackets_out = 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/


[60/74] bonding: remove already created master sysfs link on failure

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Veaceslav Falico 

[ Upstream commit 9fe16b78ee17579cb4f333534cf7043e94c67024 ]

If slave sysfs symlink failes to be created - we end up without removing
the master sysfs symlink. Remove it in case of failure.

Signed-off-by: Veaceslav Falico 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/bonding/bond_sysfs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index a549f36..8d923d3 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -184,6 +184,11 @@ int bond_create_slave_symlinks(struct net_device *master,
sprintf(linkname, "slave_%s", slave->name);
ret = sysfs_create_link(&(master->dev.kobj), &(slave->dev.kobj),
linkname);
+
+   /* free the master link created earlier in case of error */
+   if (ret)
+   sysfs_remove_link(&(slave->dev.kobj), "master");
+
return ret;
 
 }

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


[18/74] rtlwifi: usb: add missing freeing of skbuff

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jussi Kivilinna 

commit 36ef0b473fbf43d5db23eea4616cc1d18cec245f upstream.

Signed-off-by: Jussi Kivilinna 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/rtlwifi/usb.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -812,6 +812,7 @@ static void _rtl_usb_transmit(struct iee
if (unlikely(!_urb)) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 ("Can't allocate urb. Drop skb!\n"));
+   kfree_skb(skb);
return;
}
urb_list = >tx_pending[ep_num];

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


[31/74] Nest rename_lock inside vfsmount_lock

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Al Viro 

commit 7ea600b5314529f9d1b9d6d3c41cb26fce6a7a4a upstream.

... lest we get livelocks between path_is_under() and d_path() and friends.

The thing is, wrt fairness lglocks are more similar to rwsems than to rwlocks;
it is possible to have thread B spin on attempt to take lock shared while thread
A is already holding it shared, if B is on lower-numbered CPU than A and there's
a thread C spinning on attempt to take the same lock exclusive.

As the result, we need consistent ordering between vfsmount_lock (lglock) and
rename_lock (seq_lock), even though everything that takes both is going to take
vfsmount_lock only shared.

Spotted-by: Brad Spengler 
Signed-off-by: Al Viro 
[bwh: Backported to 3.2:
 - Adjust context
 - s/_lock/vfsmount_lock/]
Signed-off-by: Ben Hutchings 
---
 fs/dcache.c |   16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2445,7 +2445,6 @@ static int prepend_path(const struct pat
bool slash = false;
int error = 0;
 
-   br_read_lock(vfsmount_lock);
while (dentry != root->dentry || vfsmnt != root->mnt) {
struct dentry * parent;
 
@@ -2475,8 +2474,6 @@ static int prepend_path(const struct pat
if (!error && !slash)
error = prepend(buffer, buflen, "/", 1);
 
-out:
-   br_read_unlock(vfsmount_lock);
return error;
 
 global_root:
@@ -2493,7 +2490,7 @@ global_root:
error = prepend(buffer, buflen, "/", 1);
if (!error)
error = vfsmnt->mnt_ns ? 1 : 2;
-   goto out;
+   return error;
 }
 
 /**
@@ -2520,9 +2517,11 @@ char *__d_path(const struct path *path,
int error;
 
prepend(, , "\0", 1);
+   br_read_lock(vfsmount_lock);
write_seqlock(_lock);
error = prepend_path(path, root, , );
write_sequnlock(_lock);
+   br_read_unlock(vfsmount_lock);
 
if (error < 0)
return ERR_PTR(error);
@@ -2539,9 +2538,11 @@ char *d_absolute_path(const struct path
int error;
 
prepend(, , "\0", 1);
+   br_read_lock(vfsmount_lock);
write_seqlock(_lock);
error = prepend_path(path, , , );
write_sequnlock(_lock);
+   br_read_unlock(vfsmount_lock);
 
if (error > 1)
error = -EINVAL;
@@ -2605,11 +2606,13 @@ char *d_path(const struct path *path, ch
return path->dentry->d_op->d_dname(path->dentry, buf, buflen);
 
get_fs_root(current->fs, );
+   br_read_lock(vfsmount_lock);
write_seqlock(_lock);
error = path_with_deleted(path, , , );
+   write_sequnlock(_lock);
+   br_read_unlock(vfsmount_lock);
if (error < 0)
res = ERR_PTR(error);
-   write_sequnlock(_lock);
path_put();
return res;
 }
@@ -2764,6 +2767,7 @@ SYSCALL_DEFINE2(getcwd, char __user *, b
get_fs_root_and_pwd(current->fs, , );
 
error = -ENOENT;
+   br_read_lock(vfsmount_lock);
write_seqlock(_lock);
if (!d_unlinked(pwd.dentry)) {
unsigned long len;
@@ -2773,6 +2777,7 @@ SYSCALL_DEFINE2(getcwd, char __user *, b
prepend(, , "\0", 1);
error = prepend_path(, , , );
write_sequnlock(_lock);
+   br_read_unlock(vfsmount_lock);
 
if (error < 0)
goto out;
@@ -2793,6 +2798,7 @@ SYSCALL_DEFINE2(getcwd, char __user *, b
}
} else {
write_sequnlock(_lock);
+   br_read_unlock(vfsmount_lock);
}
 
 out:

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


[54/74] tcp: preserve ACK clocking in TSO

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

[ Upstream commit f4541d60a449afd40448b06496dcd510f505928e ]

A long standing problem with TSO is the fact that tcp_tso_should_defer()
rearms the deferred timer, while it should not.

Current code leads to following bad bursty behavior :

20:11:24.484333 IP A > B: . 297161:316921(19760) ack 1 win 119
20:11:24.484337 IP B > A: . ack 263721 win 1117
20:11:24.485086 IP B > A: . ack 265241 win 1117
20:11:24.485925 IP B > A: . ack 266761 win 1117
20:11:24.486759 IP B > A: . ack 268281 win 1117
20:11:24.487594 IP B > A: . ack 269801 win 1117
20:11:24.488430 IP B > A: . ack 271321 win 1117
20:11:24.489267 IP B > A: . ack 272841 win 1117
20:11:24.490104 IP B > A: . ack 274361 win 1117
20:11:24.490939 IP B > A: . ack 275881 win 1117
20:11:24.491775 IP B > A: . ack 277401 win 1117
20:11:24.491784 IP A > B: . 316921:332881(15960) ack 1 win 119
20:11:24.492620 IP B > A: . ack 278921 win 1117
20:11:24.493448 IP B > A: . ack 280441 win 1117
20:11:24.494286 IP B > A: . ack 281961 win 1117
20:11:24.495122 IP B > A: . ack 283481 win 1117
20:11:24.495958 IP B > A: . ack 285001 win 1117
20:11:24.496791 IP B > A: . ack 286521 win 1117
20:11:24.497628 IP B > A: . ack 288041 win 1117
20:11:24.498459 IP B > A: . ack 289561 win 1117
20:11:24.499296 IP B > A: . ack 291081 win 1117
20:11:24.500133 IP B > A: . ack 292601 win 1117
20:11:24.500970 IP B > A: . ack 294121 win 1117
20:11:24.501388 IP B > A: . ack 295641 win 1117
20:11:24.501398 IP A > B: . 332881:351881(19000) ack 1 win 119

While the expected behavior is more like :

20:19:49.259620 IP A > B: . 197601:202161(4560) ack 1 win 119
20:19:49.260446 IP B > A: . ack 154281 win 1212
20:19:49.261282 IP B > A: . ack 155801 win 1212
20:19:49.262125 IP B > A: . ack 157321 win 1212
20:19:49.262136 IP A > B: . 202161:206721(4560) ack 1 win 119
20:19:49.262958 IP B > A: . ack 158841 win 1212
20:19:49.263795 IP B > A: . ack 160361 win 1212
20:19:49.264628 IP B > A: . ack 161881 win 1212
20:19:49.264637 IP A > B: . 206721:211281(4560) ack 1 win 119
20:19:49.265465 IP B > A: . ack 163401 win 1212
20:19:49.265886 IP B > A: . ack 164921 win 1212
20:19:49.266722 IP B > A: . ack 166441 win 1212
20:19:49.266732 IP A > B: . 211281:215841(4560) ack 1 win 119
20:19:49.267559 IP B > A: . ack 167961 win 1212
20:19:49.268394 IP B > A: . ack 169481 win 1212
20:19:49.269232 IP B > A: . ack 171001 win 1212
20:19:49.269241 IP A > B: . 215841:221161(5320) ack 1 win 119

Signed-off-by: Eric Dumazet 
Cc: Yuchung Cheng 
Cc: Van Jacobson 
Cc: Neal Cardwell 
Cc: Nandita Dukkipati 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv4/tcp_output.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 9bb7400..5c1807c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1587,8 +1587,11 @@ static int tcp_tso_should_defer(struct sock *sk, struct 
sk_buff *skb)
goto send_now;
}
 
-   /* Ok, it looks like it is advisable to defer.  */
-   tp->tso_deferred = 1 | (jiffies << 1);
+   /* Ok, it looks like it is advisable to defer.
+* Do not rearm the timer if already set to not break TCP ACK clocking.
+*/
+   if (!tp->tso_deferred)
+   tp->tso_deferred = 1 | (jiffies << 1);
 
return 1;
 

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


[65/74] DM9000B: driver initialization upgrade

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Joseph CHANG 

[ Upstream commit 6741f40d198c6a5feb23653a1efd4ca47f93d83d ]

Fix bug for DM9000 revision B which contain a DSP PHY

DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY,
So need extra change in initialization, For
explicity PHY Reset and PHY init parameter, and
first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe().

Following DM9000_NCR reset cause by dm9000_open() clear the
NCR_MAC_LBK bit.

Without this fix, Power-up FIFO pointers error happen around 2%
rate among Davicom's customers' boards. With this fix, All above
cases can be solved.

Signed-off-by: Joseph CHANG 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/davicom/dm9000.c | 214 +-
 drivers/net/ethernet/davicom/dm9000.h |  11 +-
 2 files changed, 120 insertions(+), 105 deletions(-)

diff --git a/drivers/net/ethernet/davicom/dm9000.c 
b/drivers/net/ethernet/davicom/dm9000.c
index 2a22f52..2f2e98b 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -257,6 +257,107 @@ static void dm9000_dumpblk_32bit(void __iomem *reg, int 
count)
tmp = readl(reg);
 }
 
+/*
+ * Sleep, either by using msleep() or if we are suspending, then
+ * use mdelay() to sleep.
+ */
+static void dm9000_msleep(board_info_t *db, unsigned int ms)
+{
+   if (db->in_suspend)
+   mdelay(ms);
+   else
+   msleep(ms);
+}
+
+/* Read a word from phyxcer */
+static int
+dm9000_phy_read(struct net_device *dev, int phy_reg_unused, int reg)
+{
+   board_info_t *db = netdev_priv(dev);
+   unsigned long flags;
+   unsigned int reg_save;
+   int ret;
+
+   mutex_lock(>addr_lock);
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* Save previous register address */
+   reg_save = readb(db->io_addr);
+
+   /* Fill the phyxcer register into REG_0C */
+   iow(db, DM9000_EPAR, DM9000_PHY | reg);
+
+   /* Issue phyxcer read command */
+   iow(db, DM9000_EPCR, EPCR_ERPRR | EPCR_EPOS);
+
+   writeb(reg_save, db->io_addr);
+   spin_unlock_irqrestore(>lock, flags);
+
+   dm9000_msleep(db, 1);   /* Wait read complete */
+
+   spin_lock_irqsave(>lock, flags);
+   reg_save = readb(db->io_addr);
+
+   iow(db, DM9000_EPCR, 0x0);  /* Clear phyxcer read command */
+
+   /* The read data keeps on REG_0D & REG_0E */
+   ret = (ior(db, DM9000_EPDRH) << 8) | ior(db, DM9000_EPDRL);
+
+   /* restore the previous address */
+   writeb(reg_save, db->io_addr);
+   spin_unlock_irqrestore(>lock, flags);
+
+   mutex_unlock(>addr_lock);
+
+   dm9000_dbg(db, 5, "phy_read[%02x] -> %04x\n", reg, ret);
+   return ret;
+}
+
+/* Write a word to phyxcer */
+static void
+dm9000_phy_write(struct net_device *dev,
+int phyaddr_unused, int reg, int value)
+{
+   board_info_t *db = netdev_priv(dev);
+   unsigned long flags;
+   unsigned long reg_save;
+
+   dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
+   mutex_lock(>addr_lock);
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* Save previous register address */
+   reg_save = readb(db->io_addr);
+
+   /* Fill the phyxcer register into REG_0C */
+   iow(db, DM9000_EPAR, DM9000_PHY | reg);
+
+   /* Fill the written data into REG_0D & REG_0E */
+   iow(db, DM9000_EPDRL, value);
+   iow(db, DM9000_EPDRH, value >> 8);
+
+   /* Issue phyxcer write command */
+   iow(db, DM9000_EPCR, EPCR_EPOS | EPCR_ERPRW);
+
+   writeb(reg_save, db->io_addr);
+   spin_unlock_irqrestore(>lock, flags);
+
+   dm9000_msleep(db, 1);   /* Wait write complete */
+
+   spin_lock_irqsave(>lock, flags);
+   reg_save = readb(db->io_addr);
+
+   iow(db, DM9000_EPCR, 0x0);  /* Clear phyxcer write command */
+
+   /* restore the previous address */
+   writeb(reg_save, db->io_addr);
+
+   spin_unlock_irqrestore(>lock, flags);
+   mutex_unlock(>addr_lock);
+}
+
 /* dm9000_set_io
  *
  * select the specified set of io routines to use with the
@@ -793,6 +894,9 @@ dm9000_init_dm9000(struct net_device *dev)
 
iow(db, DM9000_GPCR, GPCR_GEP_CNTL);/* Let GPIO0 output */
 
+   dm9000_phy_write(dev, 0, MII_BMCR, BMCR_RESET); /* PHY RESET */
+   dm9000_phy_write(dev, 0, MII_DM_DSPCR, DSPCR_INIT_PARAM); /* Init */
+
ncr = (db->flags & DM9000_PLATF_EXT_PHY) ? NCR_EXT_PHY : 0;
 
/* if wol is needed, then always set NCR_WAKEEN otherwise we end
@@ -1199,109 +1303,6 @@ dm9000_open(struct net_device *dev)
return 0;
 }
 
-/*
- * Sleep, either by using msleep() or if we are suspending, then
- * use mdelay() to sleep.
- */
-static void dm9000_msleep(board_info_t *db, unsigned int ms)
-{
-   if (db->in_suspend)
-   mdelay(ms);
-   

[38/74] usb: ftdi_sio: Add support for Mitsubishi FX-USB-AW/-BD

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Konstantin Holoborodko 

commit 482b0b5d82bd916cc0c55a2abf65bdc69023b843 upstream.

It enhances the driver for FTDI-based USB serial adapters
to recognize Mitsubishi Electric Corp. USB/RS422 Converters
as FT232BM chips and support them.
https://search.meau.com/?q=FX-USB-AW

Signed-off-by: Konstantin Holoborodko 
Tested-by: Konstantin Holoborodko 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/ftdi_sio.c |1 +
 drivers/usb/serial/ftdi_sio_ids.h |7 +++
 2 files changed, 8 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -648,6 +648,7 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_RM_CANVIEW_PID) },
{ USB_DEVICE(ACTON_VID, ACTON_SPECTRAPRO_PID) },
{ USB_DEVICE(CONTEC_VID, CONTEC_COM1USBH_PID) },
+   { USB_DEVICE(MITSUBISHI_VID, MITSUBISHI_FXUSB_PID) },
{ USB_DEVICE(BANDB_VID, BANDB_USOTL4_PID) },
{ USB_DEVICE(BANDB_VID, BANDB_USTL4_PID) },
{ USB_DEVICE(BANDB_VID, BANDB_USO9ML2_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -584,6 +584,13 @@
 #define CONTEC_COM1USBH_PID0x8311  /* COM-1(USB)H */
 
 /*
+ * Mitsubishi Electric Corp. (http://www.meau.com)
+ * Submitted by Konstantin Holoborodko
+ */
+#define MITSUBISHI_VID 0x06D3
+#define MITSUBISHI_FXUSB_PID   0x0284 /* USB/RS422 converters: FX-USB-AW/-BD */
+
+/*
  * Definitions for B Electronics products.
  */
 #define BANDB_VID  0x0856  /* B Electronics Vendor ID */

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


[03/74] UBIFS: make space fixup work in the remount case

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Artem Bityutskiy 

commit 67e753ca41782913d805ff4a8a2b0f60b26b7915 upstream.

The UBIFS space fixup is a useful feature which allows to fixup the "broken"
flash space at the time of the first mount. The "broken" space is usually the
result of using a "dumb" industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.

The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
   (see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
   flag and re-writes the entire media atomically, which may take really a lot
   of time.
3. UBIFS clears the fixup flag in the superblock.

This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.

Signed-off-by: Artem Bityutskiy 
Reported-by: Mark Jackson 
Signed-off-by: Ben Hutchings 
---
 fs/ubifs/super.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1583,6 +1583,12 @@ static int ubifs_remount_rw(struct ubifs
c->remounting_rw = 1;
c->ro_mount = 0;
 
+   if (c->space_fixup) {
+   err = ubifs_fixup_free_space(c);
+   if (err)
+   return err;
+   }
+
err = check_free_space(c);
if (err)
goto out;
@@ -1699,12 +1705,6 @@ static int ubifs_remount_rw(struct ubifs
err = dbg_check_space_info(c);
}
 
-   if (c->space_fixup) {
-   err = ubifs_fixup_free_space(c);
-   if (err)
-   goto out;
-   }
-
mutex_unlock(>umount_mutex);
return err;
 

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


[16/74] Bluetooth: Add support for Dell[QCA 0cf3:817a]

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ming Lei 

commit ebaf5795ef57a70a042ea259448a465024e2821d upstream.

Add support for the AR9462 chip

T:  Bus=03 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=817a Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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

Cc: Gustavo Padovan 
Signed-off-by: Ming Lei 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Ben Hutchings 
---
 drivers/bluetooth/ath3k.c |2 ++
 drivers/bluetooth/btusb.c |1 +
 2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -76,6 +76,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0CF3, 0x3004) },
{ USB_DEVICE(0x0CF3, 0x3008) },
{ USB_DEVICE(0x0CF3, 0x311D) },
+   { USB_DEVICE(0x0CF3, 0x817a) },
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3004) },
{ USB_DEVICE(0x04CA, 0x3005) },
@@ -111,6 +112,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0CF3, 0x817a), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -143,6 +143,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0cf3, 0x817a), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },

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


[15/74] HID: usbhid: fix build problem

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jiri Kosina 

commit 570637dc8eeb2faba06228d497ff40bb019bcc93 upstream.

Fix build problem caused by typo introduced by 620ae90ed8
("HID: usbhid: quirk for MSI GX680R led panel").

Reported-by: fengguang...@intel.com
Signed-off-by: Jiri Kosina 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/hid/usbhid/hid-quirks.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -71,7 +71,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, 
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
-   { USB_VENDIR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
+   { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2, 
HID_QUIRK_NO_INIT_REPORTS },

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


[05/74] Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Daniel Schaal 

commit 2c262b2a5235b7f5b18d4d58394511f76371d7cb upstream.

T:  Bus=02 Lev=02 Prnt=02 Port=06 Cnt=01 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=3006 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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

Signed-off-by: Daniel Schaal 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Ben Hutchings 
---
 drivers/bluetooth/ath3k.c |2 ++
 drivers/bluetooth/btusb.c |1 +
 2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -76,6 +76,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0CF3, 0x311D) },
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3005) },
+   { USB_DEVICE(0x04CA, 0x3006) },
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
@@ -104,6 +105,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -143,6 +143,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },

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


[52/74] sky2: Receive Overflows not counted

2013-04-07 Thread Ben Hutchings
3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mirko Lindner 

[ Upstream commit 9cfe8b156c21cf340b3a10ecb3022fbbc1c39185 ]

The sky2 driver doesn't count the Receive Overflows because the MAC
interrupt for this event is not set in the MAC's interrupt mask.
The MAC's interrupt mask is set only for Transmit FIFO Underruns.

Fix: The correct setting should be (GM_IS_TX_FF_UR | GM_IS_RX_FF_OR)
Otherwise the Receive Overflow event will not generate any interrupt.
The  Receive Overflow interrupt is handled correctly

Signed-off-by: Mirko Lindner 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/marvell/sky2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/sky2.h 
b/drivers/net/ethernet/marvell/sky2.h
index 3c896ce..a0f229e 100644
--- a/drivers/net/ethernet/marvell/sky2.h
+++ b/drivers/net/ethernet/marvell/sky2.h
@@ -2069,7 +2069,7 @@ enum {
GM_IS_RX_FF_OR  = 1<<1, /* Receive FIFO Overrun */
GM_IS_RX_COMPL  = 1<<0, /* Frame Reception Complete */
 
-#define GMAC_DEF_MSK GM_IS_TX_FF_UR
+#define GMAC_DEF_MSK (GM_IS_TX_FF_UR | GM_IS_RX_FF_OR)
 };
 
 /* GMAC_LINK_CTRL  16 bit  GMAC Link Control Reg (YUKON only) */

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


  1   2   3   4   5   6   >