[PATCH v2] m25p80 / fast read

[Sascha Hauer]

Changes since v1:

- rebase on git.infradead.org/l2-mtd.git
- improve description for patch 2/3

Sascha


Markus Niebel (1):
  mtd: m25p80: add support for mr25h10

Sascha Hauer (2):
  mtd: m25p80: Pass flags through CAT25_INFO macro
  mtd: m25p80: make CONFIG_M25PXX_USE_FAST_READ safe to enable

 drivers/mtd/devices/m25p80.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()

[Chen Gang]

On 08/20/2013 03:48 PM, Chen Gang wrote:
> On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
>> On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>>>
 sure you'll have to change shmem_show_mpol statement to return int code.
 Won't this be more short and convenient?


>>>
>>> Hmm... if return -ENOSPC, in common processing, it still need continue
>>> (but need let outside know about the string truncation).
>>>
>>> So I still suggest to give more check for it.
>>
>> I still don't like adding additional code like
>>
>> +ret = mpol_to_str(buffer, sizeof(buffer), mpol);
>> +if (ret < 0)
>> +   switch (ret) {
>> +   case -ENOSPC:
>> +   printk(KERN_WARNING
>> +   "in %s: string is truncated in 
>> mpol_to_str().\n",
>> +   __func__);

Oh, that need 'break' in my original patch. :-)

>> +   default:
>> +   printk(KERN_ERR
>> +   "in %s: call mpol_to_str() fail, errcode: 
>> %d. buffer: %p, size: %zu, pol: %p\n",
>> +   __func__, ret, buffer, sizeof(buffer), mpol);
>> +   return;
>> +   }
>>
>> this code is pretty neat for debugging purpose I think but in most case (if
>> only I've not missed something obvious) it simply won't be the case.
>>
> 
> For mpol_to_str(), it is for printing string, I suggest to fill buffer
> as full as possible like another printing string functions, -ENOSPC is
> not critical error, callers may can bear it, and still want to continue.
> 
> For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
> really not a critical error, they can continue.
> 
> For the 'default' error processing:
> 
>   I still suggest to 'printk' in shmem_show_mpol(), because when failure 
> occurs, it has no return value to mark the failure to upper caller.
>   Hmm... but for show_numa_map(), may remove the 'printk', only return the 
> error code is OK. :-)
> 
> 
> Thanks.
> 
>> Won't somthing like below do the same but with smaller code change?
>> Note I've not even compiled it but it shows the idea.
>> ---
>>  fs/proc/task_mmu.c |4 +++-
>>  mm/shmem.c |   17 +
>>  2 files changed, 12 insertions(+), 9 deletions(-)
>>
>> Index: linux-2.6.git/fs/proc/task_mmu.c
>> ===
>> --- linux-2.6.git.orig/fs/proc/task_mmu.c
>> +++ linux-2.6.git/fs/proc/task_mmu.c
>> @@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
>>  walk.mm = mm;
>>  
>>  pol = get_vma_policy(task, vma, vma->vm_start);
>> -mpol_to_str(buffer, sizeof(buffer), pol);
>> +n = mpol_to_str(buffer, sizeof(buffer), pol);
>>  mpol_cond_put(pol);
>> +if (n < 0)
>> +return n;
>>  
>>  seq_printf(m, "%08lx %s", vma->vm_start, buffer);
>>  
>> Index: linux-2.6.git/mm/shmem.c
>> ===
>> --- linux-2.6.git.orig/mm/shmem.c
>> +++ linux-2.6.git/mm/shmem.c
>> @@ -883,16 +883,20 @@ redirty:
>>  
>>  #ifdef CONFIG_NUMA
>>  #ifdef CONFIG_TMPFS
>> -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>> +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>>  {
>>  char buffer[64];
>> +int ret;
>>  
>>  if (!mpol || mpol->mode == MPOL_DEFAULT)
>> -return; /* show nothing */
>> +return 0;   /* show nothing */
>>  
>> -mpol_to_str(buffer, sizeof(buffer), mpol);
>> +ret = mpol_to_str(buffer, sizeof(buffer), mpol);
>> +if (ret < 0)
>> +return ret;
>>  
>>  seq_printf(seq, ",mpol=%s", buffer);
>> +return 0;
>>  }
>>  
>>  static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
>> @@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
>>  }
>>  #else /* !CONFIG_NUMA */
>>  #ifdef CONFIG_TMPFS
>> -static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy 
>> *mpol)
>> -{
>> -}
>> +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy 
>> *mpol) { return 0; }
>>  #endif /* CONFIG_TMPFS */
>>  
>>  static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
>> @@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
>>  if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
>>  seq_printf(seq, ",gid=%u",
>>  from_kgid_munged(_user_ns, sbinfo->gid));
>> -shmem_show_mpol(seq, sbinfo->mpol);
>> -return 0;
>> +return shmem_show_mpol(seq, sbinfo->mpol);
>>  }
>>  #endif /* CONFIG_TMPFS */
>>  
>>
>>
> 
> 


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

Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()

[Ian Applegate]

Unfortunately no boxen with CONFIG_DEBUG_MUTEXES among them. I can
enable on a few and should have some results within the day. These
mainly serve (quite a bit of) HTTP/S cache traffic.

On Tue, Aug 20, 2013 at 12:21 AM, Al Viro  wrote:
> On Tue, Aug 20, 2013 at 12:17:52AM -0700, Ian Applegate wrote:
>> We are also seeing this or a similar issue. On a fairly widespread
>> deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the
>> order of 36 days (combined MTBF.)
>
> Do you have any boxen with CONFIG_DEBUG_MUTEXES among those?  What
> kind of setup do you have on those, BTW?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()

[Chen Gang]

On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
> On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>>
>>> sure you'll have to change shmem_show_mpol statement to return int code.
>>> Won't this be more short and convenient?
>>>
>>>
>>
>> Hmm... if return -ENOSPC, in common processing, it still need continue
>> (but need let outside know about the string truncation).
>>
>> So I still suggest to give more check for it.
> 
> I still don't like adding additional code like
> 
> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
> + if (ret < 0)
> +   switch (ret) {
> +   case -ENOSPC:
> +   printk(KERN_WARNING
> +   "in %s: string is truncated in 
> mpol_to_str().\n",
> +   __func__);
> +   default:
> +   printk(KERN_ERR
> +   "in %s: call mpol_to_str() fail, errcode: %d. 
> buffer: %p, size: %zu, pol: %p\n",
> +   __func__, ret, buffer, sizeof(buffer), mpol);
> +   return;
> +   }
> 
> this code is pretty neat for debugging purpose I think but in most case (if
> only I've not missed something obvious) it simply won't be the case.
>

For mpol_to_str(), it is for printing string, I suggest to fill buffer
as full as possible like another printing string functions, -ENOSPC is
not critical error, callers may can bear it, and still want to continue.

For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
really not a critical error, they can continue.

For the 'default' error processing:

  I still suggest to 'printk' in shmem_show_mpol(), because when failure 
occurs, it has no return value to mark the failure to upper caller.
  Hmm... but for show_numa_map(), may remove the 'printk', only return the 
error code is OK. :-)


Thanks.

> Won't somthing like below do the same but with smaller code change?
> Note I've not even compiled it but it shows the idea.
> ---
>  fs/proc/task_mmu.c |4 +++-
>  mm/shmem.c |   17 +
>  2 files changed, 12 insertions(+), 9 deletions(-)
> 
> Index: linux-2.6.git/fs/proc/task_mmu.c
> ===
> --- linux-2.6.git.orig/fs/proc/task_mmu.c
> +++ linux-2.6.git/fs/proc/task_mmu.c
> @@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
>   walk.mm = mm;
>  
>   pol = get_vma_policy(task, vma, vma->vm_start);
> - mpol_to_str(buffer, sizeof(buffer), pol);
> + n = mpol_to_str(buffer, sizeof(buffer), pol);
>   mpol_cond_put(pol);
> + if (n < 0)
> + return n;
>  
>   seq_printf(m, "%08lx %s", vma->vm_start, buffer);
>  
> Index: linux-2.6.git/mm/shmem.c
> ===
> --- linux-2.6.git.orig/mm/shmem.c
> +++ linux-2.6.git/mm/shmem.c
> @@ -883,16 +883,20 @@ redirty:
>  
>  #ifdef CONFIG_NUMA
>  #ifdef CONFIG_TMPFS
> -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>  {
>   char buffer[64];
> + int ret;
>  
>   if (!mpol || mpol->mode == MPOL_DEFAULT)
> - return; /* show nothing */
> + return 0;   /* show nothing */
>  
> - mpol_to_str(buffer, sizeof(buffer), mpol);
> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
> + if (ret < 0)
> + return ret;
>  
>   seq_printf(seq, ",mpol=%s", buffer);
> + return 0;
>  }
>  
>  static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
> @@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
>  }
>  #else /* !CONFIG_NUMA */
>  #ifdef CONFIG_TMPFS
> -static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy 
> *mpol)
> -{
> -}
> +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy 
> *mpol) { return 0; }
>  #endif /* CONFIG_TMPFS */
>  
>  static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
> @@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
>   if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
>   seq_printf(seq, ",gid=%u",
>   from_kgid_munged(_user_ns, sbinfo->gid));
> - shmem_show_mpol(seq, sbinfo->mpol);
> - return 0;
> + return shmem_show_mpol(seq, sbinfo->mpol);
>  }
>  #endif /* CONFIG_TMPFS */
>  
> 
> 


-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] mfd: max8997: use devm_*() functions

[Lee Jones]

> Use devm_*() functions to make cleanup paths simpler.
> 
> Signed-off-by: Jingoo Han 

Patches look good to me 1-6 applied.

By the way, when you're sending patch-sets would you mind adding a
cover letter? Or at least thread patches 2-n on to patch 1. It just
makes them easier to track if they receive comments.

If you don't already, send your patches with `git send-mail` and try
playing around with: --thread (turns on threading) and
--[no-]chain-reply-to (controlls shallow and deep threading) to find
your preference. Cover letters are added with --compose and for
convenience you can annotate them with, surprise surprise --annotate. :)

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1] seq_file: Fix overflow condition in seq_commit

[Al Viro]

On Tue, Aug 20, 2013 at 12:51:56PM +0530, Arun KS wrote:

> d_path expects the pathname to be less than 64 bytes. If its more than
> 64, it returns -ENAMETOOLONG.

?!?!?  d_path() does not expect anything of that sort - it can very
well produce names much longer, without ENAMETOOLONG.

> char *dynamic_dname(struct dentry *dentry, char *buffer, int buflen,
> const char *fmt, ...)
> {
> va_list args;
> char temp[64];
> int sz;
> 
> va_start(args, fmt);
> sz = vsnprintf(temp, sizeof(temp), fmt, args) + 1;
> va_end(args);
> 
> if (sz > sizeof(temp) || sz > buflen)
> return ERR_PTR(-ENAMETOOLONG);
> 
> buffer += buflen - sz;
> return memcpy(buffer, temp, sz);
> }

Aha.  _That_ is a bug, all right - dynamic_dname() is simply not suitable
for that kind of uses.  ashmem.c is certainly abusing shmem_file_setup();
feeding that kind of mess as dentry name is a Bad Idea(tm).  Anyway,
I'd suggest this for a fix:

va_list args;
size_t sz;
va_start(args, fmt);
sz = vsnprintf(NULL, 0, fmt, args) + 1;
va_end(args);
if (sz > buflen)
return ERR_PTR(-ENAMETOOLONG);
va_start(args, fmt);
buffer += buflen - sz;
vsprintf(buffer, fmt, args);
va_end(args);
return buffer;

Either right in dynamic_dname(), or as possibly_fucking_long_dname(),
to be used by shmem.c...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Aug 20

[Stephen Rothwell]

Hi all,

Changes since 20130819:

The xfs tree gained a build failure for which I reverted a commit.

The libata tree lost its build failure.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 222 trees (counting Linus' and 30 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (fd3930f proc: more readdir conversion bug-fixes)
Merging fixes/master (b3a3a9c Merge tag 'trace-3.11-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1)
Merging arc-current/for-curr (c095ba7 Linux 3.11-rc4)
Merging arm-current/fixes (e1f0203 Merge branch 'security-fixes' into fixes)
Merging m68k-current/for-linus (ea077b1 m68k: Truncate base in do_div())
Merging metag-fixes/fixes (dfe248b MAINTAINERS: add linux-metag mailing list)
Merging powerpc-merge/merge (28e61cc powerpc/tm: Fix context switching TAR, PPR 
and DSCR SPRs)
Merging sparc/master (1c2696c sparc64: Fix ITLB handler of null page)
Merging net/master (0f7dd1a Merge tag 'clk-fixes-for-linus' of 
git://git.linaro.org/people/mturquette/linux)
Merging ipsec/master (844d487 xfrm: choose protocol family by skb protocol)
Merging sound-current/for-linus (d3d3835 ALSA: hda - Add inverted digital mic 
fixup for Acer Aspire One)
Merging pci-current/for-linus (36dd1f3 PCI: mvebu: Disable prefetchable memory 
support in PCI-to-PCI bridge)
Merging wireless/master (48c3e37 Merge branch 'for-john' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging driver-core.current/driver-core-linus (5ae90d8 Linux 3.11-rc3)
Merging tty.current/tty-linus (c095ba7 Linux 3.11-rc4)
Merging usb.current/usb-linus (b36f4be Linux 3.11-rc6)
Merging staging.current/staging-linus (d4e4ab8 Linux 3.11-rc5)
Merging char-misc.current/char-misc-linus (b36f4be Linux 3.11-rc6)
Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus)
Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' 
and 'recovery'.)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (e70308e Revert "crypto: crct10dif - Wrap 
crc_t10dif function all to use crypto transform framework")
Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j 
option")
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct 
resource to 0 in of_irq_to_resource())
Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32)
Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work 
without pdata)
Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove)
Merging drm-intel-fixes/drm-intel-fixes (884020b drm/i915: Invalidate TLBs for 
the rings after a reset)
Merging asm-generic/master (fb9de7e xtensa: Use generic asm/mmu.h for nommu)
Merging arc/for-next (a00b92e ARC: [ASID] Optimize the threads-of-process 
switching case)
Merging arm/for-next (2c5d489 Merge branch 

RE: [ 00/34] 3.4.59-stable review

[Berg, Johannes]

> > [ 26/34] genetlink: fix family dump race
> 
> Johannes, another strike against this patch :(
> 
> Any chance on fixing it upstream and me sucking that fix in?

Yeah, I'm trying to get that, but it's not clear to me how to fix it. Where did 
you apply it? It was going to need some fixes but when the first objection was 
raised I figured you were going to drop it for now completely? Sorry for the 
mess :-(

johannes
-- 

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Re: commit 94fc5d9: chromium-sandbox core dumped

[Emmanuel Benisty]

Hi Linus,

On Tue, Aug 20, 2013 at 1:26 AM, Linus Torvalds
 wrote:
> On Mon, Aug 19, 2013 at 1:25 PM, Linus Torvalds
>  wrote:
>>
>> I suspect that last "return 0" at the end should be "return 1". Does
>> that fix things for you? Untested.
>
> Ok. Confirmed. I reproduced the bug that Richard Genoud fixed, and
> also verified that yes, changing that last "return 0" in
> proc_readdir_de() to "return 1" fixes the bug that Emmanuel reported.
> Although I just did it with a special test-program using different
> getdents buffer sizes, so I didn't verify the particular Chromium
> breakage, but that does look like it's the same issue.

Just to confirm it does fix the chromium issue as well.

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

Re: [PATCH 1/3] mfd: pm8921: include missing linux/module.h

[Lee Jones]

On Tue, 20 Aug 2013, Jingoo Han wrote:

> Include  in order to fix the following errors.
> 
> drivers/mfd/pm8921-core.c:209:16: error: expected declaration specifiers or 
> '...' before string constant
> drivers/mfd/pm8921-core.c:210:20: error: expected declaration specifiers or 
> '...' before string constant
> drivers/mfd/pm8921-core.c:211:16: error: expected declaration specifiers or 
> '...' before string constant
> drivers/mfd/pm8921-core.c:212:14: error: expected declaration specifiers or 
> '...' before string constant
> 
> Signed-off-by: Jingoo Han 

Patches look good to me 1-3 applied.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/17] ARM: imx: remove custom .init_time hook

[Sascha Hauer]

On Tue, Aug 20, 2013 at 04:04:20AM +0200, Sebastian Hesselbarth wrote:
> With arch/arm calling of_clk_init(NULL) from time_init(), we can now
> remove custom .init_time hooks.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Notes:
> - Although mx5_clocks_common_init() is shared with non-DT, removing
>   of_clk_init(NULL) should be fine, as it only registers DT clk providers.
> - For imx6q, printing of silicon revision has been moved from .init_time
>   to .init_machine hook.
> 
> Cc: Russell King 
> Cc: Arnd Bergmann 
> Cc: Sascha Hauer 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   12 
>  arch/arm/mach-imx/common.h  |2 --
>  arch/arm/mach-imx/imx51-dt.c|6 --
>  arch/arm/mach-imx/mach-imx53.c  |6 --
>  arch/arm/mach-imx/mach-imx6q.c  |   14 +++---
>  arch/arm/mach-imx/mach-imx6sl.c |7 ---
>  arch/arm/mach-imx/mach-vf610.c  |9 -
>  7 files changed, 3 insertions(+), 53 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
> b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 1a56a33..5955a54 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -131,8 +131,6 @@ static void __init mx5_clocks_common_init(unsigned long 
> rate_ckil,
>  {
>   int i;
>  
> - of_clk_init(NULL);
> -
>   clk[dummy] = imx_clk_fixed("dummy", 0);
>   clk[ckil] = imx_obtain_fixed_clock("ckil", rate_ckil);
>   clk[osc] = imx_obtain_fixed_clock("osc", rate_osc);
> @@ -569,13 +567,3 @@ int __init mx53_clocks_init(unsigned long rate_ckil, 
> unsigned long rate_osc,
>  
>   return 0;
>  }
> -
> -int __init mx51_clocks_init_dt(void)
> -{
> - return mx51_clocks_init(0, 0, 0, 0);
> -}
> -
> -int __init mx53_clocks_init_dt(void)
> -{
> - return mx53_clocks_init(0, 0, 0, 0);
> -}
> diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
> index 4517fd7..0ce8313 100644
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -68,8 +68,6 @@ extern int mx53_clocks_init(unsigned long ckil, unsigned 
> long osc,
>  extern int mx25_clocks_init_dt(void);
>  extern int mx27_clocks_init_dt(void);
>  extern int mx31_clocks_init_dt(void);
> -extern int mx51_clocks_init_dt(void);
> -extern int mx53_clocks_init_dt(void);
>  extern struct platform_device *mxc_register_gpio(char *name, int id,
>   resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
>  extern void mxc_set_cpu_type(unsigned int type);
> diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
> index 53e43e5..bece8a6 100644
> --- a/arch/arm/mach-imx/imx51-dt.c
> +++ b/arch/arm/mach-imx/imx51-dt.c
> @@ -34,17 +34,11 @@ static const char *imx51_dt_board_compat[] __initdata = {
>   NULL
>  };
>  
> -static void __init imx51_timer_init(void)
> -{
> - mx51_clocks_init_dt();
> -}
> -
>  DT_MACHINE_START(IMX51_DT, "Freescale i.MX51 (Device Tree Support)")
>   .map_io = mx51_map_io,
>   .init_early = imx51_init_early,
>   .init_irq   = mx51_init_irq,
>   .handle_irq = imx51_handle_irq,
> - .init_time  = imx51_timer_init,

On i.MX5 the init_time hook calls mx5x_clocks_init_dt which calls
mx5x_clocks_init which not only calls of_clk_init() but also registers
all clocks in the system. You can't remove it.

I am missing some

CLK_OF_DECLARE(imx51, "fsl,imx51-ccm", imx51_clocks_init);
CLK_OF_DECLARE(imx53, "fsl,imx53-ccm", imx53_clocks_init);

Somewhere.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION

[Mika Westerberg]

On Mon, Aug 19, 2013 at 08:34:03PM -0700, Jerry Snitselaar wrote:
> On Tue Aug 20 13, Rafael J. Wysocki wrote:
> > On Monday, August 19, 2013 04:35:29 PM Jerry Snitselaar wrote:
> > > On Tue Aug 20 13, Rafael J. Wysocki wrote:
> > > > On Monday, August 19, 2013 09:16:14 AM Mika Westerberg wrote:
> > > > > On Fri, Aug 16, 2013 at 06:26:35PM -0700, Jerry Snitselaar wrote:
> > > > > > Without MODULE_LICENSE set, I get the following with modprobe:
> > > > > > 
> > > > > > acpi_i2c: module license 'unspecified' taints kernel.
> > > > > > acpi_i2c: Unknown symbol i2c_new_device (err 0)
> > > > > > acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0)
> > > > > > acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0)
> > > > > > acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0)
> > > > > > 
> > > > > > Signed-off-by: Jerry Snitselaar 
> > > > > 
> > > > > Looks good to me.
> > > > > 
> > > > > Acked-by: Mika Westerbeg 
> > > > 
> > > > Well, OK, but do we need to be able to build that as a module?
> > > > 
> > > > Maybe it should just be yes or no?
> > > > 
> > > > Rafael
> > > > 
> > > 
> > > Perhaps have depends on I2C=y and be a bool instead of tristate?
> > 
> > Yes, that's the idea.
> > 
> Does this look okay Mika?
> 
> [PATCH] acpi_i2c: do not build as loadable module
> 
> Change from tristate to bool, and depend on I2C=y

I'm not sure about this. Does the below mean that we can't build the ACPI
I2C enumeration at all if I2C core is compiled as module?

> 
> Signed-off-by: Jerry Snitselaar 
> ---
>  drivers/acpi/Kconfig | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 100bd72..183a309 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -181,8 +181,9 @@ config ACPI_DOCK
>   drive bays such as the IBM Ultrabay and the Dell Module Bay.
>  
>  config ACPI_I2C
> -   def_tristate I2C
> -   depends on I2C
> +   bool "I2C"
> +   depends on I2C=y
> +   default n
> help
>   ACPI I2C enumeration support.
>  
> -- 
> 1.8.4.rc3.2.g2c2b664
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1] seq_file: Fix overflow condition in seq_commit

[Arun KS]

Hi Al Viro,

On Tue, Aug 20, 2013 at 11:21 AM, Al Viro  wrote:
> On Tue, Aug 20, 2013 at 10:55:40AM +0530, Arun KS wrote:
>> >From 932a134abeac597f18c86c513704709ad154994b Mon Sep 17 00:00:00 2001
>> From: Arun KS 
>> Date: Mon, 19 Aug 2013 12:06:33 +0530
>> Subject: seq_file: Fix overflow condition in seq_commit
>>
>> seq_path()/seq_commit() is treating a d_path() failure as an overflow
>> condition, but it isn't.
>>
>> seq_read handles overflow by reallocating more buffer. And this
>> continues in a loop utill we increase the size of seq buf beyond
>> KMALLOC_MAX_SIZE and hence a WARN_ON.
>>
>> [  363.192565] [ cut here ]
>> [  363.199462] WARNING: at mm/slab_common.c:377 kmalloc_slab+0x34/0x9c()
>> [  363.208557] Modules linked in:
>> [  363.212219] CPU: 1 PID: 1742 Comm: Binder_2 Tainted: GW3.10.0+ #17
>> [  363.222930] [] (unwind_backtrace+0x0/0x11c)
>> from[] (show_stack+0x10/0x14)
>> [  363.235229] [] (show_stack+0x10/0x14) from
>> [](warn_slowpath_common+0x4c/0x68)
>> [  363.247253] [] (warn_slowpath_common+0x4c/0x68)
>> from[] (warn_slowpath_null+0x18/0x1c)
>> [  363.259307] [] (warn_slowpath_null+0x18/0x1c)
>> from[] (kmalloc_slab+0x34/0x9c)
>> [  363.270812] [] (kmalloc_slab+0x34/0x9c) from
>> [](__kmalloc+0x14/0x1fc)
>> [  363.281433] [] (__kmalloc+0x14/0x1fc) from
>> [](seq_read+0x24c/0x438)
>> [  363.291992] [] (seq_read+0x24c/0x438) from
>> [](vfs_read+0xac/0x124)
>> [  363.302398] [] (vfs_read+0xac/0x124) from
>> [](SyS_read+0x3c/0x60)
>> [  363.312591] [] (SyS_read+0x3c/0x60) from
>> [](ret_fast_syscall+0x0/0x48)
>> [  363.323303] ---[ end trace 46c6467e2db7bcd4 ]---
>>
>> Pass -ENOBUFS to seq_commit to signal an overflow condition and a
>> negative value for all other errors.
>
> Excuse me, _what_ other errors?  Please, explain what errors can
> be returned by d_path/__d_path/dentry_path.  Normally all of those
> return ERR_PTR(-ENAMETOOLONG) if the pathname to be generated would
> not fit into a buffer.  In which case the only sane behaviour is
> to use a bigger buffer.

d_path expects the pathname to be less than 64 bytes. If its more than
64, it returns -ENAMETOOLONG.

File:fs/dcache.c

char *dynamic_dname(struct dentry *dentry, char *buffer, int buflen,
const char *fmt, ...)
{
va_list args;
char temp[64];
int sz;

va_start(args, fmt);
sz = vsnprintf(temp, sizeof(temp), fmt, args) + 1;
va_end(args);

if (sz > sizeof(temp) || sz > buflen)
return ERR_PTR(-ENAMETOOLONG);

buffer += buflen - sz;
return memcpy(buffer, temp, sz);
}

The string name which give error is,
"dev/ashmem/CursorWindow:
/data/data/com.android.providers.settings/databases/settings.db"

when sz>sizeof(temp), dynamic_dname returns -ENAMETOOLONG.
In this instance, sz is coming as 100.

This always happens from shared mem, after shmem_dname function was
added by the following commit.

commit 3451538a114d738a6528b1da58e19e7d8964c647
Author: Al Viro 
Date:   Thu Feb 14 22:38:02 2013 -0500

shmem_setup_file(): use d_alloc_pseudo() instead of d_alloc()

Note that provided ->d_dname() reproduces what we used to get for
those guys in e.g. /proc/self/maps; it might be a good idea to change
that to something less ugly, but for now let's keep the existing
user-visible behaviour

Signed-off-by: Al Viro 


Thanks,
Arun


>
> Could you please post the reproducer for that trace of yours?
> I might be missing something obvious, of course, but AFAICS you
> are just papering over a bug somewhere else.  If you really
> manage to get d_path() with output that wouldn't fit into 128Mb,
> you have a whole lot of unpleasant problems beyond a warning in
> seq_read().  And silent truncation of pathnames that don't happen
> to fit into what's left of the default buffer is simply wrong -
> 4095-byte pathnames are perfectly fine.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()

[Al Viro]

On Tue, Aug 20, 2013 at 12:17:52AM -0700, Ian Applegate wrote:
> We are also seeing this or a similar issue. On a fairly widespread
> deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the
> order of 36 days (combined MTBF.)

Do you have any boxen with CONFIG_DEBUG_MUTEXES among those?  What
kind of setup do you have on those, BTW?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 final tree

[Stephen Rothwell]

Hi all,

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

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_parse_options':
arch/powerpc/platforms/cell/spufs/inode.c:623:16: error: incompatible types 
when assigning to type 'kuid_t' from type 'int'
root->i_uid = option;
^
arch/powerpc/platforms/cell/spufs/inode.c:628:16: error: incompatible types 
when assigning to type 'kgid_t' from type 'int'
root->i_gid = option;
^

Caused by commit d6970d4b726c ("enable building user namespace with xfs")
from the xfs tree (that was fun to find :-)).

I have reverted that commit for today.  It could probably be replaced
with a patch that just changed XFS_FS to SPU_FS in the UIDGID_CONVERTED
config dependency - or someone could fix up SPU_FS.

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


pgp76bN7QaNKk.pgp
Description: PGP signature

Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()

[Ian Applegate]

We are also seeing this or a similar issue. On a fairly widespread
deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the
order of 36 days (combined MTBF.)

[28974.739774] [ cut here ]
[28974.744980] kernel BUG at mm/slub.c:3352!
[28974.749502] invalid opcode:  [#1] SMP
[28974.754143] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler
dm_mod md_mod nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
ip6table_raw ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack
iptable_filter xt_tcpudp xt_CT nf_conntrack xt_multiport iptable_raw
ip_tables x_tables rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 fuse
nfsv3 nfs_acl nfs fscache lockd sunrpc bonding tcp_cubic sg sfc(O) mtd
mdio igb dca i2c_algo_bit i2c_core ptp pps_core coretemp kvm_intel kvm
crc32c_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper
aes_x86_64 acpi_cpufreq evdev sd_mod crc_t10dif snd_pcm tpm_tis
microcode tpm snd_timer tpm_bios snd soundcore snd_page_alloc pcspkr
ahci libahci uhci_hcd ehci_pci ehci_hcd lpc_ich libata mfd_core
usbcore usb_common hpsa scsi_mod mperf button processor thermal_sys
[28974.835407] CPU: 17 PID: 21400 Comm: nginx-fl Tainted: G
O 3.10.1-cloudflare-trace+ #2
[28974.845307] Hardware name: HP ProLiant DL180 G6  , BIOS O20 01/24/2011
[28974.852653] task: 8805bea7b390 ti: 8809a5f0e000 task.ti:
8809a5f0e000
[28974.861095] RIP: 0010:[]  []
kfree+0x59/0xe7
[28974.869453] RSP: 0018:8809a5f0fe30  EFLAGS: 00010246
[28974.875434] RAX:  RBX: 880b21e79d40 RCX: 0028
[28974.883458] RDX: 006ffc080068 RSI: 0001183c RDI: ea002c879e40
[28974.891483] RBP: ea002c879e40 R08: 00017100 R09: ea0009ea0480
[28974.899507] R10: 880ae9746250 R11:  R12: 81119456
[28974.907533] R13: 000a R14: 8809a5f0ff48 R15: 00013b80
[28974.915558] FS:  7fb36c115710() GS:880627d6()
knlGS:
[28974.924681] CS:  0010 DS:  ES:  CR0: 80050033
[28974.931149] CR2: ff600400 CR3: 000761b93000 CR4: 07e0
[28974.939173] DR0:  DR1:  DR2: 
[28974.947190] DR3:  DR6: 0ff0 DR7: 0400
[28974.955205] Stack:
[28974.957486]  880a3e72a700 0001183c 
81119456
[28974.965873]  8809a5f0fe48  880b21e79d40
c350
[28974.974253]  8809a5f0fec0 8802b4781bc0 0200
811d96eb
[28974.982646] Call Trace:
[28974.985419]  [] ? do_readv_writev+0xfc/0x135
[28974.991987]  [] ? ep_poll+0x215/0x286
[28974.997875]  [] ? fget_light+0x2e/0x7c
[28975.003861]  [] ? fdget+0x16/0x1c
[28975.009359]  [] ? SyS_readv+0x5a/0xb0
[28975.015245]  [] ? SyS_epoll_wait+0x86/0xc1
[28975.021622]  [] ? system_call_fastpath+0x16/0x1b
[28975.028578] Code: 48 83 fb 10 0f 86 aa 00 00 00 48 89 df e8 8c de
ff ff 48 89 c7 48 89 c5 e8 b5 d7 ff ff 85 c0 75 22 48 f7 45 00 00 c0
00 00 75 02 <0f> 0b 48 89 ef e8 a8 d7 ff ff 5b 48 89 ef 89 c6 5d 41 5c
e9 9a
[28975.050651] RIP  [] kfree+0x59/0xe7
[28975.056354]  RSP 
[28975.062479] ---[ end trace 29f90372a2c3b0ac ]---

The machine hobbles along until all processes crash at this point.

[14064.855658] 
=
[14064.864884] BUG kmalloc-192 (Tainted: GW   ): Poison overwritten
[14064.872424] 
-
[14064.872424]
[14064.883322] Disabling lock debugging due to kernel taint
[14064.889304] INFO: 0x880930a54824-0x880930a54824. First byte
0x6c instead of 0x6b
[14064.898433] INFO: Allocated in alloc_pipe_info+0x17/0x94 age=80
cpu=8 pid=28897
[14064.906684]  set_track+0x5c/0xd7
[14064.910332]  alloc_debug_processing+0x76/0xfd
[14064.915250]  __slab_alloc+0x3e0/0x417
[14064.919386]  alloc_inode+0x26/0x6c
[14064.923232]  alloc_pipe_info+0x17/0x94
[14064.927467]  kmem_cache_alloc_trace+0xbe/0x14e
[14064.932486]  alloc_pipe_info+0x17/0x94
[14064.936721]  alloc_pipe_info+0x17/0x94
[14064.940956]  create_pipe_files+0x3c/0x1e5
[14064.945481]  __do_pipe_flags+0x23/0xa7
[14064.949718]  SyS_pipe2+0x18/0x86
[14064.953374]  system_call_fastpath+0x16/0x1b
[14064.958098] INFO: Freed in pipe_release+0xc4/0xcd age=76 cpu=23 pid=28897
[14064.965740]  set_track+0x5c/0xd7
[14064.969389]  free_debug_processing+0x11d/0x1a9
[14064.974391]  __slab_free+0x32/0x30a
[14064.978334]  free_pages_prepare+0x104/0x128
[14064.983053]  pipe_release+0xc4/0xcd
[14064.986991]  __fput+0xe1/0x1e4
[14064.990443]  task_work_run+0x7b/0x8f
[14064.994482]  do_notify_resume+0x59/0x68
[14064.998816]  int_signal+0x12/0x17
[14065.002561] INFO: Slab 0xea0024c29500 objects=31 used=28
fp=0x880930a570c0 flags=0x6ffc004080
[14065.013341] INFO: Object 0x880930a54820 @offset=2080
fp=0x880930a55040
[14065.023177] Bytes b4 

Re: [ANNOUNCE] 3.10.6-rt3

[Sebastian Andrzej Siewior]

On 08/20/2013 03:02 AM, Steven Rostedt wrote:
> Looking at it more, I can now see why they did what they did.

He is the only user in the whole kernel. It is somehow hard to believe
that it can't be solved differently.

> -- Steve

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

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

[Eiichi Tsukata]

(2013/08/19 23:30), James Bottomley wrote:

On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote:

Hello,

This patch adds scsi device failfast mode to avoid infinite retry loop.

Currently, scsi error handling in scsi_decide_disposition() and
scsi_io_completion() unconditionally retries on some errors. This is because
retryable errors are thought to be temporary and the scsi device will soon
recover from those errors. Normally, such retry policy is appropriate because
the device will soon recover from temporary error state.
But there is no guarantee that device is able to recover from error state
immediately. Some hardware error may prevent device from recovering.
Therefore hardware error can results in infinite command retry loop. In fact,
CHECK_CONDITION error with the sense-key = UNIT_ATTENTION caused infinite
retry loop in our environment. As the comments in kernel source code says,
UNIT_ATTENTION means the device must have been a power glitch and expected
to immediately recover from the state. But it seems that hardware error
caused permanent UNIT_ATTENTION error.

To solve the above problem, this patch introduces scsi device "failfast mode".
If failfast mode is enabled, retry counts of all scsi commands are limited to
scsi->allowed(== SD_MAX_RETRIES == 5). All commands are prohibited to retry
infinitely, and immediately fails when the retry count exceeds upper limit.
Failfast mode is useful on mission critical systems which are required
to keep running flawlessly because they need to failover to the secondary
system once they detect failures.
On default, failfast mode is disabled because failfast policy is not suitable
for most use cases which can accept I/O latency due to device hardware error.

To enable failfast mode(default disabled):
  # echo 1>  /sys/bus/scsi/devices/X:X:X:X/failfast
To disable:
  # echo 0>  /sys/bus/scsi/devices/X:X:X:X/failfast

Furthermore, I'm planning to make the upper limit count configurable.
Currently, I have two plans to implement it:
(1) set same upper limit count on all errors.
(2) set upper limit count on each error.
The first implementation is simple and easy to implement but not flexible.
Someone wants to set different upper limit count on each errors depends on the
scsi device they use. The second implementation satisfies such requirement
but can be too fine-grained and annoying to configure because scsi error
codes are so much. The default 5 times retry may too much on some errors but
too few on other errors.

Which would be the appropriate implementation?
Any comments or suggestions are welcome as usual.


I'm afraid you'll need to propose another solution.  We have a large
selection of commands which, by design, retry until the command exceeds
it's timeout.  UA is one of those (as are most of the others you're
limiting).  How do you kick this device out of its UA return (because
that's the recovery that needs to happen)?

James




Thanks for reviewing, James.

Originally, I planned that once the retry count exceeds its limit,
a monitoring tool stops the server with the scsi prink error message
as a trigger.
Current failfast mode implementation is that the command fails when
retry command exceeds its limit. However, I noticed that only printing error 
messages
on retry counts excess without changing retry logic will be enough
to stop the server and take fail over.  Though there is no guarantee that
userspace application can work properly on disk failure condition.
So, now I'm considering that just calling panic() on retry excess is better.

For that reason, I propose the solution that adding "panic_on_error" option to
sysfs parameter and if panic_on_error mode is enabled the server panics
immediately once it detects retry excess. Of course, it is disabled on default.

I would appreciate it if you could give me some comments.

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

Re: [PATCH v2 0/5] mfd: twl6030-irq: rework and add twl6032 support

[Graeme Gregory]

On 20/08/13 02:01, Samuel Ortiz wrote:

Hi Grygorii,

On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote:

This patch series intorduces twl6030-irq module rework to use Threaded IRQ and
linear irq_domain, and adds support for PMIC TWL6032 IRQs.

After this patch series TWL6030/6032 IRQs will be supported only for DT boot 
mode.

Changes since v1:
- Added new patch "mfd: twl6030-irq: create struct twl6030_irq"
   which introduces "struct twl6030_irq" to store all local variables inside it.
- Patch "mfd: twl6030-irq: migrate to IRQ threaded handler":
   Minor comments applied; fixed twl6030_exit_irq();
   The Parent IRQ has been set for each nested IRQ.
- Patch "mfd: twl6030-irq: convert to use linear irq_domain":
   The irq_find_mapping() is used in twl6030_mmc_card_detect_config()
   to get virtual IRQ number.

This looks good to me. Kevin, Graeme, any further comments/ACKs ?

Cheers,
Samuel.


Yes, it looked good to me as well.

Acked-by: Graeme Gregory 

G

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

Re: [PATCH v2] max77693: added device tree support

[Lee Jones]

On Mon, 19 Aug 2013, Stephen Warren wrote:

> On 08/19/2013 05:40 AM, Andrzej Hajda wrote:
> > max77693 mfd main device uses only wakeup field
> > from max77693_platform_data. This field is mapped
> > to wakeup-source common property in device tree.
> 
> > diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt 
> > b/Documentation/devicetree/bindings/mfd/max77693.txt
> 
> >  Optional properties:
> >  - regulators : The regulators of max77693 have to be instantiated under 
> > subnod
> >named "regulators" using the following format.
> > +- wakeup-source : Indicates if the device can wakeup the system from the 
> > sleep
> > +  state.
> 
> Does the property mean "can" or "should"?
> 
> "Can" implies that the property means something about the HW. What
> exactly does it mean; perhaps that some specific output pin of the chip
> has been wired to an input IRQ/GPIO of the SoC or PMIC that (can) wake
> up the system? If so, which pin, signal, ...? Also, doesn't this also
> depend on the SoC itself supporting its input IRQ/GPIO as a wakeup
> source, so isn't some co-ordination required between the SoC and chip,
> such that this property doesn't mean "can wakeup the system", but simply
> "a signal is routed to the SoC, so perhaps it can wakeup the system".
> 
> "Should" implies policy, which probably shouldn't be represented in
> device tree, since DT should describe the HW and not how it should be used.
> 
> Finally, if there was already a binding for max77693.txt, I don't think
> the patch subject "added device tree support" is entirely accurate; this
> change to the binding document seems to be more about adding a new
> feature than adding DT support to the driver...

I'm taking this as a NACK.

Once Stephen is happy I'll reapply any RESEND with his Ack.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 1/7] r8152: remove clearing the memory to zero for netdev priv

[David Miller]

Series applied, thanks.

Please, in the future, provide an initial "[PATCH 0/N] " posting which
gives a general overview to the series, and to which I can apply when
I have something to say about the series as a whole.

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

Re: 3.11.0-rc6+: INFO: possible circular locking dependency detected

[Bjørn Mork]

Miles Lane  writes:

> [   24.990076] [ INFO: possible circular locking dependency detected ]
> [   24.990086] 3.11.0-rc6+ #154 Not tainted
> [   24.990094] ---
> [   24.990103] crda/1159 is trying to acquire lock:
> [   24.990111]  (genl_mutex){+.+.+.}, at: []
> genl_lock+0x12/0x14
> [   24.990134]
> [   24.990134] but task is already holding lock:
> [   24.990144]  (nlk->cb_mutex){+.+.+.}, at: []
> netlink_dump+0x1c/0x1da

Yes, me too...  This is already discussed on netdev:
http://www.spinics.net/lists/stable/msg18179.html

But the fix is still out in the blue as far as I understand.  Reverting
58ad436fc will fix it, but leave the original problem (missing locking)
unfixed.


Bjørn

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

[PATCH 6/6] mfd: wl1273: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/wl1273-core.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
index 1288e99..f7c52d9 100644
--- a/drivers/mfd/wl1273-core.c
+++ b/drivers/mfd/wl1273-core.c
@@ -172,12 +172,9 @@ static int wl1273_fm_set_volume(struct wl1273_core *core, 
unsigned int volume)
 
 static int wl1273_core_remove(struct i2c_client *client)
 {
-   struct wl1273_core *core = i2c_get_clientdata(client);
-
dev_dbg(>dev, "%s\n", __func__);
 
mfd_remove_devices(>dev);
-   kfree(core);
 
return 0;
 }
@@ -203,7 +200,7 @@ static int wl1273_core_probe(struct i2c_client *client,
return -EINVAL;
}
 
-   core = kzalloc(sizeof(*core), GFP_KERNEL);
+   core = devm_kzalloc(>dev, sizeof(*core), GFP_KERNEL);
if (!core)
return -ENOMEM;
 
@@ -249,7 +246,6 @@ static int wl1273_core_probe(struct i2c_client *client,
 
 err:
pdata->free_resources();
-   kfree(core);
 
dev_dbg(>dev, "%s\n", __func__);
 
-- 
1.7.10.4


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

[PATCH 5/6] mfd: tps65010: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/tps65010.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
index 8114567..743fb52 100644
--- a/drivers/mfd/tps65010.c
+++ b/drivers/mfd/tps65010.c
@@ -530,7 +530,6 @@ static int __exit tps65010_remove(struct i2c_client *client)
free_irq(client->irq, tps);
cancel_delayed_work_sync(>work);
debugfs_remove(tps->file);
-   kfree(tps);
the_tps = NULL;
return 0;
 }
@@ -550,7 +549,7 @@ static int tps65010_probe(struct i2c_client *client,
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EINVAL;
 
-   tps = kzalloc(sizeof *tps, GFP_KERNEL);
+   tps = devm_kzalloc(>dev, sizeof(*tps), GFP_KERNEL);
if (!tps)
return -ENOMEM;
 
@@ -568,7 +567,7 @@ static int tps65010_probe(struct i2c_client *client,
if (status < 0) {
dev_dbg(>dev, "can't get IRQ %d, err %d\n",
client->irq, status);
-   goto fail1;
+   return status;
}
/* annoying race here, ideally we'd have an option
 * to claim the irq now and enable it later.
@@ -668,9 +667,6 @@ static int tps65010_probe(struct i2c_client *client,
}
 
return 0;
-fail1:
-   kfree(tps);
-   return status;
 }
 
 static const struct i2c_device_id tps65010_id[] = {
-- 
1.7.10.4


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

[PATCH 3/6] mfd: menelaus: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/menelaus.c |   16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index f24df8c..ad25bfa 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1197,7 +1197,7 @@ static int menelaus_probe(struct i2c_client *client,
return -ENODEV;
}
 
-   menelaus = kzalloc(sizeof *menelaus, GFP_KERNEL);
+   menelaus = devm_kzalloc(>dev, sizeof(*menelaus), GFP_KERNEL);
if (!menelaus)
return -ENOMEM;
 
@@ -1210,8 +1210,7 @@ static int menelaus_probe(struct i2c_client *client,
rev = menelaus_read_reg(MENELAUS_REV);
if (rev < 0) {
pr_err(DRIVER_NAME ": device not found");
-   err = -ENODEV;
-   goto fail1;
+   return -ENODEV;
}
 
/* Ack and disable all Menelaus interrupts */
@@ -1231,7 +1230,7 @@ static int menelaus_probe(struct i2c_client *client,
if (err) {
dev_dbg(>dev,  "can't get IRQ %d, err %d\n",
client->irq, err);
-   goto fail1;
+   return err;
}
}
 
@@ -1242,7 +1241,7 @@ static int menelaus_probe(struct i2c_client *client,
 
val = menelaus_read_reg(MENELAUS_VCORE_CTRL1);
if (val < 0)
-   goto fail2;
+   goto fail;
if (val & (1 << 7))
menelaus->vcore_hw_mode = 1;
else
@@ -1251,17 +1250,15 @@ static int menelaus_probe(struct i2c_client *client,
if (menelaus_pdata != NULL && menelaus_pdata->late_init != NULL) {
err = menelaus_pdata->late_init(>dev);
if (err < 0)
-   goto fail2;
+   goto fail;
}
 
menelaus_rtc_init(menelaus);
 
return 0;
-fail2:
+fail:
free_irq(client->irq, menelaus);
flush_work(>work);
-fail1:
-   kfree(menelaus);
return err;
 }
 
@@ -1271,7 +1268,6 @@ static int __exit menelaus_remove(struct i2c_client 
*client)
 
free_irq(client->irq, menelaus);
flush_work(>work);
-   kfree(menelaus);
the_menelaus = NULL;
return 0;
 }
-- 
1.7.10.4


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

[PATCH 4/6] mfd: pcf50633-adc: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/pcf50633-adc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mfd/pcf50633-adc.c b/drivers/mfd/pcf50633-adc.c
index 18b53cb..b8941a5 100644
--- a/drivers/mfd/pcf50633-adc.c
+++ b/drivers/mfd/pcf50633-adc.c
@@ -203,7 +203,7 @@ static int pcf50633_adc_probe(struct platform_device *pdev)
 {
struct pcf50633_adc *adc;
 
-   adc = kzalloc(sizeof(*adc), GFP_KERNEL);
+   adc = devm_kzalloc(>dev, sizeof(*adc), GFP_KERNEL);
if (!adc)
return -ENOMEM;
 
@@ -236,7 +236,6 @@ static int pcf50633_adc_remove(struct platform_device *pdev)
kfree(adc->queue[i]);
 
mutex_unlock(>queue_mutex);
-   kfree(adc);
 
return 0;
 }
-- 
1.7.10.4


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

[PATCH 2/6] mfd: max8998: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/max8998.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
index 45bffb8..fe6332d 100644
--- a/drivers/mfd/max8998.c
+++ b/drivers/mfd/max8998.c
@@ -188,7 +188,8 @@ static int max8998_i2c_probe(struct i2c_client *i2c,
struct max8998_dev *max8998;
int ret = 0;
 
-   max8998 = kzalloc(sizeof(struct max8998_dev), GFP_KERNEL);
+   max8998 = devm_kzalloc(>dev, sizeof(struct max8998_dev),
+   GFP_KERNEL);
if (max8998 == NULL)
return -ENOMEM;
 
@@ -246,7 +247,6 @@ err:
mfd_remove_devices(max8998->dev);
max8998_irq_exit(max8998);
i2c_unregister_device(max8998->rtc);
-   kfree(max8998);
return ret;
 }
 
@@ -257,7 +257,6 @@ static int max8998_i2c_remove(struct i2c_client *i2c)
mfd_remove_devices(max8998->dev);
max8998_irq_exit(max8998);
i2c_unregister_device(max8998->rtc);
-   kfree(max8998);
 
return 0;
 }
-- 
1.7.10.4


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

[PATCH 1/6] mfd: max8997: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/max8997.c |   14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index 1523047..cee098c 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -191,7 +191,8 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
struct max8997_platform_data *pdata = dev_get_platdata(>dev);
int ret = 0;
 
-   max8997 = kzalloc(sizeof(struct max8997_dev), GFP_KERNEL);
+   max8997 = devm_kzalloc(>dev, sizeof(struct max8997_dev),
+   GFP_KERNEL);
if (max8997 == NULL)
return -ENOMEM;
 
@@ -203,14 +204,12 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
 
if (max8997->dev->of_node) {
pdata = max8997_i2c_parse_dt_pdata(max8997->dev);
-   if (IS_ERR(pdata)) {
-   ret = PTR_ERR(pdata);
-   goto err;
-   }
+   if (IS_ERR(pdata))
+   return PTR_ERR(pdata);
}
 
if (!pdata)
-   goto err;
+   return ret;
 
max8997->pdata = pdata;
max8997->ono = pdata->ono;
@@ -250,8 +249,6 @@ err_mfd:
i2c_unregister_device(max8997->muic);
i2c_unregister_device(max8997->haptic);
i2c_unregister_device(max8997->rtc);
-err:
-   kfree(max8997);
return ret;
 }
 
@@ -263,7 +260,6 @@ static int max8997_i2c_remove(struct i2c_client *i2c)
i2c_unregister_device(max8997->muic);
i2c_unregister_device(max8997->haptic);
i2c_unregister_device(max8997->rtc);
-   kfree(max8997);
 
return 0;
 }
-- 
1.7.10.4


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

[PATCH 3/3] mfd: pm8921: use devm_*() functions

[Jingoo Han]

Use devm_*() functions to make cleanup paths simpler.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/pm8921-core.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
index 9a7c991..a6841f7 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8921-core.c
@@ -118,7 +118,7 @@ static int pm8921_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   pmic = kzalloc(sizeof(struct pm8921), GFP_KERNEL);
+   pmic = devm_kzalloc(>dev, sizeof(struct pm8921), GFP_KERNEL);
if (!pmic) {
pr_err("Cannot alloc pm8921 struct\n");
return -ENOMEM;
@@ -128,7 +128,7 @@ static int pm8921_probe(struct platform_device *pdev)
rc = ssbi_read(pdev->dev.parent, REG_HWREV, , sizeof(val));
if (rc) {
pr_err("Failed to read hw rev reg %d:rc=%d\n", REG_HWREV, rc);
-   goto err_read_rev;
+   return rc;
}
pr_info("PMIC revision 1: %02X\n", val);
rev = val;
@@ -138,7 +138,7 @@ static int pm8921_probe(struct platform_device *pdev)
if (rc) {
pr_err("Failed to read hw rev 2 reg %d:rc=%d\n",
REG_HWREV_2, rc);
-   goto err_read_rev;
+   return rc;
}
pr_info("PMIC revision 2: %02X\n", val);
rev |= val << BITS_PER_BYTE;
@@ -160,8 +160,6 @@ static int pm8921_probe(struct platform_device *pdev)
 
 err:
mfd_remove_devices(pmic->dev);
-err_read_rev:
-   kfree(pmic);
return rc;
 }
 
@@ -179,7 +177,6 @@ static int pm8921_remove(struct platform_device *pdev)
pm8xxx_irq_exit(pmic->irq_chip);
pmic->irq_chip = NULL;
}
-   kfree(pmic);
 
return 0;
 }
-- 
1.7.10.4


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

[PATCH 2/3] mfd: pm8921: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/mfd/pm8921-core.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
index bd4b37c..9a7c991 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8921-core.c
@@ -160,7 +160,6 @@ static int pm8921_probe(struct platform_device *pdev)
 
 err:
mfd_remove_devices(pmic->dev);
-   platform_set_drvdata(pdev, NULL);
 err_read_rev:
kfree(pmic);
return rc;
@@ -180,7 +179,6 @@ static int pm8921_remove(struct platform_device *pdev)
pm8xxx_irq_exit(pmic->irq_chip);
pmic->irq_chip = NULL;
}
-   platform_set_drvdata(pdev, NULL);
kfree(pmic);
 
return 0;
-- 
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 2/4] nohz: Synchronize sleep time stats with seqlock

[Fernando Luis Vázquez Cao]

(2013年08月17日 01:46), Frederic Weisbecker wrote:

On Fri, Aug 16, 2013 at 06:26:54PM +0200, Oleg Nesterov wrote:

On 08/16, Frederic Weisbecker wrote:

On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:

+   do {
+   seq = read_seqcount_begin(>sleeptime_seq);
+   if (ts->idle_active && nr_iowait_cpu(cpu) > 0) {
+   ktime_t delta = ktime_sub(now, ts->idle_entrytime);
+   iowait = ktime_add(ts->iowait_sleeptime, delta);
+   } else {
+   iowait = ts->iowait_sleeptime;
+   }
+   } while (read_seqcount_retry(>sleeptime_seq, seq));

Unless I missread this patch, this is still racy a bit.

Suppose it is called on CPU_0 and cpu == 1. Suppose that
ts->idle_active == T and nr_iowait_cpu(cpu) == 1.

So we return iowait_sleeptime + delta.

Suppose that we call get_cpu_iowait_time_us() again. By this time
the task which incremented ->nr_iowait can be woken up on another
CPU, and it can do atomic_dec(rq->nr_iowait). So the next time
we return iowait_sleeptime, and this is not monotonic again.

Hmm, by the time it decrements nr_iowait, it returned from schedule() and
so idle had flushed the pending iowait sleeptime.

Suppose a task does io_schedule() on CPU_0, and increments the counter.
This CPU becomes idle and nr_iowait_cpu(0) == 1.

Then this task is woken up, but try_to_wake_up() selects another CPU != 0.

It returns from schedule() and decrements the same counter, it doesn't
do raw_rq/etc again. nr_iowait_cpu(0) becomes 0.

In fact the task can even migrate to another CPU right after raw_rq().

Ah I see now. So that indeed yet another race.


I am sorry for chiming in late.

That precisely the race I described here:

https://lkml.org/lkml/2013/7/2/3

I should have been more concise in my explanation. I apologize.


Should we flush that iowait to the src CPU? But then it means we must handle
concurrent updates to iowait_sleeptime, idle_sleeptime from the migration
code and from idle enter / exit.

So I fear we need a seqlock.

Or we can live with that and still account the whole idle time slept until
tick_nohz_stop_idle() to iowait if we called tick_nohz_start_idle() with nr_iowait 
> 0.
All we need is just a new field in ts-> that records on which state we entered
idle.


Another approach could be to shadow ->iowait_sleeptime as
suggested here: https://lkml.org/lkml/2013/7/2/165
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mfd: pm8921: include missing linux/module.h

[Jingoo Han]

Include  in order to fix the following errors.

drivers/mfd/pm8921-core.c:209:16: error: expected declaration specifiers or 
'...' before string constant
drivers/mfd/pm8921-core.c:210:20: error: expected declaration specifiers or 
'...' before string constant
drivers/mfd/pm8921-core.c:211:16: error: expected declaration specifiers or 
'...' before string constant
drivers/mfd/pm8921-core.c:212:14: error: expected declaration specifiers or 
'...' before string constant

Signed-off-by: Jingoo Han 
---
 drivers/mfd/pm8921-core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
index 9be6840..bd4b37c 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8921-core.c
@@ -14,6 +14,7 @@
 #define pr_fmt(fmt) "%s: " fmt, __func__
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
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 2/4] nohz: Synchronize sleep time stats with seqlock

[Fernando Luis Vázquez Cao]

(2013年08月19日 20:10), Peter Zijlstra wrote:

On Fri, Aug 16, 2013 at 06:46:28PM +0200, Frederic Weisbecker wrote:

Option A:


Should we flush that iowait to the src CPU? But then it means we must handle
concurrent updates to iowait_sleeptime, idle_sleeptime from the migration
code and from idle enter / exit.

So I fear we need a seqlock.

Option B:


Or we can live with that and still account the whole idle time slept until
tick_nohz_stop_idle() to iowait if we called tick_nohz_start_idle() with nr_iowait 
> 0.
All we need is just a new field in ts-> that records on which state we entered
idle.

What do you think?

I think option B is unworkable. Afaict it could basically caused
unlimited iowait time. Suppose we have a load-balancer that tries it
bestestest to sort-left (ie. run a task on the lowest 'free' cpu
possible) -- the power aware folks are pondering such schemes.

Now suppose we have a small burst of activity and the rightmost cpu gets
to run something that goes to sleep on iowait.

We'd accrue iowait on that cpu until it wakes up, which could be days
from now if the load stays low enough, even though the task got to run
almost instantly on another cpu.

So no, if we need per-cpu iowait time we have to do A.

Since we already have atomics in the io_schedule*() paths, please
replace those with (seq)locks. Also see if you can place the entire
iowait accounting thing in a separate cacheline.


I considered option A for a while but, fearing it would be
considered overkill, took a different approach: create a
shadow copy of ->iowait_sleeptime that is always kept
monotonic (artificially in some cases) and use that to
compute the values exported through /proc.

That said, if deemed acceptable, option A is the one I would
choose.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Revert "Revert "math64: New div64_u64_rem helper""

[Stanislaw Gruszka]

On Fri, Aug 09, 2013 at 03:56:03PM -0400, Mike Snitzer wrote:
> This reverts commit f3002134158092178be81339ec5a22ff80e6c308.
> 
> div64_u64_rem was removed because there were no other users.
> 
> But Device Mapper's I/O statistics support has a need for
> div64_u64_rem; reintroduce this helper.

This slows down div64_u64 operation, especially on 32-bit systems.

Since dm statistic code is possibly not performance critical
perhaps you could use something like below instead to calculate
remainder:

res = div64_u64(a, b);
rem = a - b*res;

Stanislaw

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

Re: [RESEND PATCH 2/4] ARM: msm: Re-organize platsmp to make it extensible

[David Rientjes]

On Mon, 12 Aug 2013, Mark Rutland wrote:

> >  static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
> >  {
> > +   int cpu, map;
> > +   unsigned int flags = 0;
> > +
> > +   for_each_present_cpu(cpu) {
> > +   map = cpu_logical_map(cpu);
> > +   if (map > ARRAY_SIZE(cold_boot_flags)) {
> > +   set_cpu_present(cpu, false);
> > +   __WARN();
> > +   continue;
> > +   }
> > +   flags |= cold_boot_flags[map];

__WARN() can't be used in generic code because it's possible to have 
CONFIG_BUG=n, you probably want something like WARN_ON(1) instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] mm/vmalloc: use wrapper function get_vm_area_size to caculate size of vm area

[Wanpeng Li]

v1 -> v2:
 * replace all the spots by function get_vm_area_size().

Use wrapper function get_vm_area_size to calculate size of vm area.

Signed-off-by: Wanpeng Li 
---
 mm/vmalloc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 93d3182..1074543 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1258,7 +1258,7 @@ void unmap_kernel_range(unsigned long addr, unsigned long 
size)
 int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page ***pages)
 {
unsigned long addr = (unsigned long)area->addr;
-   unsigned long end = addr + area->size - PAGE_SIZE;
+   unsigned long end = addr + get_vm_area_size(area);
int err;
 
err = vmap_page_range(addr, end, prot, *pages);
@@ -1553,7 +1553,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, 
gfp_t gfp_mask,
unsigned int nr_pages, array_size, i;
gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
 
-   nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
+   nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));
 
area->nr_pages = nr_pages;
@@ -1985,7 +1985,7 @@ long vread(char *buf, char *addr, unsigned long count)
 
vm = va->vm;
vaddr = (char *) vm->addr;
-   if (addr >= vaddr + vm->size - PAGE_SIZE)
+   if (addr >= vaddr + get_vm_area_size(vm))
continue;
while (addr < vaddr) {
if (count == 0)
@@ -1995,7 +1995,7 @@ long vread(char *buf, char *addr, unsigned long count)
addr++;
count--;
}
-   n = vaddr + vm->size - PAGE_SIZE - addr;
+   n = vaddr + get_vm_area_size(vm) - addr;
if (n > count)
n = count;
if (!(vm->flags & VM_IOREMAP))
@@ -2067,7 +2067,7 @@ long vwrite(char *buf, char *addr, unsigned long count)
 
vm = va->vm;
vaddr = (char *) vm->addr;
-   if (addr >= vaddr + vm->size - PAGE_SIZE)
+   if (addr >= vaddr + get_vm_area_size(vm))
continue;
while (addr < vaddr) {
if (count == 0)
@@ -2076,7 +2076,7 @@ long vwrite(char *buf, char *addr, unsigned long count)
addr++;
count--;
}
-   n = vaddr + vm->size - PAGE_SIZE - addr;
+   n = vaddr + get_vm_area_size(vm) - addr;
if (n > count)
n = count;
if (!(vm->flags & VM_IOREMAP)) {
-- 
1.8.1.2

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

[PATCH v2 2/4] mm/sparse: introduce alloc_usemap_and_memmap

[Wanpeng Li]

v1 -> v2:
 * add comments to describe alloc_usemap_and_memmap 

After commit 9bdac91424075("sparsemem: Put mem map for one node together."),
vmemmap for one node will be allocated together, its logic is similar as
memory allocation for pageblock flags. This patch introduce 
alloc_usemap_and_memmap
to extract the same logic of memory alloction for pageblock flags and vmemmap.

Signed-off-by: Wanpeng Li 
---
 mm/sparse.c | 140 
 1 file changed, 66 insertions(+), 74 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index 308d503..d27db9b 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -439,6 +439,14 @@ static void __init sparse_early_mem_maps_alloc_node(struct 
page **map_map,
 map_count, nodeid);
 }
 #else
+
+static void __init sparse_early_mem_maps_alloc_node(struct page **map_map,
+   unsigned long pnum_begin,
+   unsigned long pnum_end,
+   unsigned long map_count, int nodeid)
+{
+}
+
 static struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
 {
struct page *map;
@@ -460,6 +468,62 @@ void __attribute__((weak)) __meminit 
vmemmap_populate_print_last(void)
 {
 }
 
+/**
+ *  alloc_usemap_and_memmap - memory alloction for pageblock flags and vmemmap
+ *  @map: usemap_map for pageblock flags or mmap_map for vmemmap
+ *  @use_map: true if memory allocated for pageblock flags, otherwise false
+ */
+static void alloc_usemap_and_memmap(unsigned long **map, bool use_map)
+{
+   unsigned long pnum;
+   unsigned long map_count;
+   int nodeid_begin = 0;
+   unsigned long pnum_begin = 0;
+
+   for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+   struct mem_section *ms;
+
+   if (!present_section_nr(pnum))
+   continue;
+   ms = __nr_to_section(pnum);
+   nodeid_begin = sparse_early_nid(ms);
+   pnum_begin = pnum;
+   break;
+   }
+   map_count = 1;
+   for (pnum = pnum_begin + 1; pnum < NR_MEM_SECTIONS; pnum++) {
+   struct mem_section *ms;
+   int nodeid;
+
+   if (!present_section_nr(pnum))
+   continue;
+   ms = __nr_to_section(pnum);
+   nodeid = sparse_early_nid(ms);
+   if (nodeid == nodeid_begin) {
+   map_count++;
+   continue;
+   }
+   /* ok, we need to take cake of from pnum_begin to pnum - 1*/
+   if (use_map)
+   sparse_early_usemaps_alloc_node(map, pnum_begin, pnum,
+map_count, nodeid_begin);
+   else
+   sparse_early_mem_maps_alloc_node((struct page **)map,
+   pnum_begin, pnum, map_count, nodeid_begin);
+   /* new start, update count etc*/
+   nodeid_begin = nodeid;
+   pnum_begin = pnum;
+   map_count = 1;
+   }
+   /* ok, last chunk */
+   if (use_map)
+   sparse_early_usemaps_alloc_node(map, pnum_begin,
+   NR_MEM_SECTIONS, map_count, nodeid_begin);
+   else
+   sparse_early_mem_maps_alloc_node((struct page **)map,
+   pnum_begin, NR_MEM_SECTIONS, map_count, nodeid_begin);
+}
+
 /*
  * Allocate the accumulated non-linear sections, allocate a mem_map
  * for each and record the physical to section mapping.
@@ -471,11 +535,7 @@ void __init sparse_init(void)
unsigned long *usemap;
unsigned long **usemap_map;
int size;
-   int nodeid_begin = 0;
-   unsigned long pnum_begin = 0;
-   unsigned long usemap_count;
 #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
-   unsigned long map_count;
int size2;
struct page **map_map;
 #endif
@@ -501,82 +561,14 @@ void __init sparse_init(void)
usemap_map = alloc_bootmem(size);
if (!usemap_map)
panic("can not allocate usemap_map\n");
-
-   for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
-   struct mem_section *ms;
-
-   if (!present_section_nr(pnum))
-   continue;
-   ms = __nr_to_section(pnum);
-   nodeid_begin = sparse_early_nid(ms);
-   pnum_begin = pnum;
-   break;
-   }
-   usemap_count = 1;
-   for (pnum = pnum_begin + 1; pnum < NR_MEM_SECTIONS; pnum++) {
-   struct mem_section *ms;
-   int nodeid;
-
-   if (!present_section_nr(pnum))
-   continue;
-   ms = __nr_to_section(pnum);
-   nodeid = sparse_early_nid(ms);
-   if (nodeid == nodeid_begin) {
-   usemap_count++;
-   continue;
-  

[PATCH V2] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking on ioapic_lock

[Yoshihiro YUNOMAE]

Prevent crash_kexec() from deadlocking on ioapic_lock. When crash_kexec()
is executed on a cpu, the cpu will get ioapic_lock in disable_IO_APIC().
So if the cpu gets NMI while locking ioapic_lock, a deadlock will happen.
In this patch, ioapic_lock is initialized before disable_IO_APIC().

To confirm this deadlock, you'll set up as follows:

1. Add mdelay(1000) after raw_spin_lock_irqsave() in
   native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c

   Although the deadlock can occur without this modification, it will increase
  the potential of the deadlock problem.

2. Build and install the kernel

3. Set up the OS which will run panic() and kexec when NMI is injected
# echo "kernel.unknown_nmi_panic=1" >> /etc/sysctl.conf
# vim /etc/default/grub
  add "nmi_watchdog=0 crashkernel=256M" in GRUB_CMDLINE_LINUX line
# grub2-mkconfig

4. Reboot the OS

5. Run following command for each vcpu on the guest
# while true; do echo  > /proc/irq//smp_affinitity; done;
   By running this command, cpus will get ioapic_lock for setting affinity.

6. Inject NMI (push a dump button or execute 'virsh inject-nmi ' if you
   use VM)
   After injecting NMI, panic() is called in an nmi-handler context.
   Then, kexec will normally run in panic(), but the operation will be stopped
   by deadlock on ioapic_lock in crash_kexec()->machine_crash_shutdown()->
   native_machine_crash_shutdown()->disable_IO_APIC()->clear_IO_APIC()->
   clear_IO_APIC_pin()->ioapic_read_entry().

Changes in V2: Fix typos, change ioapic_lock_init() to ioapic_zap_locks(),
   and change "#if defined(CONFIG_X86_IO_APIC)" to
   "#ifdef CONFIG_X86_IO_APIC".

Signed-off-by: Yoshihiro YUNOMAE 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Andrew Morton 
Cc: Andi Kleen 
Cc: Seiji Aguchi 
Cc: Konrad Rzeszutek Wilk 
Cc: Sebastian Andrzej Siewior 
Cc: Joerg Roedel 
Cc: Zhang Yanfei 
Cc: "Eric W. Biederman" 
Cc: Gleb Natapov 
Cc: Marcelo Tosatti 
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 arch/x86/include/asm/apic.h|2 ++
 arch/x86/kernel/apic/io_apic.c |5 +
 arch/x86/kernel/crash.c|4 +++-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..1d2091a 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
 }
 
+extern void ioapic_zap_locks(void);
+
 #endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..260abc2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
 }
 
+void ioapic_zap_locks(void)
+{
+   raw_spin_lock_init(_lock);
+}
+
 __apicdebuginit(void) print_IO_APIC(int ioapic_idx)
 {
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..e0e0841 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -128,7 +128,9 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
cpu_emergency_svm_disable();
 
lapic_shutdown();
-#if defined(CONFIG_X86_IO_APIC)
+#ifdef CONFIG_X86_IO_APIC
+   /* Prevent crash_kexec() from deadlocking on ioapic_lock. */
+   ioapic_zap_locks();
disable_IO_APIC();
 #endif
 #ifdef CONFIG_HPET_TIMER

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

[PATCH v2 1/4] mm/pgtable: Fix continue to preallocate pmds even if failure occurrence

[Wanpeng Li]

v1 -> v2:
 * remove failed.

preallocate_pmds will continue to preallocate pmds even if failure
occurrence, and then free all the preallocate pmds if there is
failure, this patch fix it by stop preallocate if failure occurrence
and go to free path.

Reviewed-by: Dave Hansen 
Signed-off-by: Wanpeng Li 
---
 arch/x86/mm/pgtable.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index dfa537a..65c2106 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -196,21 +196,18 @@ static void free_pmds(pmd_t *pmds[])
 static int preallocate_pmds(pmd_t *pmds[])
 {
int i;
-   bool failed = false;
 
for(i = 0; i < PREALLOCATED_PMDS; i++) {
pmd_t *pmd = (pmd_t *)__get_free_page(PGALLOC_GFP);
if (pmd == NULL)
-   failed = true;
+   goto err;
pmds[i] = pmd;
}
 
-   if (failed) {
-   free_pmds(pmds);
-   return -ENOMEM;
-   }
-
return 0;
+err:
+   free_pmds(pmds);
+   return -ENOMEM;
 }
 
 /*
-- 
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/

clk: Xilinx Zynq changes for v3.12

[Michal Simek]

Hi Mike,

as we discussed with Kevin in my arm-soc pull request I should send
these two patches separately and directly to you.
I have rebased them on 3.11-rc2 which is the kernel version you have in
your clk-next branch. Thanks for pulling them.

Thanks,
Michal

The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:

  Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)

are available in the git repository at:

  git://git.xilinx.com/linux-xlnx.git tags/zynq-clk-for-3.12

for you to fetch changes up to 353dc6c47d67c83f7cc20334f8deb251674e6864:

  clk/zynq/pll: Use #defines for fbdiv min/max values (2013-08-20 07:54:41 
+0200)


arm: Xilinx Zynq clock changes for v3.12

Just small two changes where the first fixes
documentation and the second improves
code readability.


Soren Brinkmann (2):
  clk/zynq/pll: Fix documentation for PLL register function
  clk/zynq/pll: Use #defines for fbdiv min/max values

 drivers/clk/zynq/pll.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH V3 1/2] tps6507x-ts: Add DT support

[Manish Badarkhe]

Hi Prabhakar,

On Tue, Aug 20, 2013 at 11:44 AM, Prabhakar Lad
 wrote:
> Hi Manish,
>
> Thanks for the patch.
>
> On Tue, May 21, 2013 at 2:24 PM, Vishwanathrao Badarkhe, Manish
>  wrote:
>> Add device tree based support for TI's tps6507x touchscreen.
>>
>> Tested on da850-evm.
>>
>> Signed-off-by: Vishwanathrao Badarkhe, Manish 
>> ---
>> Changes since V2:
>>  - Removed unnecessary code.
>>  - Updated Documentation to provide proper names of
>>devicetree properties.
>>
>> Changes since V1:
>>  - Updated documentation to specify tps6507x as multifunctional
>>device.
>>  - return proper error value in absence of platform and DT
>>data for touchscreen.
>>  - Updated commit message.
>>
>> :100755 100755 8fffa3c... 65ee2cd... M  
>> Documentation/devicetree/bindings/mfd/tps6507x.txt
>> :100644 100644 65e0f9a... 89232ee... M  
>> drivers/input/touchscreen/tps6507x-ts.c
>>  Documentation/devicetree/bindings/mfd/tps6507x.txt |   28 ++-
>>  drivers/input/touchscreen/tps6507x-ts.c|   98 
>> ++--
>>  2 files changed, 95 insertions(+), 31 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt 
>> b/Documentation/devicetree/bindings/mfd/tps6507x.txt
>> index 8fffa3c..65ee2cd 100755
>> --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
>> @@ -1,4 +1,8 @@
>> -TPS6507x Power Management Integrated Circuit
>> +TPS6507x Multifunctional Device.
>> +
>> +Features provided by TPS6507x:
>> +1.Power Management Integrated Circuit.
>> +2.Touch-Screen.
>>
>>  Required properties:
>>  - compatible: "ti,tps6507x"
>> @@ -23,6 +27,12 @@ Required properties:
>> vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
>> vindcdc3-supply  : VDCDC3 input.
>> vldo1_2-supply   : VLDO1 and VLDO2 input.
>> +- tsc: This node specifies touch screen data.
>> +   ti,poll-period : Time at which touch input is getting sampled in ms.
>> +   ti,min-pressure: Minimum pressure value to trigger touch.
>> +   ti,vref: voltage reference for ADC.
>> + 0: Reference voltage for ADC is disabled.
>> + 1: Reference voltage for ADC is enabled.
>>
>>  Regulator Optional properties:
>>  - defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
>> @@ -30,6 +40,14 @@ Regulator Optional properties:
>> 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
>>If this property is not defined, it defaults to 0 (not enabled).
>>
>> +Touchscreen Optional properties:
>> +- ti,vendor : Touchscreen vendor id to populate
>> + in sysclass interface.
>> +- ti,product: Touchscreen product id to populate
>> + in sysclass interface.
>> +- ti,version: Touchscreen version id to populate
>> + in sysclass interface.
>> +
>>  Example:
>>
>> pmu: tps6507x@48 {
>> @@ -88,4 +106,12 @@ Example:
>> };
>> };
>>
>> +   tsc {
>> +   ti,poll-period = <30>;
>> +   ti,min-pressure = <0x30>;
>> +   ti,vref = <0>;
>> +   ti,vendor = <0>;
>> +   ti,product = <65070>;
>> +   ti,version = <0x100>;
>> +   };
>> };
>> diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
>> b/drivers/input/touchscreen/tps6507x-ts.c
>> index 65e0f9a..89232ee 100644
>> --- a/drivers/input/touchscreen/tps6507x-ts.c
>> +++ b/drivers/input/touchscreen/tps6507x-ts.c
>> @@ -21,6 +21,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>>  #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
>>  #define TPS_DEFAULT_MIN_PRESSURE 0x30
>> @@ -231,36 +233,76 @@ done:
>> ret = tps6507x_adc_standby(tsc);
>>  }
>>
>> +static int tsc_init_data(struct tps6507x_dev *tps6507x_dev,
>> +   struct input_dev *input_dev)
>> +{
>> +   struct device_node *node = tps6507x_dev->dev->of_node;
>> +   struct tps6507x_board *tps_board =
>> +   (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
>> +   struct touchscreen_init_data *init_data = NULL;
>> +   int err;
>> +
>> +   if (node)
>> +   node = of_find_node_by_name(node, "tsc");
>> +   if (tps_board)
>> +   init_data = tps_board->tps6507x_ts_init_data;
>> +
>> +   if (node == NULL || init_data == NULL) {
>> +   err = -EINVAL;
>> +   goto error_ret;
>> +   } else if (init_data) {
>> +   tps6507x_dev->ts->poll_period = init_data->poll_period;
>> +   tps6507x_dev->ts->min_pressure = init_data->min_pressure;
>> +   tps6507x_dev->ts->vref = init_data->vref;
>> +   input_dev->id.vendor = init_data->vendor;
>> +   input_dev->id.product = init_data->product;
>> +   input_dev->id.version = init_data->version;
>> +   } 

BUG: kernel panic after jbd bugs / kernel paging request

[kardan]

Dear developers,

At first thanks for all your work!

kernel version: 3.9.9-t23
kernel config: https://paste.debian.net/27351/
lspci -nvv output is attached.

I merged two kernel issues into one mail to find relations easier.

As both appeared only once I did not invest more time to try with
newer kernels. But I will do so for testing patches. Please give me
pointers where to dig in for reproducing.

1) jbd2_journal_dirty_metadata

I reported this in #linuxfs and was confirmed to forward it here.

12:55 < kardan:#linuxfs> it seems like my hdd is hanging (hdd led
turned. jbd is buzy for over an hour now:
1326 be/3 root  0.00 B 16.00 K  0.00 % 98.47 % [jbd2/sda1-8]

The load was caused by iceape (or something stacked below)
#1  0xb764680e in wait4 () at ../sysdeps/unix/syscall-template.S:81
#2  0xb76467e7 in __wait3 (stat_loc=..., options=0, usage=0x0)
at ../sysdeps/unix/bsd/bsd4.4/wait3.c:3312:55 

This led to several jbd related kernel bugs and a kernel panic in
the end. I attached the jbd-schedulings-bugs to avoid wrapping issues.

jbd2_journal_dirty_metadata+0x162/0x188
kmem_cache_alloc+0x26/0x9f
spin_unlock.isra.6+0x1e/0x1e
ext4_file_open+0x13e/0x1b2 
spin_lock.isra.7+0xa/0xb 
__d_instantiate+0x59/0x63 
fsnotify_perm+0x4d/0x58

__schedule_bug+0x39/0x49
__schedule+0x54/0x4e4 
ttwu_do_wakeup.constprop.111+0x39/0x56
try_to_wake_up+0xe7/0xef 
autoremove_wake_function+0xd/0x29 
activate_page+0xae/0xfc 
__cond_resched+0xf/0x19 
_cond_resched+0x10/0x18
Aug 15 18:06:10 delight
unmap_single_vma+0x3fc/0x49c 
unmap_vmas+0x30/0x4d 
exit_mmap+0x68/0xcb
get_signal_to_deliver+0x202/0x4d1 

kmem_cache_alloc+0x26/0x9f
spin_unlock.isra.6+0x1e/0x1e
ext4_file_open+0x13e/0x1b2 
fsnotify+0x1fa/0x22c
__d_instantiate+0x59/0x63

__schedule_bug+0x39/0x49
_schedule+0x54/0x4e4 
blk_peek_request+0x16f/0x1a4 
scsi_request_fn+0x35d/0x3fe 
activate_page+0xae/0xfc 
__cond_resched+0xf/0x19 
_cond_resched+0x10/0x18
unmap_single_vma+0x3fc/0x49c 
unmap_vmas+0x30/0x4d 
exit_mmap+0x68/0xcb
get_signal_to_deliver+0x202/0x4d1

__schedule_bug+0x39/0x49
__schedule+0x54/0x4e4 
__free_one_page+0xeb/0x1c4 
free_pcppages_bulk+0xbb/0x103
__cond_resched+0xf/0x19 
_cond_resched+0x10/0x18 
unmap_single_vma+0x3fc/0x49c 
unmap_vmas+0x30/0x4d
exit_mmap+0x68/0xcb
get_signal_to_deliver+0x202/0x4d1

 __schedule_bug+0x39/0x49
__schedule+0x54/0x4e4 
smp_apic_timer_interrupt+0x58/0x60 
apic_timer_interrupt+0x34/0x3c
activate_page+0xae/0xfc
__cond_resched+0xf/0x19 
_cond_resched+0x10/0x18 
unmap_single_vma+0x3fc/0x49c 
unmap_vmas+0x30/0x4d 
exit_mmap+0x68/0xcb

 __schedule_bug+0x39/0x49
__schedule+0x54/0x4e4 
vm_acct_memory+0x26/0x3c
__cache_free.isra.57+0xf/0x8f
 percpu_counter_add.constprop.21+0x26/0x3e 
spin_lock.isra.7+0xa/0xb
 dput+0x11/0x96 
spin_unlock.isra.11+0xa/0x1e 
__fput+0x15f/0x17e
mnt_add_count.isra.16+0x1c/0x34 
__cond_resched+0xf/0x19 
_cond_resched+0x10/0x18 
task_work_run+0x4f/0x5a 
do_exit+0x2c6/0x796 
kmsg_dump+0x1d/0xcc 
oops_end+0x86/0x8a 
do_bounds+0x4c/0x4c

 Full log: https://paste.debian.net/27347/

2) unable to handle kernel paging request

INFO: task kswapd0:21 blocked for more than 120 seconds.
[289200.502665]  [] ? kmem_cache_alloc+0x2f/0x9f
[289200.502677]  [] ? mempool_alloc+0x3b/0xee
[289200.502690]  [] ? timekeeping_get_ns.constprop.
[289200.502703]  [] ? io_schedule+0x34/0x47
[289200.502715]  [] ? get_request+0x416/0x4ae
[289200.502728]  [] ? native_sched_clock+0x48/0x94
[289200.502741]  [] ? ioc_lookup_icq+0x41/0x49

[289800.503037] INFO: task kswapd0:21 blocked for more than 120 seconds.
[289800.503126]  [] ? sched_slice.isra.36+0x67/0x85
[289800.503139]  [] ? timekeeping_get_ns.constprop.
[289800.503153] [] ? io_schedule+0x34/0x47 
[289800.503165] [] ? get_request+0x416/0x4ae 
[289800.503178]  [] ? ioc_lookup_icq+0x41/0x49 
[289800.503189]  [] ? abort_exclusive_wait+0x64/0x64 
[289800.503199]  [] ? blk_queue_bio+0x185/0x26d

This issue dates back some weeks, sorry for not reporting earlear.

I had two occurances of this with several days in between. 
One week before the first occurence a new ram bank and a PCMCIA card
usb hub was added to the laptop.

Some days ago I saw a lot of IO errors once, they did not reappear.
On #linux-fs it was said the first one looks like use-after-free or
some other type of software-induced memory corruption. 

"Those tend to be nasty problems that can take months to track down
some of the crazy-looking problems end up as bad hardware.

have you also experienced crashes of userspace programs?"
kswap/kworker were followed by Xorg, iceweasel, claws and Xorg.

Awesome was inresponsive afterwards and I needed the restart lightdm.
In a new X session parts of old windows reappeared, this was
reproducable.

Log is attached.

-- 
Kardan 
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558


kernel-paging-bug
Description: Binary data


lspci
Description: Binary data

[PATCH v2 3/4] mm/writeback: make writeback_inodes_wb static

[Wanpeng Li]

It's not used globally and could be static.

Signed-off-by: Wanpeng Li 
---
 fs/fs-writeback.c | 2 +-
 include/linux/writeback.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 87d7781..54b3c31 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -723,7 +723,7 @@ static long __writeback_inodes_wb(struct bdi_writeback *wb,
return wrote;
 }
 
-long writeback_inodes_wb(struct bdi_writeback *wb, long nr_pages,
+static long writeback_inodes_wb(struct bdi_writeback *wb, long nr_pages,
enum wb_reason reason)
 {
struct wb_writeback_work work = {
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 4e198ca..021b8a3 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -98,8 +98,6 @@ int try_to_writeback_inodes_sb(struct super_block *, enum 
wb_reason reason);
 int try_to_writeback_inodes_sb_nr(struct super_block *, unsigned long nr,
  enum wb_reason reason);
 void sync_inodes_sb(struct super_block *);
-long writeback_inodes_wb(struct bdi_writeback *wb, long nr_pages,
-   enum wb_reason reason);
 void wakeup_flusher_threads(long nr_pages, enum wb_reason reason);
 void inode_wait_for_writeback(struct inode *inode);
 
-- 
1.8.1.2

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

Re: [PATCH 1/2] extcon: extcon-dra7xx: Add extcon driver for USB ID detection

[George Cherian]

Hi Stephen,

Thanks for your review.

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


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

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

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


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



+ - compatible : Should be "ti,dra7xx-usb"

If this is a USB VID detector rather than a full USB host controller,
then "usb" in the binding is a bit over-reaching. Perhaps "-usb-vid" or
"-usb-vid-detector" would be more accurate.


This will be renamed to dra7xx-extcon.



+ - gpios : phandle to ID pin and interrupt gpio.

This isn't just a phandle; it's phandle+args, or a GPIO specifier. Some
reference should be made to ../gpio/gpio.txt for the format.


okay

Why does the interrupt line need to be included in a list of GPIOs?


ID pins are connected to pcf8575, and the pcf8575's interrupt line is 
inturn connected to

gpio bank6 pin 11, we use this gpio interrupt to detect the ID pin change.

If the DRA7xxx is a VID detector, why does it even need/have any GPIOs
associated with it; surely it has a dedicated VID input pin. Can you
provide more details re: how the HW is structured.


+Optional Properties:
+  - interrupt-parent : interrupt controller phandle
+  - interrupts : interrupt number
+
+

It's typical insert the following between those two blank lines:

Example:

... or delete one of the blank lines.


+dra7x_extcon1 {
+   compatible = "ti,dra7xx-usb";
+   gpios = <_usb 1 0>,
+   < 11 2>;
+   interrupt-parent = <>;
+   interrupts = <11>;
+   };
+

No need for that trailing blank line.


okay





--
-George

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

[Borislav Petkov]

On Mon, Aug 19, 2013 at 07:27:51PM -0500, Aravind Gopalakrishnan wrote:
> Aravind Gopalakrishnan (1):
>   AMD64_EDAC: Fix incorrect wrap arounds due to left shift beyond 32
> bits.
> 
>  drivers/edac/amd64_edac.c |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

Just a minor thing: when you send one patch only, you don't really need
the 0/1 email.

Thanks.

-- 
Regards/Gruss,
Boris.

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

Re: [Patch net-next v3 9/9] selinux: use generic union inet_addr

[David Miller]

From: Casey Schaufler 
Date: Mon, 19 Aug 2013 14:42:55 -0700

> On 8/19/2013 12:50 PM, David Miller wrote:
>> It's so that you can pass a generic ipv4/ipv6 address blob into
>> things like printf formatting, and since there is an address family
>> member present, it knows what's in there and therefore one printf
>> format specifier can handle both ipv4 and ipv6 addresses.
> 
> The patch message needs to say that, then.

Actually, that belongs in the "0/N" posting, the contents of which
will end up in the merge commit should I apply the series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()

[Cyrill Gorcunov]

On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
> 
> need "if (ret < 0)" instead of.  ;-)

sure, it's details

> 
> > sure you'll have to change shmem_show_mpol statement to return int code.
> > Won't this be more short and convenient?
> > 
> > 
> 
> Hmm... if return -ENOSPC, in common processing, it still need continue
> (but need let outside know about the string truncation).
> 
> So I still suggest to give more check for it.

I still don't like adding additional code like

+   ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+   if (ret < 0)
+   switch (ret) {
+   case -ENOSPC:
+   printk(KERN_WARNING
+   "in %s: string is truncated in 
mpol_to_str().\n",
+   __func__);
+   default:
+   printk(KERN_ERR
+   "in %s: call mpol_to_str() fail, errcode: %d. 
buffer: %p, size: %zu, pol: %p\n",
+   __func__, ret, buffer, sizeof(buffer), mpol);
+   return;
+   }

this code is pretty neat for debugging purpose I think but in most case (if
only I've not missed something obvious) it simply won't be the case.

Won't somthing like below do the same but with smaller code change?
Note I've not even compiled it but it shows the idea.
---
 fs/proc/task_mmu.c |4 +++-
 mm/shmem.c |   17 +
 2 files changed, 12 insertions(+), 9 deletions(-)

Index: linux-2.6.git/fs/proc/task_mmu.c
===
--- linux-2.6.git.orig/fs/proc/task_mmu.c
+++ linux-2.6.git/fs/proc/task_mmu.c
@@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
walk.mm = mm;
 
pol = get_vma_policy(task, vma, vma->vm_start);
-   mpol_to_str(buffer, sizeof(buffer), pol);
+   n = mpol_to_str(buffer, sizeof(buffer), pol);
mpol_cond_put(pol);
+   if (n < 0)
+   return n;
 
seq_printf(m, "%08lx %s", vma->vm_start, buffer);
 
Index: linux-2.6.git/mm/shmem.c
===
--- linux-2.6.git.orig/mm/shmem.c
+++ linux-2.6.git/mm/shmem.c
@@ -883,16 +883,20 @@ redirty:
 
 #ifdef CONFIG_NUMA
 #ifdef CONFIG_TMPFS
-static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
+static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
 {
char buffer[64];
+   int ret;
 
if (!mpol || mpol->mode == MPOL_DEFAULT)
-   return; /* show nothing */
+   return 0;   /* show nothing */
 
-   mpol_to_str(buffer, sizeof(buffer), mpol);
+   ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+   if (ret < 0)
+   return ret;
 
seq_printf(seq, ",mpol=%s", buffer);
+   return 0;
 }
 
 static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
@@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
 }
 #else /* !CONFIG_NUMA */
 #ifdef CONFIG_TMPFS
-static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy 
*mpol)
-{
-}
+static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy 
*mpol) { return 0; }
 #endif /* CONFIG_TMPFS */
 
 static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
@@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u",
from_kgid_munged(_user_ns, sbinfo->gid));
-   shmem_show_mpol(seq, sbinfo->mpol);
-   return 0;
+   return shmem_show_mpol(seq, sbinfo->mpol);
 }
 #endif /* CONFIG_TMPFS */
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 warning after merge of the tip tree

[Ingo Molnar]

* Andi Kleen  wrote:

> > > Introduced by commit 9a55fdbe941e ("x86, asmlinkage, paravirt: Add
> > > __visible/asmlinkage to xen paravirt ops").  The 2 definitions used to be
> > > identical ... maybe there should be only one.
> > 
> > Andi, please send a fix for this build warning, against 
> > tip:x86/asmlinkage.
> 
> I resent the patch. Thanks for the headsup.

I suspect hpa missed it because the patch was opaque and 
non-descriptive: the title talks about a 'warning' that is 
supposedly fixed but the changelog does not explain what 
warning it is and why the change matters.

Please use the customary changelog style we use in the 
kernel:

  " Current code does (A), this has a problem when (B).
We can improve this doing (C), because (D)."

I've seen this pattern of deficient changelogs a dozen 
times in your patches this year alone ...

Thanks,

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

[PATCH 5/5] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

To iterate over all policies we currently iterate over all CPUs and
then get the policy for each of them.  Let's use the newly created
cpufreq_policy_list for this purpose.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0586bd2..81ceea6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -961,8 +961,8 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
struct cpufreq_policy *policy;
unsigned long flags;
 #ifdef CONFIG_HOTPLUG_CPU
+   struct cpufreq_policy *tpolicy;
struct cpufreq_governor *gov;
-   int sibling;
 #endif
 
if (cpu_is_offline(cpu))
@@ -985,11 +985,10 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
 #ifdef CONFIG_HOTPLUG_CPU
/* Check if this cpu was hot-unplugged earlier and has siblings */
read_lock_irqsave(_driver_lock, flags);
-   for_each_online_cpu(sibling) {
-   struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
-   if (cp && cpumask_test_cpu(cpu, cp->related_cpus)) {
+   list_for_each_entry(tpolicy, _policy_list, policy_list) {
+   if (cpumask_test_cpu(cpu, tpolicy->related_cpus)) {
read_unlock_irqrestore(_driver_lock, flags);
-   ret = cpufreq_add_policy_cpu(cp, cpu, dev, frozen);
+   ret = cpufreq_add_policy_cpu(tpolicy, cpu, dev, frozen);
up_read(_rwsem);
return ret;
}
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 4/5] cpufreq: remove cpufreq_policy_cpu per-cpu variable

[Viresh Kumar]

cpufreq_policy_cpu per-cpu variables are used for storing cpu that manages a cpu
or its policy->cpu. We are also storing policy for each cpu in cpufreq_cpu_data
and so this information is just redundant.

Better use cpufreq_cpu_data to retrieve policy and get policy->cpu from there.
And so this patch removes cpufreq_policy_cpu per-cpu variable.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 45 ++---
 1 file changed, 10 insertions(+), 35 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b03a851..0586bd2 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -64,15 +64,14 @@ static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], 
cpufreq_cpu_governor);
  * - Lock should not be held across
  * __cpufreq_governor(data, CPUFREQ_GOV_STOP);
  */
-static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
 static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
 
 #define lock_policy_rwsem(mode, cpu)   \
 static int lock_policy_rwsem_##mode(int cpu)   \
 {  \
-   int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);  \
-   BUG_ON(policy_cpu == -1);   \
-   down_##mode(_cpu(cpu_policy_rwsem, policy_cpu));\
+   struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
+   BUG_ON(!policy);\
+   down_##mode(_cpu(cpu_policy_rwsem, policy->cpu));   \
\
return 0;   \
 }
@@ -83,9 +82,9 @@ lock_policy_rwsem(write, cpu);
 #define unlock_policy_rwsem(mode, cpu) \
 static void unlock_policy_rwsem_##mode(int cpu)
\
 {  \
-   int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);  \
-   BUG_ON(policy_cpu == -1);   \
-   up_##mode(_cpu(cpu_policy_rwsem, policy_cpu));  \
+   struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
+   BUG_ON(!policy);\
+   up_##mode(_cpu(cpu_policy_rwsem, policy->cpu)); \
 }
 
 unlock_policy_rwsem(read, cpu);
@@ -887,7 +886,6 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy 
*policy,
write_lock_irqsave(_driver_lock, flags);
 
cpumask_set_cpu(cpu, policy->cpus);
-   per_cpu(cpufreq_policy_cpu, cpu) = policy->cpu;
per_cpu(cpufreq_cpu_data, cpu) = policy;
write_unlock_irqrestore(_driver_lock, flags);
 
@@ -1013,9 +1011,6 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
cpumask_copy(policy->cpus, cpumask_of(cpu));
 
-   /* Initially set CPU itself as the policy_cpu */
-   per_cpu(cpufreq_policy_cpu, cpu) = cpu;
-
init_completion(>kobj_unregister);
INIT_WORK(>update, handle_update);
 
@@ -1053,10 +1048,8 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
 #endif
 
write_lock_irqsave(_driver_lock, flags);
-   for_each_cpu(j, policy->cpus) {
+   for_each_cpu(j, policy->cpus)
per_cpu(cpufreq_cpu_data, j) = policy;
-   per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
-   }
write_unlock_irqrestore(_driver_lock, flags);
 
if (!frozen) {
@@ -1080,15 +1073,11 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
 
 err_out_unregister:
write_lock_irqsave(_driver_lock, flags);
-   for_each_cpu(j, policy->cpus) {
+   for_each_cpu(j, policy->cpus)
per_cpu(cpufreq_cpu_data, j) = NULL;
-   if (j != cpu)
-   per_cpu(cpufreq_policy_cpu, j) = -1;
-   }
write_unlock_irqrestore(_driver_lock, flags);
 
 err_set_policy_cpu:
-   per_cpu(cpufreq_policy_cpu, cpu) = -1;
cpufreq_policy_free(policy);
 nomem_out:
up_read(_rwsem);
@@ -1112,14 +1101,9 @@ static int cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif)
 
 static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
 {
-   int j;
-
policy->last_cpu = policy->cpu;
policy->cpu = cpu;
 
-   for_each_cpu(j, policy->cpus)
-   per_cpu(cpufreq_policy_cpu, j) = cpu;
-
 #ifdef CONFIG_CPU_FREQ_TABLE
cpufreq_frequency_table_update_policy_cpu(policy);
 #endif
@@ -1131,7 +1115,6 @@ static int cpufreq_nominate_new_policy_cpu(struct 
cpufreq_policy *policy,
   unsigned int old_cpu, bool frozen)
 {
struct device 

[PATCH 3/5] cpufreq: remove unnecessary check in __cpufreq_governor()

[Viresh Kumar]

We don't need to check if event is CPUFREQ_GOV_POLICY_INIT and put governor
module as we are sure event can only be START/STOP here.

And so remove this useless check.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0302121..b03a851 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1719,8 +1719,6 @@ static int __cpufreq_governor(struct cpufreq_policy 
*policy,
if ((!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
(policy->governor_enabled && (event == CPUFREQ_GOV_START))) {
mutex_unlock(_governor_lock);
-   if (event == CPUFREQ_GOV_POLICY_INIT)
-   module_put(policy->governor->owner);
return -EBUSY;
}
 
-- 
1.7.12.rc2.18.g61b472e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: remove policy from cpufreq_policy_list in system suspend

[Viresh Kumar]

cpufreq_policy_list is a list of active policies. We do remove policies from
this list when all CPUs belonging to that policy are removed. But during suspend
we don't really free a policy struct as it will be used again during resume. And
so we didn't remove it from cpufreq_policy_list as well..

This is incorrect. We are saying this policy isn't valid anymore and must not be
referenced (though we haven't freed it), but it can still be used by code that
iterates over cpufreq_policy_list.

Lets remove policy from this list even in case of suspend as well.. Similarly we
must add it back whenever the first cpu belonging to that policy turns up.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fedc842..0302121 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -950,12 +950,6 @@ err_free_policy:
 
 static void cpufreq_policy_free(struct cpufreq_policy *policy)
 {
-   unsigned long flags;
-
-   write_lock_irqsave(_driver_lock, flags);
-   list_del(>policy_list);
-   write_unlock_irqrestore(_driver_lock, flags);
-
free_cpumask_var(policy->related_cpus);
free_cpumask_var(policy->cpus);
kfree(policy);
@@ -1069,12 +1063,12 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
ret = cpufreq_add_dev_interface(policy, dev);
if (ret)
goto err_out_unregister;
-
-   write_lock_irqsave(_driver_lock, flags);
-   list_add(>policy_list, _policy_list);
-   write_unlock_irqrestore(_driver_lock, flags);
}
 
+   write_lock_irqsave(_driver_lock, flags);
+   list_add(>policy_list, _policy_list);
+   write_unlock_irqrestore(_driver_lock, flags);
+
cpufreq_init_policy(policy);
 
kobject_uevent(>kobj, KOBJ_ADD);
@@ -1280,6 +1274,11 @@ static int __cpufreq_remove_dev(struct device *dev,
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
 
+   /* Remove policy from list of active policies */
+   write_lock_irqsave(_driver_lock, flags);
+   list_del(>policy_list);
+   write_unlock_irqrestore(_driver_lock, flags);
+
if (!frozen)
cpufreq_policy_free(policy);
} else {
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 1/5] cpufreq: align closing brace '}' of an if block

[Viresh Kumar]

Following patch caused this:

commit 3de9bdeb28638e164d1f0eb38dd68e3f5d2ac95c
Author: Viresh Kumar 
Date:   Tue Aug 6 22:53:13 2013 +0530

cpufreq: improve error checking on return values of __cpufreq_governor()

Lets fix it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index c0ef84d..fedc842 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1253,7 +1253,7 @@ static int __cpufreq_remove_dev(struct device *dev,
__func__);
return ret;
}
-   }
+   }
 
if (!frozen) {
lock_policy_rwsem_read(cpu);
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 0/5] cpufreq: Fixes for 3.12

[Viresh Kumar]

Hi Rafael,

You recently did this:

commit 878f6e074e9a7784a6e351512eace4ccb3542eef
Author: Rafael J. Wysocki 
Date:   Sun Aug 18 15:35:59 2013 +0200

Revert "cpufreq: Use cpufreq_policy_list for iterating over policies"

Revert commit eb60852 (cpufreq: Use cpufreq_policy_list for iterating
over policies), because it breaks system suspend/resume on multiple
machines.

It either causes resume to block indefinitely or causes the BUG_ON()
in lock_policy_rwsem_##mode() to trigger on sysfs accesses to cpufreq
attributes.

--xx---

This patchset gets the reverted patch back along with few supporting patches.
Cause of the initial problem you observed was this:

- At suspend all CPUs are removed leaving boot cpu. At this time policies aren't
  freed and also aren't removed from cpufreq_policy_list. And per-cpu variable
  cpufreq_cpu_data is marked as NULL.
- At resume CPUs other than boot cpu called __cpufreq_add_dev(). The tricky
  change that was introduced by my patch was: We iterate over list of policies
  instead of CPUs, where we used to get policy structure associated with
  CPUs using per-cpu variable. Which used to be NULL for first CPU of a policy
  that turned up. For the first cpu we don't want to call
  cpufreq_add_policy_cpu() but want __cpufreq_add_add() to continue.

  When we called cpufreq_add_policy_cpu() it tried to stop the governor (which
  was already stopped) and hence errors leading into unstable state.

This patchset fixes these issues and is tested with suspend-resume over my
thinkpad with ubuntu. Apart from minor cleanups it removes policy from
cpufreq_policy_list in case of suspend/resume as well and hence we will never
call cpufreq_add_policy_cpu() for first cpu of a policy.

--
viresh

Viresh Kumar (5):
  cpufreq: align closing brace '}' of an if block
  cpufreq: remove policy from cpufreq_policy_list in system suspend
  cpufreq: remove unnecessary check in __cpufreq_governor()
  cpufreq: remove cpufreq_policy_cpu per-cpu variable
  cpufreq: Use cpufreq_policy_list for iterating over policies

 drivers/cpufreq/cpufreq.c | 77 +++
 1 file changed, 24 insertions(+), 53 deletions(-)

-- 
1.7.12.rc2.18.g61b472e

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

Re: [PATCH V2 07/11] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

On 19 August 2013 16:57, Viresh Kumar  wrote:
> It wasn't my patch actually.. It only made it visible that's it :)
> The problem is:
> - On suspend all CPUs are removed and so governors are
> stopped.
> - On resume, handle_update() is called for the boot cpu and
> cpu_add_dev for all others.
>
> handle_update() doesn't start governor but only plays with
> CPUFREQ_GOV_LIMITS.. when we start adding other
> CPUs and call: cpufreq_add_policy_cpu() which fails in
> following call:
>
> __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>
> and so cpufreq_policy_cpu never gets initialized to
> policy->cpu and stays at -1, and hence the crash.
>
> So, there are few problems with core at this point:
> - I don't understand how does the work done in
> cpufreq_add_dev() gets done for boot cpu during
> resume ? And so how does Srivatsa's "frozen" solution
> really works (I haven't had time to investigate, its not
> that I couldn't understand it :) )..
>
> - We need to start governor boot cpu in handle_update()
> and things would be solved...

Whatever I wrote here was simply _Bullshit_ :(

I am about to send you a fixup patchset that fixes this issue, and
yes it was my patch which introduced this problem :(, but
because of some mishandling of cpufreq_policy_list :)

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

Re: [PATCH V2 07/11] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

On 20 August 2013 04:52, Rafael J. Wysocki  wrote:
> From my experience, however, it is good to figure out what needs to be 
> included
> into your test kernel and configure away everything else.  Also, I'd recommend
> to build as much as possible into the kernel image and avoid compiling too 
> many
> modules, because installing modules takes time too (ideally, if you can get
> away without any modules at all, that's the best option timing-wise).  Just
> select only the drivers that you're going to use and unset all of the options
> that don't apply to your test machine.

I haven't done this exercise yet but I have a workable solution with default
.config as suggested by 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: [PATCH V2 07/11] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

On 19 August 2013 17:15, Amit Kucheria  wrote:
> Why do you create .deb packages to test development kernels? It _is_ slow.
>
> Instead I'd just add a new grub menu entry to /boot/grub/grub.cfg and
> point it to /boot/MyzImage. After a 'make install; make
> modules_install' just link /boot/MyzImage to the installed kernel in
> /boot. And then generate a new initramfs using 'update-initramfs -c -k
> '

initramfs was fixed automatically for me with make install.. Thanks it saved
lots of my time :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAX7301 GPIO: Reverting "Do not force SPI speed when using OF Platform"

[Christophe Leroy]

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

Signed-off-by: Christophe Leroy 

--- linux-3.11-rc6/drivers/gpio/gpio-max7301.c  2013-08-17 21:09:17.0 
+0200
+++ linux/drivers/gpio/gpio-max7301.c   2013-08-18 06:31:52.0 +0200
@@ -56,8 +56,7 @@
int ret;
 
/* bits_per_word cannot be configured in platform data */
-   if (spi->dev.platform_data)
-   spi->bits_per_word = 16;
+   spi->bits_per_word = 16;
ret = spi_setup(spi);
if (ret < 0)
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/

Re: [PATCH 1/2] ARC: gdbserver breakage in Big-Endian configuration #1

[greg Kroah-Hartman]

On Tue, Aug 20, 2013 at 10:50:40AM +0530, Vineet Gupta wrote:
> Hi Greg,
> 
> On 08/19/2013 08:27 PM, greg Kroah-Hartman wrote:
> > On Mon, Aug 19, 2013 at 09:08:49AM +, Vineet Gupta wrote:
> >> Hi Greg,
> >>
> >> I'd posted these patches for stable backport. Do I need to do anything 
> >> more to get them included.
> >>
> >> https://patchwork.kernel.org/patch/2841153/  [1/2] ARC: gdbserver breakage 
> >> in Big-Endian configuration 
> >> #1]
> >> https://patchwork.kernel.org/patch/2841158/  [2/2] ARC: gdbserver breakage 
> >> in Big-Endian configuration #2
> > 
> > I ignored them as I thought you were submitting them for upstream
> > inclusion.  If they are already in Linus's tree, then take a look at the
> > file, Documentation/stable_kernel_rules.txt for how to send a patch for
> > inclusion into a stable release (hint, I need to know the git commit id
> > that the patch has in Linus's tree, which I didn't see anywhere here.)
> 
> 
> I'm sure I mentioned the commit-id in the patch. Hint, please look at 
> annotation
> within --->8--- blocks in changelogs.

You're right, I missed that, sorry.

> The caveat however is we can't apply those exact commits as it is as that 
> warrants
> more changes to be pulled in. However I'm going by the last stable kernel 
> rule "It
> or an equivalent fix must already exist in Linus' tree (upstream)."
> 
> Anyhow, since both these patches are extracted from same commit, I'll respin a
> single patch (with a small addition - again part of the same commit) and send 
> it
> over. OK !

That would be great, thanks.

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

Re: [PATCH] proc: return on proc_readdir error

[Richard Genoud]

2013/8/20 Marc Dionne :
> On Mon, Aug 19, 2013 at 7:49 PM, Linus Torvalds
>  wrote:
>> On Mon, Aug 19, 2013 at 1:33 PM, Marc Dionne  wrote:
>>>
>>> By my reading that commit (f0c3b5093add) also made proc_readdir always
>>> return 0, so with this patch the effect I see is that no pid entries
>>> are listed under /proc, breaking ps for instance.  I don't see how
>>> even the previous version of proc_readdir could return a negative
>>> value; looks like 1 and 0 were the only possible return values.
>>
>> Yes, see the other thread. The "return 1" case had gotten lost. I
>> think current git should get everything right, but please do test. I
>> did some testing of my own with a random little getdents test-program
>> (just checking that it got the same results with different (small)
>> buffer sizes), but it was by no means exhaustive.
>>
>>   Linus
>
> It does fix the symptoms I was seeing, thanks.  "ps" now has output
> and the pid entries are now visible again under /proc.
>
> Marc
arg !
I was so focused on getting the non-PID proc entries right that I
didn't even see all the missing PIDs when I tested it !

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

Re: [PATCHv3 3/4] clk: sunxi: Add A31 clocks support

[Maxime Ripard]

Hi Emilio,

On Mon, Aug 19, 2013 at 05:14:57PM -0300, Emilio López wrote:
> El 05/08/13 17:43, Maxime Ripard escribió:
> >The A31 has a mostly different clock set compared to the other older
> >SoCs currently supported in the Allwinner clock driver.
> >
> >Add support for the basic useful clocks. The other ones will come in
> >eventually.
> >
> >Signed-off-by: Maxime Ripard 
> 
> I had another quick look at it and overall it looks good to go,
> 
> Reviewed-by: Emilio López 

Thanks!

> >---
> >  Documentation/devicetree/bindings/clock/sunxi.txt  |   6 +
> >  .../bindings/clock/sunxi/sun6i-a31-gates.txt   |  83 ++
> >  drivers/clk/sunxi/clk-sunxi.c  | 124 
> > +
> >  3 files changed, 213 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
> >
> >diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
> >b/Documentation/devicetree/bindings/clock/sunxi.txt
> >index b24de10..c383d12 100644
> >--- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >@@ -8,6 +8,7 @@ Required properties:
> >  - compatible : shall be one of the following:
> > "allwinner,sun4i-osc-clk" - for a gatable oscillator
> > "allwinner,sun4i-pll1-clk" - for the main PLL clock
> >+"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
> > "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
> > "allwinner,sun4i-axi-clk" - for the AXI clock
> > "allwinner,sun4i-axi-gates-clk" - for the AXI gates
> >@@ -15,6 +16,8 @@ Required properties:
> > "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
> > "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
> > "allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
> >+"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
> >+"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
> > "allwinner,sun4i-apb0-clk" - for the APB0 clock
> > "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
> > "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
> >@@ -24,6 +27,9 @@ Required properties:
> > "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
> > "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
> > "allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
> >+"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
> >+"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
> >+"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> >
> >  Required properties for all clocks:
> >  - reg : shall be the control register address for the clock.
> >diff --git 
> >a/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt 
> >b/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
> >new file mode 100644
> >index 000..fe44932
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
> >@@ -0,0 +1,83 @@
> >+Gate clock outputs
> >+--
> >+
> >+  * AHB1 gates ("allwinner,sun6i-a31-ahb1-gates-clk")
> >+
> >+MIPI DSI1
> >+
> >+SS  5
> >+DMA 6
> >+
> >+MMC08
> >+MMC19
> >+MMC210
> >+MMC311
> >+
> >+NAND1   12
> >+NAND0   13
> >+SDRAM   14
> >+
> >+GMAC17
> >+TS  18
> >+HSTIMER 19
> >+SPI020
> >+SPI121
> >+SPI222
> >+SPI323
> >+USB_OTG 24
> >+
> >+EHCI0   26
> >+EHCI1   27
> >+
> >+OHCI0   29
> >+OHCI1   30
> >+OHCI2   31
> >+VE  32
> >+
> >+LCD036
> >+LCD137
> >+
> >+CSI 40
> >+
> >+HDMI43
> >+DE_BE0  44
> >+DE_BE1  45
> >+DE_FE1  46
> >+DE_FE1  47
> >+
> >+MP 

[PATCH v3 5/6] mfd:rtsx: Configure to enter a deeper power-saving mode in S3

[wei_wang]

From: Wei WANG 

Set a bit to enable rts5227 and rts5249 to enter a deeper internal
power-saving mode in S3, and recover it after resuming.

Signed-off-by: Wei WANG 
---
 drivers/mfd/rtl8411.c|2 +-
 drivers/mfd/rts5209.c|2 +-
 drivers/mfd/rts5227.c|6 +-
 drivers/mfd/rts5229.c|2 +-
 drivers/mfd/rts5249.c|6 +-
 drivers/mfd/rtsx_pcr.c   |2 +-
 include/linux/mfd/rtsx_pci.h |2 +-
 7 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index d183fa0..37367fb 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -86,7 +86,7 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtl8411b_reg_to_sd30_drive_sel_3v3(reg));
 }
 
-static void rtl8411_force_power_down(struct rtsx_pcr *pcr)
+static void rtl8411_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
 }
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 03a15f7..ef6a59f 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -59,7 +59,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
}
 }
 
-static void rts5209_force_power_down(struct rtsx_pcr *pcr)
+static void rts5209_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
 }
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 724ce4c5..c72abd6 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -83,13 +83,16 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->flags |= PCR_REVERSE_SOCKET;
 }
 
-static void rts5227_force_power_down(struct rtsx_pcr *pcr)
+static void rts5227_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
 
+   if (pm_state == HOST_ENTER_S3)
+   rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
 
@@ -123,6 +126,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
AUTOLOAD_CFG_BASE + 3, 0xB8, 0x88);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index e8261d7..afb0f24 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -56,7 +56,7 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtsx_reg_to_sd30_drive_sel_3v3(reg));
 }
 
-static void rts5229_force_power_down(struct rtsx_pcr *pcr)
+static void rts5229_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index c5e54d7..384b30b 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -88,13 +88,16 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->flags |= PCR_REVERSE_SOCKET;
 }
 
-static void rts5249_force_power_down(struct rtsx_pcr *pcr)
+static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
 
+   if (pm_state == HOST_ENTER_S3)
+   rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
 
@@ -119,6 +122,7 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
AUTOLOAD_CFG_BASE + 3, 0xB0, 0x80);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index ffd393c..29932a0 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -939,7 +939,7 @@ static void rtsx_pci_power_off(struct rtsx_pcr *pcr, u8 
pm_state)
rtsx_pci_write_register(pcr, HOST_SLEEP_STATE, 0x03, pm_state);
 
if (pcr->ops->force_power_down)
-   pcr->ops->force_power_down(pcr);
+   pcr->ops->force_power_down(pcr, pm_state);
 }
 
 static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 9a16276..dd0bd58 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -779,7 +779,7 @@ struct 

[PATCH v3 0/6] MFD patches for Realtek cardreader

[wei_wang]

From: Wei WANG 

v3:
Seperate copyright changes to a distinct patch
Modify some coding style and naming style
Fix a bug that sd30_drive_sel would be assigned a wrong value, in rts5227 and 
rts5249

v2:
Use macro when initializing vendor settings

Wei WANG (6):
  mfd:rtsx: Read vendor setting from config space
  mfd:rtsx: Add shutdown callback in rtsx_pci_driver
  mfd:rtsx: Move some actions from rtsx_pci_init_hw to individual
extra_init_hw
  mfd:rtsx: Clear hardware PFM mode in rtl8411b
  mfd:rtsx: Configure to enter a deeper power-saving mode in S3
  mfd:rtsx: Modify copyright comments

 drivers/mfd/rtl8411.c   |   90 ---
 drivers/mfd/rts5209.c   |   61 +++--
 drivers/mfd/rts5227.c   |  113 ++-
 drivers/mfd/rts5229.c   |   51 --
 drivers/mfd/rts5249.c   |  108 +
 drivers/mfd/rtsx_pcr.c  |   76 +++---
 drivers/mfd/rtsx_pcr.h  |   32 ++-
 include/linux/mfd/rtsx_common.h |3 +-
 include/linux/mfd/rtsx_pci.h|   51 --
 9 files changed, 482 insertions(+), 103 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/

[PATCH v3 4/6] mfd:rtsx: Clear hardware PFM mode in rtl8411b

[wei_wang]

From: Wei WANG 

Clear hw_pfm_en to disable hardware PFM mode, to fix a bug that in some
situation registers in 0xFDxx domain can't be accessed.

Signed-off-by: Wei WANG 
---
 drivers/mfd/rtl8411.c|2 ++
 include/linux/mfd/rtsx_pci.h |1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 56cc248..d183fa0 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -114,6 +114,8 @@ static int rtl8411b_extra_init_hw(struct rtsx_pcr *pcr)
0xFF, pcr->sd30_drive_sel_3v3);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CD_PAD_CTL,
CD_DISABLE_MASK | CD_AUTO_DISABLE, CD_ENABLE);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, FUNC_FORCE_CTL,
+   0x06, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 11ab786..9a16276 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -687,6 +687,7 @@
 #define PME_FORCE_CTL  0xFE56
 #define ASPM_FORCE_CTL 0xFE57
 #define PM_CLK_FORCE_CTL   0xFE58
+#define FUNC_FORCE_CTL 0xFE59
 #define PERST_GLITCH_WIDTH 0xFE5C
 #define CHANGE_LINK_STATE  0xFE5B
 #define RESET_LOAD_REG 0xFE5E
-- 
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/

[PATCH v3 3/6] mfd:rtsx: Move some actions from rtsx_pci_init_hw to individual extra_init_hw

[wei_wang]

From: Wei WANG 

These actions are individual for each reader model, so should be put in
extra_init_hw instead of rtsx_pci_init_hw.

Signed-off-by: Wei WANG 
---
 drivers/mfd/rts5209.c  |4 
 drivers/mfd/rts5227.c  |2 ++
 drivers/mfd/rts5229.c  |4 
 drivers/mfd/rts5249.c  |2 ++
 drivers/mfd/rtsx_pcr.c |4 
 5 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index c67935e..03a15f7 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -70,6 +70,10 @@ static int rts5209_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Turn off LED */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_GPIO, 0xFF, 0x03);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
+   /* Force CLKREQ# PIN to drive 0 to request clock */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x08, 0x08);
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_GPIO_DIR, 0xFF, 0x03);
/* Configure driving */
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 42ebf5c..724ce4c5 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -101,6 +101,8 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
/* Switch LDO3318 source from DV33 to card_3v3 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index a0b695a..e8261d7 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -67,6 +67,10 @@ static int rts5229_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
+   /* Force CLKREQ# PIN to drive 0 to request clock */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x08, 0x08);
/* Switch LDO3318 source from DV33 to card_3v3 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 79ff212..c5e54d7 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -104,6 +104,8 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
/* Switch LDO3318 source from DV33 to card_3v3 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 97526f1..ffd393c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -972,8 +972,6 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, HOST_SLEEP_STATE, 0x03, 0x00);
/* Disable card clock */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_CLK_EN, 0x1E, 0);
-   /* Reset ASPM state to default value */
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
/* Reset delink mode */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CHANGE_LINK_STATE, 0x0A, 0);
/* Card driving select */
@@ -1003,8 +1001,6 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
 *  0: ELBI interrupt flag[31:22] & [7:0] only can be write clear
 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, NFTS_TX_CTRL, 0x02, 0);
-   /* Force CLKREQ# PIN to drive 0 to request clock */
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x08, 0x08);
 
err = rtsx_pci_send_cmd(pcr, 100);
if (err < 0)
-- 
1.7.9.5

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

Re: [PATCH][RFC] Tests on 200 different CPUs/Arches and OSes with CPU Jitter RNG

[Stephan Mueller]

Am Sonntag, 18. August 2013, 20:05:52 schrieb Stephan Mueller:

Hi Ted, Sandy,

For FIPS 140-2, there is currently a draft of an Implementation Guidance 
discussed covering the requirements of seed sources for deterministic 
random number generators. The standard seed source when having no 
hardware RNGs is either /dev/urandom or /dev/random. Please note that 
the current discussion explicitly prohibits the use of /dev/urandom for 
FIPS 140-2 compliant systems.

In addition, the recommendation of SP800-90B is available in draft form 
at [1] placing quite severe requirements on seed sources. After 
assessing the above mentioned IG discussion and in discussions with the 
German BSI, these governmental folks seem to interpret the concept of 
entropy as solely information theoretical entropy. They seem to 
disregard cryptographic strength added by a whitening function. 
Therefore, my gut feeling is that /dev/urandom is also questioned by 
SP800-90B -- but I have no proof at this point.

That focus on information theoretical entropy ultimately implies that 
only /dev/random can be used and /dev/urandom must not be used. 
Naturally, many people are not happy with that due to the blocking 
behavior. Especially in a headless environment like server systems, 
Linux is currently starved of entropy. This is even more a problem with 
virtualized environments. For example, some time ago we tried to obtain 
48 bytes out of /dev/random on a PPC system after the entropy pools 
where completely drained. Well, we got it after some 20 hours as the 
system was quiet (it may now be a bit better with the interrupt usage in 
current kernels, but still there will be a noticeable block).

Now, people will scream: those governmental guys sell snake oil and we 
should still use /dev/urandom. And I have to concur. Yet, I am just 
delivering the message. With the German BSI, the last discussion showed 
that they are open to allowing /dev/urandom based on extensive 
discussions. Yet, you have to make quite a stance to prove that.

>- addition of a patch to integrate the RNG into /dev/random as
>explained in appendix B.3 of [2], although the long-term goal of the
>RNG is rather the integration into the kernel crypto API when
>considering the Linux kernel as outlined in appendix B.1 of [2]

All in all, with the suggested CPU Jitter RNG, all of this would be an 
issue of the past on systems the init function considers appropriate -- 
in my tests more than 95% of all systems are accepted. When using my 
patch on /dev/random, dd shows a throughput of about 6kb/s on my system 
when pulling out megabytes of data. It will be slower on slower systems, 
but yet it will not block. Moreover when pulling data for seed which is 
only a few bytes at a time, the invocation of /dev/random will not show 
any noticeable delay.

PS: As I mentioned earlier, however, my long term goal would be that 
callers would disregard /dev/random entirely as it is a central entropy 
source and therefore the prime spot for attacks to reduce entropy. With 
the jitter RNG, even unprivileged user space can have its own instance 
of a seed source.


[1] http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-B


Ciao
Stephan
-- 
| Cui bono? |

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

Re: [PATCH net-next v4] net: cpsw: Add support for wake-on-lan for cpsw

[Mugunthan V N]

On Tuesday 20 August 2013 11:29 AM, ujhely...@gmail.com wrote:
> From: Matus Ujhelyi 
>
> Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 
> 88E1318S).
> There is no way how to enable wol on CPSW with such connected phys. This patch
> adds this support. It is provided by calling the phy's related code.
>
> Tested on board with at8030x connected phy. Wol interrupt line is
> connected to GPIO0 on am335x.
>
> Signed-off-by: Matus Ujhelyi 
> ---
Looks good to me.

Acked-by: Mugunthan V N 

Also feel free to add my ack in case if you are submitting one more version.

Regards
Mugunthan V 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/

[PATCH v3 2/6] mfd:rtsx: Add shutdown callback in rtsx_pci_driver

[wei_wang]

From: Wei WANG 

Some actions to clear power state should be handled in .shutdown
callback in rtsx_pci_driver. This patch adopts the following measures to
catch this goal:
1. Add a function rtsx_pci_power_off to abstract the common ops in
.shutdown and .suspend
2. Add pcr->ops->force_power_down to fulfill the individual action for
each reader model

Signed-off-by: Wei WANG 
---
 drivers/mfd/rtl8411.c|7 +++
 drivers/mfd/rts5209.c|6 ++
 drivers/mfd/rts5227.c|   11 +++
 drivers/mfd/rts5229.c|6 ++
 drivers/mfd/rts5249.c|   11 +++
 drivers/mfd/rtsx_pcr.c   |   43 --
 include/linux/mfd/rtsx_pci.h |   13 +++--
 7 files changed, 85 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 5a68c9b..56cc248 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -86,6 +86,11 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtl8411b_reg_to_sd30_drive_sel_3v3(reg));
 }
 
+static void rtl8411_force_power_down(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
+}
+
 static int rtl8411_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
@@ -285,6 +290,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
.conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
+   .force_power_down = rtl8411_force_power_down,
 };
 
 static const struct pcr_ops rtl8411b_pcr_ops = {
@@ -300,6 +306,7 @@ static const struct pcr_ops rtl8411b_pcr_ops = {
.switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
.conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
+   .force_power_down = rtl8411_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 2170449..c67935e 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -59,6 +59,11 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
}
 }
 
+static void rts5209_force_power_down(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
+}
+
 static int rts5209_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
@@ -197,6 +202,7 @@ static const struct pcr_ops rts5209_pcr_ops = {
.switch_output_voltage = rts5209_switch_output_voltage,
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
+   .force_power_down = rts5209_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index c3181d7..42ebf5c 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -83,6 +83,16 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->flags |= PCR_REVERSE_SOCKET;
 }
 
+static void rts5227_force_power_down(struct rtsx_pcr *pcr)
+{
+   /* Set relink_time to 0 */
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
+
+   rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
+}
+
 static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
 {
u16 cap;
@@ -218,6 +228,7 @@ static const struct pcr_ops rts5227_pcr_ops = {
.switch_output_voltage = rts5227_switch_output_voltage,
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
+   .force_power_down = rts5227_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 7a1ad6d..a0b695a 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -56,6 +56,11 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtsx_reg_to_sd30_drive_sel_3v3(reg));
 }
 
+static void rts5229_force_power_down(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
+}
+
 static int rts5229_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
@@ -179,6 +184,7 @@ static const struct pcr_ops rts5229_pcr_ops = {
.switch_output_voltage = rts5229_switch_output_voltage,
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
+   .force_power_down = rts5229_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index d5db182..79ff212 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -88,6 +88,16 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr->flags |= PCR_REVERSE_SOCKET;
 }
 
+static void rts5249_force_power_down(struct rtsx_pcr *pcr)
+{
+   /* Set relink_time to 0 */
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 

[PATCH v3 6/6] mfd:rtsx: Modify copyright comments

[wei_wang]

From: Wei WANG 

Update copyright date, and remove author address.

Signed-off-by: Wei WANG 
---
 drivers/mfd/rtl8411.c   |4 ++--
 drivers/mfd/rts5209.c   |3 +--
 drivers/mfd/rts5227.c   |5 +
 drivers/mfd/rts5229.c   |3 +--
 drivers/mfd/rts5249.c   |1 -
 drivers/mfd/rtsx_pcr.c  |3 +--
 drivers/mfd/rtsx_pcr.h  |3 +--
 include/linux/mfd/rtsx_common.h |3 +--
 include/linux/mfd/rtsx_pci.h|3 +--
 9 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 37367fb..e4c1833 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,7 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
+ *   Roger Tseng 
  */
 
 #include 
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index ef6a59f..4026e1f 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include 
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index c72abd6..d7cae82 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,10 +17,7 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
- *
  *   Roger Tseng 
- *   No. 2, Innovation Road II, Hsinchu Science Park, Hsinchu 300, Taiwan
  */
 
 #include 
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index afb0f24..620e7fa 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include 
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 384b30b..ea90f8f 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 128, West Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include 
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 29932a0..e6ae772 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include 
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 7a1b87a..947e79b 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #ifndef __RTSX_PCR_H
diff --git a/include/linux/mfd/rtsx_common.h b/include/linux/mfd/rtsx_common.h
index 2b13970..443176e 100644
--- a/include/linux/mfd/rtsx_common.h
+++ 

[PATCH v3 1/6] mfd:rtsx: Read vendor setting from config space

[wei_wang]

From: Wei WANG 

Normally OEMs will set vendor setting to the config space of Realtek
card reader in BIOS stage. This patch reads the setting at the first,
and configure the internal registers according to it, to improve card
reader's compatibility condition.

Signed-off-by: Wei WANG 
---
 drivers/mfd/rtl8411.c|   77 ---
 drivers/mfd/rts5209.c|   48 +++---
 drivers/mfd/rts5227.c|   91 --
 drivers/mfd/rts5229.c|   38 --
 drivers/mfd/rts5249.c|   90 +++--
 drivers/mfd/rtsx_pcr.c   |   26 ++--
 drivers/mfd/rtsx_pcr.h   |   29 ++
 include/linux/mfd/rtsx_pci.h |   34 +++-
 8 files changed, 365 insertions(+), 68 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index c436bf2..5a68c9b 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -47,19 +47,70 @@ static int rtl8411b_is_qfn48(struct rtsx_pcr *pcr)
return 0;
 }
 
+static void rtl8411_fetch_vendor_settings(struct rtsx_pcr *pcr)
+{
+   u32 reg1;
+   u8 reg3;
+
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
+   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg1);
+
+   if (!rtsx_vendor_setting_valid(reg1))
+   return;
+
+   pcr->aspm_en = rtsx_reg_to_aspm(reg1);
+   pcr->sd30_drive_sel_1v8 =
+   map_sd_drive(rtsx_reg_to_sd30_drive_sel_1v8(reg1));
+   pcr->card_drive_sel &= 0x3F;
+   pcr->card_drive_sel |= rtsx_reg_to_card_drive_sel(reg1);
+
+   rtsx_pci_read_config_byte(pcr, PCR_SETTING_REG3, );
+   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG3, reg3);
+   pcr->sd30_drive_sel_3v3 = rtl8411_reg_to_sd30_drive_sel_3v3(reg3);
+}
+
+static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr *pcr)
+{
+   u32 reg;
+
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
+   dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+
+   if (!rtsx_vendor_setting_valid(reg))
+   return;
+
+   pcr->aspm_en = rtsx_reg_to_aspm(reg);
+   pcr->sd30_drive_sel_1v8 =
+   map_sd_drive(rtsx_reg_to_sd30_drive_sel_1v8(reg));
+   pcr->sd30_drive_sel_3v3 =
+   map_sd_drive(rtl8411b_reg_to_sd30_drive_sel_3v3(reg));
+}
+
 static int rtl8411_extra_init_hw(struct rtsx_pcr *pcr)
 {
-   return rtsx_pci_write_register(pcr, CD_PAD_CTL,
+   rtsx_pci_init_cmd(pcr);
+
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_DRIVE_SEL,
+   0xFF, pcr->sd30_drive_sel_3v3);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CD_PAD_CTL,
CD_DISABLE_MASK | CD_AUTO_DISABLE, CD_ENABLE);
+
+   return rtsx_pci_send_cmd(pcr, 100);
 }
 
 static int rtl8411b_extra_init_hw(struct rtsx_pcr *pcr)
 {
-   if (rtl8411b_is_qfn48(pcr))
-   rtsx_pci_write_register(pcr, CARD_PULL_CTL3, 0xFF, 0xF5);
+   rtsx_pci_init_cmd(pcr);
 
-   return rtsx_pci_write_register(pcr, CD_PAD_CTL,
+   if (rtl8411b_is_qfn48(pcr))
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   CARD_PULL_CTL3, 0xFF, 0xF5);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_DRIVE_SEL,
+   0xFF, pcr->sd30_drive_sel_3v3);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CD_PAD_CTL,
CD_DISABLE_MASK | CD_AUTO_DISABLE, CD_ENABLE);
+
+   return rtsx_pci_send_cmd(pcr, 100);
 }
 
 static int rtl8411_turn_on_led(struct rtsx_pcr *pcr)
@@ -141,13 +192,13 @@ static int rtl8411_switch_output_voltage(struct rtsx_pcr 
*pcr, u8 voltage)
mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_MASK;
if (voltage == OUTPUT_3V3) {
err = rtsx_pci_write_register(pcr,
-   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_D);
+   SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_3v3);
if (err < 0)
return err;
val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_3V3;
} else if (voltage == OUTPUT_1V8) {
err = rtsx_pci_write_register(pcr,
-   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
+   SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_1v8);
if (err < 0)
return err;
val = (BPP_ASIC_1V8 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_1V8;
@@ -222,6 +273,7 @@ static int rtl8411_conv_clk_and_div_n(int input, int dir)
 }
 
 static const struct pcr_ops rtl8411_pcr_ops = {
+   .fetch_vendor_settings = rtl8411_fetch_vendor_settings,
.extra_init_hw = rtl8411_extra_init_hw,
.optimize_phy = NULL,
.turn_on_led = rtl8411_turn_on_led,
@@ -236,6 +288,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
 };
 
 static const 

Re: [PATCH] ARM: at91/dt: split sam9x5 peripheral definitions

[b.brezillon]

Hello Mike,

On Mon, 19 Aug 2013 15:37:14 -0700, Mike Turquette
 wrote:
> Quoting Nicolas Ferre (2013-08-19 09:23:46)
>> On 08/08/2013 17:23, boris brezillon :
>> > Hello Jean-Christophe,
>> >
>> > On 08/08/2013 16:07, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> >> On 12:14 Wed 07 Aug , Boris BREZILLON wrote:
>> >>> This patch splits the sam9x5 peripheral definitions into:
>> >>> - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
>> >>> - several optional peripheral definitions which will be included by 
>> >>> specific
>> >>> sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
>> >>>
>> >>> This provides a better representation of the real hardware (drop unneeded
>> >>> dt nodes) and avoids future peripheral id conflict (lcdc and isi both use
>> >>> peripheral id 25).
>> >> I really don't like this
>> >>
>> >> the mapping is soc specific (here familly) so I does not see any advantage
>> >> except move files so NO for me
>> > Let me explain in detail why I did that.
>> >
>> > This separation was part of the "at91 common clk" series and was here to
>> > avoid the
>> > definition of unavailable clocks or definition of clocks with the same
>> > id (which may result
>> > in bad clk registration).
>> > If we keep all the definitions in one .dtsi file (even the one which are
>> > not really available),
>> > I may need to add a new property to each peripheral (and system) clk
>> > node to specify the
>> > availabilty of the clock (something similar to 'status="disabled"' in
>> > device nodes).
>>
>> This is indeed a pretty good argument.
>> I do think that we have to ask Mike Turquette to see if he already has
>> encountered such a case.
> 
> It is correct to place chip-specific clocks into a chip-specific dts.
> Having clocks marked as "disabled" in a big dtsi is not the right way to
> go.
> 

I agree. As I said earlier, I think unavailable peripherals (and
associated clocks)
should not be part of the dts definition because it may lead to
misinterpretation of
the real hardware parts.
There is a difference between unused IP block (defined with
status="disabled") because
external I/Os are not connected on a specific board and unavailable IP
block (IP block
not available on a given SoC).

This beeing said, I understand the readability concern, and I won't
force this split if
we find a way to declare a clk as "unavailable" or "disabled"  

> Regarding naming conflicts, is your issue with string name collisions
> during calls to __clk_lookup?
> 

No, there is no collision in clk names, because each optional clock has
a unique name.
But there may be conflicts on clk ids (peripheral ids):

LCDC (LCD Controller) and ISI (Image Sensor Interface) peripherals have
the same id (25)
in sam9x5 SoC family but are never both available in a given SoC.

If you declare LCDC clk before ISI clock, the former will always be
returned when you
reference the ISI clk in ISI peripheral node (clocks=< 25>).

This will work, as the method for enabling/disabling periph clk are the
same for all clks.
But when you print the clk tree (using debugfs) you will see lcdc_clk
with prepare/enable
count incremented and isi_clk always unused, even if the SoC does not
have an LCDC block.

Moreover, isi_clk will be allocated for nothing, because it cannot be
retrieved.

And what happens if an unavailable clock is referenced (I did not test
that, but I guess
the is_enabled callback will always return false)?
This case should not happen if the dts is correctly defined, but still,
I think unavailable
clocks should not be registered in the clk framework.

Please, feel free to share your thoughts.

Best Regards,

Boris

> Thanks,
> Mike
> 
>>
>> I must say that I was not in favor for this split because of readability
>> and dts/dtsi file organization (you know, the usual question: where the
>> hell this peripheral property is finally setup?).
>>
>> But, if we really have to implement a new kind of property to tell if a
>> clock is actually present or not, I am in favor for reconsidering this
>> solution as it seems quite simple and self-explanatory...
>>
>> > As explained to Thomas, I thought device tree was here to give a real
>> > description of the
>> > hardware parts (in case of sam9x5.dtsi the description of the common
>> > parts of sam9x5 SoC
>> > family).
>> > If you define peripherals that are not present in a SoC (lets say macb0
>> > for sam9g15) you break
>> > this rule.
>>
>> Well, on the other hand, the status says "disabled", so we can imagine
>> that it has been disabled, from its birth, in hardware...
>>
>> > I'm not telling I have the right approach here, I'm just trying to
>> > understand what should be done and
>> > what should not.
>> >
>> > Finally, I'd like to point that the memory footprint of the dtb file
>> > generated after this patch has been
>> > applied is bit smaller (even if it won't make a real difference):
>> >
>> > with this patch:
>> >
>> > 15937 arch/arm/boot/dts/at91-ariag25.dtb
>> > 15860 

Re: [PATCH V3 1/2] tps6507x-ts: Add DT support

[Prabhakar Lad]

Hi Manish,

Thanks for the patch.

On Tue, May 21, 2013 at 2:24 PM, Vishwanathrao Badarkhe, Manish
 wrote:
> Add device tree based support for TI's tps6507x touchscreen.
>
> Tested on da850-evm.
>
> Signed-off-by: Vishwanathrao Badarkhe, Manish 
> ---
> Changes since V2:
>  - Removed unnecessary code.
>  - Updated Documentation to provide proper names of
>devicetree properties.
>
> Changes since V1:
>  - Updated documentation to specify tps6507x as multifunctional
>device.
>  - return proper error value in absence of platform and DT
>data for touchscreen.
>  - Updated commit message.
>
> :100755 100755 8fffa3c... 65ee2cd... M  
> Documentation/devicetree/bindings/mfd/tps6507x.txt
> :100644 100644 65e0f9a... 89232ee... M  
> drivers/input/touchscreen/tps6507x-ts.c
>  Documentation/devicetree/bindings/mfd/tps6507x.txt |   28 ++-
>  drivers/input/touchscreen/tps6507x-ts.c|   98 
> ++--
>  2 files changed, 95 insertions(+), 31 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt 
> b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> index 8fffa3c..65ee2cd 100755
> --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
> +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> @@ -1,4 +1,8 @@
> -TPS6507x Power Management Integrated Circuit
> +TPS6507x Multifunctional Device.
> +
> +Features provided by TPS6507x:
> +1.Power Management Integrated Circuit.
> +2.Touch-Screen.
>
>  Required properties:
>  - compatible: "ti,tps6507x"
> @@ -23,6 +27,12 @@ Required properties:
> vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
> vindcdc3-supply  : VDCDC3 input.
> vldo1_2-supply   : VLDO1 and VLDO2 input.
> +- tsc: This node specifies touch screen data.
> +   ti,poll-period : Time at which touch input is getting sampled in ms.
> +   ti,min-pressure: Minimum pressure value to trigger touch.
> +   ti,vref: voltage reference for ADC.
> + 0: Reference voltage for ADC is disabled.
> + 1: Reference voltage for ADC is enabled.
>
>  Regulator Optional properties:
>  - defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
> @@ -30,6 +40,14 @@ Regulator Optional properties:
> 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
>If this property is not defined, it defaults to 0 (not enabled).
>
> +Touchscreen Optional properties:
> +- ti,vendor : Touchscreen vendor id to populate
> + in sysclass interface.
> +- ti,product: Touchscreen product id to populate
> + in sysclass interface.
> +- ti,version: Touchscreen version id to populate
> + in sysclass interface.
> +
>  Example:
>
> pmu: tps6507x@48 {
> @@ -88,4 +106,12 @@ Example:
> };
> };
>
> +   tsc {
> +   ti,poll-period = <30>;
> +   ti,min-pressure = <0x30>;
> +   ti,vref = <0>;
> +   ti,vendor = <0>;
> +   ti,product = <65070>;
> +   ti,version = <0x100>;
> +   };
> };
> diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
> b/drivers/input/touchscreen/tps6507x-ts.c
> index 65e0f9a..89232ee 100644
> --- a/drivers/input/touchscreen/tps6507x-ts.c
> +++ b/drivers/input/touchscreen/tps6507x-ts.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
>  #define TPS_DEFAULT_MIN_PRESSURE 0x30
> @@ -231,36 +233,76 @@ done:
> ret = tps6507x_adc_standby(tsc);
>  }
>
> +static int tsc_init_data(struct tps6507x_dev *tps6507x_dev,
> +   struct input_dev *input_dev)
> +{
> +   struct device_node *node = tps6507x_dev->dev->of_node;
> +   struct tps6507x_board *tps_board =
> +   (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
> +   struct touchscreen_init_data *init_data = NULL;
> +   int err;
> +
> +   if (node)
> +   node = of_find_node_by_name(node, "tsc");
> +   if (tps_board)
> +   init_data = tps_board->tps6507x_ts_init_data;
> +
> +   if (node == NULL || init_data == NULL) {
> +   err = -EINVAL;
> +   goto error_ret;
> +   } else if (init_data) {
> +   tps6507x_dev->ts->poll_period = init_data->poll_period;
> +   tps6507x_dev->ts->min_pressure = init_data->min_pressure;
> +   tps6507x_dev->ts->vref = init_data->vref;
> +   input_dev->id.vendor = init_data->vendor;
> +   input_dev->id.product = init_data->product;
> +   input_dev->id.version = init_data->version;
> +   } else if (node) {
> +   err = of_property_read_u32(node, "ti,poll-period",
> +   (u32 
> *)_dev->ts->poll_period);
> +   if (err < 0)
> + 

Re: [PATCH 1/8] ARM: at91: move peripheral id definitions to dt-bindings include dir

[b.brezillon]

Hello Nicolas,

On Mon, 19 Aug 2013 18:46:13 +0200, Nicolas Ferre
 wrote:
> On 08/08/2013 06:09, boris brezillon :
>> Hello Arnd,
>>
>> On 07/08/2013 22:24, Arnd Bergmann wrote:
>>> On Thursday 01 August 2013, Boris BREZILLON wrote:
 This patch moves peripheral id definitions from machine specific include
 dir (arch/arm/mach-at91/include/mach/'soc-name'.h) to dt-bindinds include
 dir (include/dt-bindings/at91/'soc-name'/peripherals.h).

 These definitions will be used inside dt to define interrupt ids and
 peripheral clk ids.

 Signed-off-by: Boris BREZILLON 
>>> This seems counterproductive, why would you do that?
>>
>> This was requested by Jean-Christophe Plagniol-Villard (and proposed by
>> Richard Genoud)
>> for the 3rd version of the "ARM: at91: move to common clk framework"
>> patch series (see
>> https://lkml.org/lkml/2013/7/29/361) and thought it was a good idea too
>> (even if I didn't know
>> where to put the macro files as there are no soc specific macro files in
>> dt-bindings include
>> dir).
>>
>> Indeed I found it much easier to detect bugs in dt definition using
>> macros because
>> the macro names and dt node names are the same (it does not protect
>> against errors
>> in the macro definitions).
>>
>> If you think these macro definitions should be dropped, I won't argue
>> against this.
>> But please, have a talk with Jean-Christophe first.
> 
> [..]
> 
>>> There is no sharing of identifiers across SoCs here, you just move the
>>> data around, and changing the .dts files to use the abstract macros would
>>> just end up making them harder to understand, not easier, since you then
>>> have to look up the numbers in another file.
> 
> Boris, Jean-Christophe and Richard,
> 
> Well, I must say that I do agree with Arnd on this point.
> 
> I think that a simple numeric field in a cell has to be represented
> as a number and even if this simple information is used twice
> (interrupt number and clock bit position in PMC). The possibility of
> error is very low compared to the big amount of unneeded definitions
> added by this solution.
> 
> Moreover, I had the hope to completely remove this long list of
> peripheral definitions for all SoC when we have a full DT kernel (with
> your patches about common clock framework). So I think it is not
> interesting to move in this direction and continue to build such a
> list for future full DT products...
> 
> Believe me, I am sorry that I didn't entered the discussion earlier
> and avoid unnecessary work... Anyway, give me your opinion, but I do
> think that the simpler is the best.
> 

As discussed with you (on IRC), I am not absolutely convinced we need
these macro definitions, and given the direction you want to take
(completely
remove the peripheral id definitions), i would say we'd rather drop
this patch.
It won't bother me at all to rework the "sama5 dt clk" patch series
(this is the
only SoC I supported in the 3rd version of the at91 common clk
transition)
to remove references to these macros.

Best Regards,
Boris

> Bye,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next v4] net: cpsw: Add support for wake-on-lan for cpsw

[ujhelyi . m]

From: Matus Ujhelyi 

Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 
88E1318S).
There is no way how to enable wol on CPSW with such connected phys. This patch
adds this support. It is provided by calling the phy's related code.

Tested on board with at8030x connected phy. Wol interrupt line is
connected to GPIO0 on am335x.

Signed-off-by: Matus Ujhelyi 
---
 drivers/net/ethernet/ti/cpsw.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 0fcf212..e2a2535 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1640,6 +1640,29 @@ static int cpsw_set_settings(struct net_device *ndev, 
struct ethtool_cmd *ecmd)
return -EOPNOTSUPP;
 }
 
+static void cpsw_get_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
+{
+   struct cpsw_priv *priv = netdev_priv(ndev);
+   int slave_no = cpsw_slave_index(priv);
+
+   wol->supported = 0;
+   wol->wolopts = 0;
+
+   if (priv->slaves[slave_no].phy)
+   phy_ethtool_get_wol(priv->slaves[slave_no].phy, wol);
+}
+
+static int cpsw_set_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
+{
+   struct cpsw_priv *priv = netdev_priv(ndev);
+   int slave_no = cpsw_slave_index(priv);
+
+   if (priv->slaves[slave_no].phy)
+   return phy_ethtool_set_wol(priv->slaves[slave_no].phy, wol);
+   else
+   return -EOPNOTSUPP;
+}
+
 static const struct ethtool_ops cpsw_ethtool_ops = {
.get_drvinfo= cpsw_get_drvinfo,
.get_msglevel   = cpsw_get_msglevel,
@@ -1653,6 +1676,8 @@ static const struct ethtool_ops cpsw_ethtool_ops = {
.get_sset_count = cpsw_get_sset_count,
.get_strings= cpsw_get_strings,
.get_ethtool_stats  = cpsw_get_ethtool_stats,
+   .get_wol= cpsw_get_wol,
+   .set_wol= cpsw_set_wol,
 };
 
 static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv,
-- 
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/

[PATCH net-next v4] net: cpsw: Add support for wake-on-lan for cpsw

[ujhelyi . m]

From: Matus Ujhelyi ujhely...@gmail.com

Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 
88E1318S).
There is no way how to enable wol on CPSW with such connected phys. This patch
adds this support. It is provided by calling the phy's related code.

Tested on board with at8030x connected phy. Wol interrupt line is
connected to GPIO0 on am335x.

Signed-off-by: Matus Ujhelyi ujhely...@gmail.com
---
 drivers/net/ethernet/ti/cpsw.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 0fcf212..e2a2535 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1640,6 +1640,29 @@ static int cpsw_set_settings(struct net_device *ndev, 
struct ethtool_cmd *ecmd)
return -EOPNOTSUPP;
 }
 
+static void cpsw_get_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
+{
+   struct cpsw_priv *priv = netdev_priv(ndev);
+   int slave_no = cpsw_slave_index(priv);
+
+   wol-supported = 0;
+   wol-wolopts = 0;
+
+   if (priv-slaves[slave_no].phy)
+   phy_ethtool_get_wol(priv-slaves[slave_no].phy, wol);
+}
+
+static int cpsw_set_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
+{
+   struct cpsw_priv *priv = netdev_priv(ndev);
+   int slave_no = cpsw_slave_index(priv);
+
+   if (priv-slaves[slave_no].phy)
+   return phy_ethtool_set_wol(priv-slaves[slave_no].phy, wol);
+   else
+   return -EOPNOTSUPP;
+}
+
 static const struct ethtool_ops cpsw_ethtool_ops = {
.get_drvinfo= cpsw_get_drvinfo,
.get_msglevel   = cpsw_get_msglevel,
@@ -1653,6 +1676,8 @@ static const struct ethtool_ops cpsw_ethtool_ops = {
.get_sset_count = cpsw_get_sset_count,
.get_strings= cpsw_get_strings,
.get_ethtool_stats  = cpsw_get_ethtool_stats,
+   .get_wol= cpsw_get_wol,
+   .set_wol= cpsw_set_wol,
 };
 
 static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv,
-- 
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/8] ARM: at91: move peripheral id definitions to dt-bindings include dir

[b.brezillon]

Hello Nicolas,

On Mon, 19 Aug 2013 18:46:13 +0200, Nicolas Ferre
nicolas.fe...@atmel.com wrote:
 On 08/08/2013 06:09, boris brezillon :
 Hello Arnd,

 On 07/08/2013 22:24, Arnd Bergmann wrote:
 On Thursday 01 August 2013, Boris BREZILLON wrote:
 This patch moves peripheral id definitions from machine specific include
 dir (arch/arm/mach-at91/include/mach/'soc-name'.h) to dt-bindinds include
 dir (include/dt-bindings/at91/'soc-name'/peripherals.h).

 These definitions will be used inside dt to define interrupt ids and
 peripheral clk ids.

 Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
 This seems counterproductive, why would you do that?

 This was requested by Jean-Christophe Plagniol-Villard (and proposed by
 Richard Genoud)
 for the 3rd version of the ARM: at91: move to common clk framework
 patch series (see
 https://lkml.org/lkml/2013/7/29/361) and thought it was a good idea too
 (even if I didn't know
 where to put the macro files as there are no soc specific macro files in
 dt-bindings include
 dir).

 Indeed I found it much easier to detect bugs in dt definition using
 macros because
 the macro names and dt node names are the same (it does not protect
 against errors
 in the macro definitions).

 If you think these macro definitions should be dropped, I won't argue
 against this.
 But please, have a talk with Jean-Christophe first.
 
 [..]
 
 There is no sharing of identifiers across SoCs here, you just move the
 data around, and changing the .dts files to use the abstract macros would
 just end up making them harder to understand, not easier, since you then
 have to look up the numbers in another file.
 
 Boris, Jean-Christophe and Richard,
 
 Well, I must say that I do agree with Arnd on this point.
 
 I think that a simple numeric field in a cell has to be represented
 as a number and even if this simple information is used twice
 (interrupt number and clock bit position in PMC). The possibility of
 error is very low compared to the big amount of unneeded definitions
 added by this solution.
 
 Moreover, I had the hope to completely remove this long list of
 peripheral definitions for all SoC when we have a full DT kernel (with
 your patches about common clock framework). So I think it is not
 interesting to move in this direction and continue to build such a
 list for future full DT products...
 
 Believe me, I am sorry that I didn't entered the discussion earlier
 and avoid unnecessary work... Anyway, give me your opinion, but I do
 think that the simpler is the best.
 

As discussed with you (on IRC), I am not absolutely convinced we need
these macro definitions, and given the direction you want to take
(completely
remove the peripheral id definitions), i would say we'd rather drop
this patch.
It won't bother me at all to rework the sama5 dt clk patch series
(this is the
only SoC I supported in the 3rd version of the at91 common clk
transition)
to remove references to these macros.

Best Regards,
Boris

 Bye,

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

Re: [PATCH V3 1/2] tps6507x-ts: Add DT support

[Prabhakar Lad]

Hi Manish,

Thanks for the patch.

On Tue, May 21, 2013 at 2:24 PM, Vishwanathrao Badarkhe, Manish
manish...@ti.com wrote:
 Add device tree based support for TI's tps6507x touchscreen.

 Tested on da850-evm.

 Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
 ---
 Changes since V2:
  - Removed unnecessary code.
  - Updated Documentation to provide proper names of
devicetree properties.

 Changes since V1:
  - Updated documentation to specify tps6507x as multifunctional
device.
  - return proper error value in absence of platform and DT
data for touchscreen.
  - Updated commit message.

 :100755 100755 8fffa3c... 65ee2cd... M  
 Documentation/devicetree/bindings/mfd/tps6507x.txt
 :100644 100644 65e0f9a... 89232ee... M  
 drivers/input/touchscreen/tps6507x-ts.c
  Documentation/devicetree/bindings/mfd/tps6507x.txt |   28 ++-
  drivers/input/touchscreen/tps6507x-ts.c|   98 
 ++--
  2 files changed, 95 insertions(+), 31 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt 
 b/Documentation/devicetree/bindings/mfd/tps6507x.txt
 index 8fffa3c..65ee2cd 100755
 --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
 +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
 @@ -1,4 +1,8 @@
 -TPS6507x Power Management Integrated Circuit
 +TPS6507x Multifunctional Device.
 +
 +Features provided by TPS6507x:
 +1.Power Management Integrated Circuit.
 +2.Touch-Screen.

  Required properties:
  - compatible: ti,tps6507x
 @@ -23,6 +27,12 @@ Required properties:
 vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
 vindcdc3-supply  : VDCDC3 input.
 vldo1_2-supply   : VLDO1 and VLDO2 input.
 +- tsc: This node specifies touch screen data.
 +   ti,poll-period : Time at which touch input is getting sampled in ms.
 +   ti,min-pressure: Minimum pressure value to trigger touch.
 +   ti,vref: voltage reference for ADC.
 + 0: Reference voltage for ADC is disabled.
 + 1: Reference voltage for ADC is enabled.

  Regulator Optional properties:
  - defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
 @@ -30,6 +40,14 @@ Regulator Optional properties:
 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
If this property is not defined, it defaults to 0 (not enabled).

 +Touchscreen Optional properties:
 +- ti,vendor : Touchscreen vendor id to populate
 + in sysclass interface.
 +- ti,product: Touchscreen product id to populate
 + in sysclass interface.
 +- ti,version: Touchscreen version id to populate
 + in sysclass interface.
 +
  Example:

 pmu: tps6507x@48 {
 @@ -88,4 +106,12 @@ Example:
 };
 };

 +   tsc {
 +   ti,poll-period = 30;
 +   ti,min-pressure = 0x30;
 +   ti,vref = 0;
 +   ti,vendor = 0;
 +   ti,product = 65070;
 +   ti,version = 0x100;
 +   };
 };
 diff --git a/drivers/input/touchscreen/tps6507x-ts.c 
 b/drivers/input/touchscreen/tps6507x-ts.c
 index 65e0f9a..89232ee 100644
 --- a/drivers/input/touchscreen/tps6507x-ts.c
 +++ b/drivers/input/touchscreen/tps6507x-ts.c
 @@ -21,6 +21,8 @@
  #include linux/mfd/tps6507x.h
  #include linux/input/tps6507x-ts.h
  #include linux/delay.h
 +#include linux/of.h
 +#include linux/of_device.h

  #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
  #define TPS_DEFAULT_MIN_PRESSURE 0x30
 @@ -231,36 +233,76 @@ done:
 ret = tps6507x_adc_standby(tsc);
  }

 +static int tsc_init_data(struct tps6507x_dev *tps6507x_dev,
 +   struct input_dev *input_dev)
 +{
 +   struct device_node *node = tps6507x_dev-dev-of_node;
 +   struct tps6507x_board *tps_board =
 +   (struct tps6507x_board *)tps6507x_dev-dev-platform_data;
 +   struct touchscreen_init_data *init_data = NULL;
 +   int err;
 +
 +   if (node)
 +   node = of_find_node_by_name(node, tsc);
 +   if (tps_board)
 +   init_data = tps_board-tps6507x_ts_init_data;
 +
 +   if (node == NULL || init_data == NULL) {
 +   err = -EINVAL;
 +   goto error_ret;
 +   } else if (init_data) {
 +   tps6507x_dev-ts-poll_period = init_data-poll_period;
 +   tps6507x_dev-ts-min_pressure = init_data-min_pressure;
 +   tps6507x_dev-ts-vref = init_data-vref;
 +   input_dev-id.vendor = init_data-vendor;
 +   input_dev-id.product = init_data-product;
 +   input_dev-id.version = init_data-version;
 +   } else if (node) {
 +   err = of_property_read_u32(node, ti,poll-period,
 +   (u32 
 *)tps6507x_dev-ts-poll_period);
 +   if (err  0)
 +   goto error_ret;
 +
 +   

Re: [PATCH] ARM: at91/dt: split sam9x5 peripheral definitions

[b.brezillon]

Hello Mike,

On Mon, 19 Aug 2013 15:37:14 -0700, Mike Turquette
mturque...@linaro.org wrote:
 Quoting Nicolas Ferre (2013-08-19 09:23:46)
 On 08/08/2013 17:23, boris brezillon :
  Hello Jean-Christophe,
 
  On 08/08/2013 16:07, Jean-Christophe PLAGNIOL-VILLARD wrote:
  On 12:14 Wed 07 Aug , Boris BREZILLON wrote:
  This patch splits the sam9x5 peripheral definitions into:
  - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
  - several optional peripheral definitions which will be included by 
  specific
  sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
 
  This provides a better representation of the real hardware (drop unneeded
  dt nodes) and avoids future peripheral id conflict (lcdc and isi both use
  peripheral id 25).
  I really don't like this
 
  the mapping is soc specific (here familly) so I does not see any advantage
  except move files so NO for me
  Let me explain in detail why I did that.
 
  This separation was part of the at91 common clk series and was here to
  avoid the
  definition of unavailable clocks or definition of clocks with the same
  id (which may result
  in bad clk registration).
  If we keep all the definitions in one .dtsi file (even the one which are
  not really available),
  I may need to add a new property to each peripheral (and system) clk
  node to specify the
  availabilty of the clock (something similar to 'status=disabled' in
  device nodes).

 This is indeed a pretty good argument.
 I do think that we have to ask Mike Turquette to see if he already has
 encountered such a case.
 
 It is correct to place chip-specific clocks into a chip-specific dts.
 Having clocks marked as disabled in a big dtsi is not the right way to
 go.
 

I agree. As I said earlier, I think unavailable peripherals (and
associated clocks)
should not be part of the dts definition because it may lead to
misinterpretation of
the real hardware parts.
There is a difference between unused IP block (defined with
status=disabled) because
external I/Os are not connected on a specific board and unavailable IP
block (IP block
not available on a given SoC).

This beeing said, I understand the readability concern, and I won't
force this split if
we find a way to declare a clk as unavailable or disabled  

 Regarding naming conflicts, is your issue with string name collisions
 during calls to __clk_lookup?
 

No, there is no collision in clk names, because each optional clock has
a unique name.
But there may be conflicts on clk ids (peripheral ids):

LCDC (LCD Controller) and ISI (Image Sensor Interface) peripherals have
the same id (25)
in sam9x5 SoC family but are never both available in a given SoC.

If you declare LCDC clk before ISI clock, the former will always be
returned when you
reference the ISI clk in ISI peripheral node (clocks=periph 25).

This will work, as the method for enabling/disabling periph clk are the
same for all clks.
But when you print the clk tree (using debugfs) you will see lcdc_clk
with prepare/enable
count incremented and isi_clk always unused, even if the SoC does not
have an LCDC block.

Moreover, isi_clk will be allocated for nothing, because it cannot be
retrieved.

And what happens if an unavailable clock is referenced (I did not test
that, but I guess
the is_enabled callback will always return false)?
This case should not happen if the dts is correctly defined, but still,
I think unavailable
clocks should not be registered in the clk framework.

Please, feel free to share your thoughts.

Best Regards,

Boris

 Thanks,
 Mike
 

 I must say that I was not in favor for this split because of readability
 and dts/dtsi file organization (you know, the usual question: where the
 hell this peripheral property is finally setup?).

 But, if we really have to implement a new kind of property to tell if a
 clock is actually present or not, I am in favor for reconsidering this
 solution as it seems quite simple and self-explanatory...

  As explained to Thomas, I thought device tree was here to give a real
  description of the
  hardware parts (in case of sam9x5.dtsi the description of the common
  parts of sam9x5 SoC
  family).
  If you define peripherals that are not present in a SoC (lets say macb0
  for sam9g15) you break
  this rule.

 Well, on the other hand, the status says disabled, so we can imagine
 that it has been disabled, from its birth, in hardware...

  I'm not telling I have the right approach here, I'm just trying to
  understand what should be done and
  what should not.
 
  Finally, I'd like to point that the memory footprint of the dtb file
  generated after this patch has been
  applied is bit smaller (even if it won't make a real difference):
 
  with this patch:
 
  15937 arch/arm/boot/dts/at91-ariag25.dtb
  15860 arch/arm/boot/dts/at91sam9g15ek.dtb
  16905 arch/arm/boot/dts/at91sam9g25ek.dtb
  16473 arch/arm/boot/dts/at91sam9g35ek.dtb
  17341 arch/arm/boot/dts/at91sam9x25ek.dtb
  16473 arch/arm/boot/dts/at91sam9x35ek.dtb
 
  without this patch:
 
  

[PATCH v3 1/6] mfd:rtsx: Read vendor setting from config space

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

Normally OEMs will set vendor setting to the config space of Realtek
card reader in BIOS stage. This patch reads the setting at the first,
and configure the internal registers according to it, to improve card
reader's compatibility condition.

Signed-off-by: Wei WANG wei_w...@realsil.com.cn
---
 drivers/mfd/rtl8411.c|   77 ---
 drivers/mfd/rts5209.c|   48 +++---
 drivers/mfd/rts5227.c|   91 --
 drivers/mfd/rts5229.c|   38 --
 drivers/mfd/rts5249.c|   90 +++--
 drivers/mfd/rtsx_pcr.c   |   26 ++--
 drivers/mfd/rtsx_pcr.h   |   29 ++
 include/linux/mfd/rtsx_pci.h |   34 +++-
 8 files changed, 365 insertions(+), 68 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index c436bf2..5a68c9b 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -47,19 +47,70 @@ static int rtl8411b_is_qfn48(struct rtsx_pcr *pcr)
return 0;
 }
 
+static void rtl8411_fetch_vendor_settings(struct rtsx_pcr *pcr)
+{
+   u32 reg1;
+   u8 reg3;
+
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg1);
+   dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg1);
+
+   if (!rtsx_vendor_setting_valid(reg1))
+   return;
+
+   pcr-aspm_en = rtsx_reg_to_aspm(reg1);
+   pcr-sd30_drive_sel_1v8 =
+   map_sd_drive(rtsx_reg_to_sd30_drive_sel_1v8(reg1));
+   pcr-card_drive_sel = 0x3F;
+   pcr-card_drive_sel |= rtsx_reg_to_card_drive_sel(reg1);
+
+   rtsx_pci_read_config_byte(pcr, PCR_SETTING_REG3, reg3);
+   dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG3, reg3);
+   pcr-sd30_drive_sel_3v3 = rtl8411_reg_to_sd30_drive_sel_3v3(reg3);
+}
+
+static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr *pcr)
+{
+   u32 reg;
+
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
+   dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+
+   if (!rtsx_vendor_setting_valid(reg))
+   return;
+
+   pcr-aspm_en = rtsx_reg_to_aspm(reg);
+   pcr-sd30_drive_sel_1v8 =
+   map_sd_drive(rtsx_reg_to_sd30_drive_sel_1v8(reg));
+   pcr-sd30_drive_sel_3v3 =
+   map_sd_drive(rtl8411b_reg_to_sd30_drive_sel_3v3(reg));
+}
+
 static int rtl8411_extra_init_hw(struct rtsx_pcr *pcr)
 {
-   return rtsx_pci_write_register(pcr, CD_PAD_CTL,
+   rtsx_pci_init_cmd(pcr);
+
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_DRIVE_SEL,
+   0xFF, pcr-sd30_drive_sel_3v3);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CD_PAD_CTL,
CD_DISABLE_MASK | CD_AUTO_DISABLE, CD_ENABLE);
+
+   return rtsx_pci_send_cmd(pcr, 100);
 }
 
 static int rtl8411b_extra_init_hw(struct rtsx_pcr *pcr)
 {
-   if (rtl8411b_is_qfn48(pcr))
-   rtsx_pci_write_register(pcr, CARD_PULL_CTL3, 0xFF, 0xF5);
+   rtsx_pci_init_cmd(pcr);
 
-   return rtsx_pci_write_register(pcr, CD_PAD_CTL,
+   if (rtl8411b_is_qfn48(pcr))
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   CARD_PULL_CTL3, 0xFF, 0xF5);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_DRIVE_SEL,
+   0xFF, pcr-sd30_drive_sel_3v3);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CD_PAD_CTL,
CD_DISABLE_MASK | CD_AUTO_DISABLE, CD_ENABLE);
+
+   return rtsx_pci_send_cmd(pcr, 100);
 }
 
 static int rtl8411_turn_on_led(struct rtsx_pcr *pcr)
@@ -141,13 +192,13 @@ static int rtl8411_switch_output_voltage(struct rtsx_pcr 
*pcr, u8 voltage)
mask = (BPP_REG_TUNED18  BPP_TUNED18_SHIFT_8411) | BPP_PAD_MASK;
if (voltage == OUTPUT_3V3) {
err = rtsx_pci_write_register(pcr,
-   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_D);
+   SD30_DRIVE_SEL, 0x07, pcr-sd30_drive_sel_3v3);
if (err  0)
return err;
val = (BPP_ASIC_3V3  BPP_TUNED18_SHIFT_8411) | BPP_PAD_3V3;
} else if (voltage == OUTPUT_1V8) {
err = rtsx_pci_write_register(pcr,
-   SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
+   SD30_DRIVE_SEL, 0x07, pcr-sd30_drive_sel_1v8);
if (err  0)
return err;
val = (BPP_ASIC_1V8  BPP_TUNED18_SHIFT_8411) | BPP_PAD_1V8;
@@ -222,6 +273,7 @@ static int rtl8411_conv_clk_and_div_n(int input, int dir)
 }
 
 static const struct pcr_ops rtl8411_pcr_ops = {
+   .fetch_vendor_settings = rtl8411_fetch_vendor_settings,
.extra_init_hw = rtl8411_extra_init_hw,
.optimize_phy = NULL,
.turn_on_led = rtl8411_turn_on_led,
@@ -236,6 +288,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
 

[PATCH v3 6/6] mfd:rtsx: Modify copyright comments

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

Update copyright date, and remove author address.

Signed-off-by: Wei WANG wei_w...@realsil.com.cn
---
 drivers/mfd/rtl8411.c   |4 ++--
 drivers/mfd/rts5209.c   |3 +--
 drivers/mfd/rts5227.c   |5 +
 drivers/mfd/rts5229.c   |3 +--
 drivers/mfd/rts5249.c   |1 -
 drivers/mfd/rtsx_pcr.c  |3 +--
 drivers/mfd/rtsx_pcr.h  |3 +--
 include/linux/mfd/rtsx_common.h |3 +--
 include/linux/mfd/rtsx_pci.h|3 +--
 9 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 37367fb..e4c1833 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,7 @@
  *
  * Author:
  *   Wei WANG wei_w...@realsil.com.cn
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
+ *   Roger Tseng rogera...@realtek.com
  */
 
 #include linux/module.h
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index ef6a59f..4026e1f 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG wei_w...@realsil.com.cn
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include linux/module.h
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index c72abd6..d7cae82 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,10 +17,7 @@
  *
  * Author:
  *   Wei WANG wei_w...@realsil.com.cn
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
- *
  *   Roger Tseng rogera...@realtek.com
- *   No. 2, Innovation Road II, Hsinchu Science Park, Hsinchu 300, Taiwan
  */
 
 #include linux/module.h
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index afb0f24..620e7fa 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG wei_w...@realsil.com.cn
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include linux/module.h
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 384b30b..ea90f8f 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG wei_w...@realsil.com.cn
- *   No. 128, West Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include linux/module.h
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 29932a0..e6ae772 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG wei_w...@realsil.com.cn
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include linux/pci.h
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 7a1b87a..947e79b 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -1,6 +1,6 @@
 /* Driver for Realtek PCI-Express card reader
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the

Re: [PATCH][RFC] Tests on 200 different CPUs/Arches and OSes with CPU Jitter RNG

[Stephan Mueller]

Am Sonntag, 18. August 2013, 20:05:52 schrieb Stephan Mueller:

Hi Ted, Sandy,

For FIPS 140-2, there is currently a draft of an Implementation Guidance 
discussed covering the requirements of seed sources for deterministic 
random number generators. The standard seed source when having no 
hardware RNGs is either /dev/urandom or /dev/random. Please note that 
the current discussion explicitly prohibits the use of /dev/urandom for 
FIPS 140-2 compliant systems.

In addition, the recommendation of SP800-90B is available in draft form 
at [1] placing quite severe requirements on seed sources. After 
assessing the above mentioned IG discussion and in discussions with the 
German BSI, these governmental folks seem to interpret the concept of 
entropy as solely information theoretical entropy. They seem to 
disregard cryptographic strength added by a whitening function. 
Therefore, my gut feeling is that /dev/urandom is also questioned by 
SP800-90B -- but I have no proof at this point.

That focus on information theoretical entropy ultimately implies that 
only /dev/random can be used and /dev/urandom must not be used. 
Naturally, many people are not happy with that due to the blocking 
behavior. Especially in a headless environment like server systems, 
Linux is currently starved of entropy. This is even more a problem with 
virtualized environments. For example, some time ago we tried to obtain 
48 bytes out of /dev/random on a PPC system after the entropy pools 
where completely drained. Well, we got it after some 20 hours as the 
system was quiet (it may now be a bit better with the interrupt usage in 
current kernels, but still there will be a noticeable block).

Now, people will scream: those governmental guys sell snake oil and we 
should still use /dev/urandom. And I have to concur. Yet, I am just 
delivering the message. With the German BSI, the last discussion showed 
that they are open to allowing /dev/urandom based on extensive 
discussions. Yet, you have to make quite a stance to prove that.

- addition of a patch to integrate the RNG into /dev/random as
explained in appendix B.3 of [2], although the long-term goal of the
RNG is rather the integration into the kernel crypto API when
considering the Linux kernel as outlined in appendix B.1 of [2]

All in all, with the suggested CPU Jitter RNG, all of this would be an 
issue of the past on systems the init function considers appropriate -- 
in my tests more than 95% of all systems are accepted. When using my 
patch on /dev/random, dd shows a throughput of about 6kb/s on my system 
when pulling out megabytes of data. It will be slower on slower systems, 
but yet it will not block. Moreover when pulling data for seed which is 
only a few bytes at a time, the invocation of /dev/random will not show 
any noticeable delay.

PS: As I mentioned earlier, however, my long term goal would be that 
callers would disregard /dev/random entirely as it is a central entropy 
source and therefore the prime spot for attacks to reduce entropy. With 
the jitter RNG, even unprivileged user space can have its own instance 
of a seed source.


[1] http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-B


Ciao
Stephan
-- 
| Cui bono? |

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

Re: [PATCH net-next v4] net: cpsw: Add support for wake-on-lan for cpsw

[Mugunthan V N]

On Tuesday 20 August 2013 11:29 AM, ujhely...@gmail.com wrote:
 From: Matus Ujhelyi ujhely...@gmail.com

 Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 
 88E1318S).
 There is no way how to enable wol on CPSW with such connected phys. This patch
 adds this support. It is provided by calling the phy's related code.

 Tested on board with at8030x connected phy. Wol interrupt line is
 connected to GPIO0 on am335x.

 Signed-off-by: Matus Ujhelyi ujhely...@gmail.com
 ---
Looks good to me.

Acked-by: Mugunthan V N mugunthan...@ti.com

Also feel free to add my ack in case if you are submitting one more version.

Regards
Mugunthan V 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/

[PATCH v3 2/6] mfd:rtsx: Add shutdown callback in rtsx_pci_driver

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

Some actions to clear power state should be handled in .shutdown
callback in rtsx_pci_driver. This patch adopts the following measures to
catch this goal:
1. Add a function rtsx_pci_power_off to abstract the common ops in
.shutdown and .suspend
2. Add pcr-ops-force_power_down to fulfill the individual action for
each reader model

Signed-off-by: Wei WANG wei_w...@realsil.com.cn
---
 drivers/mfd/rtl8411.c|7 +++
 drivers/mfd/rts5209.c|6 ++
 drivers/mfd/rts5227.c|   11 +++
 drivers/mfd/rts5229.c|6 ++
 drivers/mfd/rts5249.c|   11 +++
 drivers/mfd/rtsx_pcr.c   |   43 --
 include/linux/mfd/rtsx_pci.h |   13 +++--
 7 files changed, 85 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 5a68c9b..56cc248 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -86,6 +86,11 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtl8411b_reg_to_sd30_drive_sel_3v3(reg));
 }
 
+static void rtl8411_force_power_down(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
+}
+
 static int rtl8411_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
@@ -285,6 +290,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
.conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
+   .force_power_down = rtl8411_force_power_down,
 };
 
 static const struct pcr_ops rtl8411b_pcr_ops = {
@@ -300,6 +306,7 @@ static const struct pcr_ops rtl8411b_pcr_ops = {
.switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
.conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
+   .force_power_down = rtl8411_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 2170449..c67935e 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -59,6 +59,11 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
}
 }
 
+static void rts5209_force_power_down(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
+}
+
 static int rts5209_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
@@ -197,6 +202,7 @@ static const struct pcr_ops rts5209_pcr_ops = {
.switch_output_voltage = rts5209_switch_output_voltage,
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
+   .force_power_down = rts5209_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index c3181d7..42ebf5c 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -83,6 +83,16 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr-flags |= PCR_REVERSE_SOCKET;
 }
 
+static void rts5227_force_power_down(struct rtsx_pcr *pcr)
+{
+   /* Set relink_time to 0 */
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
+
+   rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
+}
+
 static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
 {
u16 cap;
@@ -218,6 +228,7 @@ static const struct pcr_ops rts5227_pcr_ops = {
.switch_output_voltage = rts5227_switch_output_voltage,
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
+   .force_power_down = rts5227_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 7a1ad6d..a0b695a 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -56,6 +56,11 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtsx_reg_to_sd30_drive_sel_3v3(reg));
 }
 
+static void rts5229_force_power_down(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
+}
+
 static int rts5229_extra_init_hw(struct rtsx_pcr *pcr)
 {
rtsx_pci_init_cmd(pcr);
@@ -179,6 +184,7 @@ static const struct pcr_ops rts5229_pcr_ops = {
.switch_output_voltage = rts5229_switch_output_voltage,
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
+   .force_power_down = rts5229_force_power_down,
 };
 
 /* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index d5db182..79ff212 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -88,6 +88,16 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr-flags |= PCR_REVERSE_SOCKET;
 }
 
+static void rts5249_force_power_down(struct rtsx_pcr *pcr)
+{
+   /* Set relink_time to 0 */
+   

[PATCH v3 3/6] mfd:rtsx: Move some actions from rtsx_pci_init_hw to individual extra_init_hw

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

These actions are individual for each reader model, so should be put in
extra_init_hw instead of rtsx_pci_init_hw.

Signed-off-by: Wei WANG wei_w...@realsil.com.cn
---
 drivers/mfd/rts5209.c  |4 
 drivers/mfd/rts5227.c  |2 ++
 drivers/mfd/rts5229.c  |4 
 drivers/mfd/rts5249.c  |2 ++
 drivers/mfd/rtsx_pcr.c |4 
 5 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index c67935e..03a15f7 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -70,6 +70,10 @@ static int rts5209_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Turn off LED */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_GPIO, 0xFF, 0x03);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
+   /* Force CLKREQ# PIN to drive 0 to request clock */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x08, 0x08);
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_GPIO_DIR, 0xFF, 0x03);
/* Configure driving */
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 42ebf5c..724ce4c5 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -101,6 +101,8 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
/* Switch LDO3318 source from DV33 to card_3v3 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index a0b695a..e8261d7 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -67,6 +67,10 @@ static int rts5229_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
+   /* Force CLKREQ# PIN to drive 0 to request clock */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x08, 0x08);
/* Switch LDO3318 source from DV33 to card_3v3 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 79ff212..c5e54d7 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -104,6 +104,8 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
 
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Reset ASPM state to default value */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
/* Switch LDO3318 source from DV33 to card_3v3 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 97526f1..ffd393c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -972,8 +972,6 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, HOST_SLEEP_STATE, 0x03, 0x00);
/* Disable card clock */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_CLK_EN, 0x1E, 0);
-   /* Reset ASPM state to default value */
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, ASPM_FORCE_CTL, 0x3F, 0);
/* Reset delink mode */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CHANGE_LINK_STATE, 0x0A, 0);
/* Card driving select */
@@ -1003,8 +1001,6 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
 *  0: ELBI interrupt flag[31:22]  [7:0] only can be write clear
 */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, NFTS_TX_CTRL, 0x02, 0);
-   /* Force CLKREQ# PIN to drive 0 to request clock */
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x08, 0x08);
 
err = rtsx_pci_send_cmd(pcr, 100);
if (err  0)
-- 
1.7.9.5

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

[PATCH v3 4/6] mfd:rtsx: Clear hardware PFM mode in rtl8411b

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

Clear hw_pfm_en to disable hardware PFM mode, to fix a bug that in some
situation registers in 0xFDxx domain can't be accessed.

Signed-off-by: Wei WANG wei_w...@realsil.com.cn
---
 drivers/mfd/rtl8411.c|2 ++
 include/linux/mfd/rtsx_pci.h |1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 56cc248..d183fa0 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -114,6 +114,8 @@ static int rtl8411b_extra_init_hw(struct rtsx_pcr *pcr)
0xFF, pcr-sd30_drive_sel_3v3);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CD_PAD_CTL,
CD_DISABLE_MASK | CD_AUTO_DISABLE, CD_ENABLE);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, FUNC_FORCE_CTL,
+   0x06, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 11ab786..9a16276 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -687,6 +687,7 @@
 #define PME_FORCE_CTL  0xFE56
 #define ASPM_FORCE_CTL 0xFE57
 #define PM_CLK_FORCE_CTL   0xFE58
+#define FUNC_FORCE_CTL 0xFE59
 #define PERST_GLITCH_WIDTH 0xFE5C
 #define CHANGE_LINK_STATE  0xFE5B
 #define RESET_LOAD_REG 0xFE5E
-- 
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/

[PATCH v3 0/6] MFD patches for Realtek cardreader

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

v3:
Seperate copyright changes to a distinct patch
Modify some coding style and naming style
Fix a bug that sd30_drive_sel would be assigned a wrong value, in rts5227 and 
rts5249

v2:
Use macro when initializing vendor settings

Wei WANG (6):
  mfd:rtsx: Read vendor setting from config space
  mfd:rtsx: Add shutdown callback in rtsx_pci_driver
  mfd:rtsx: Move some actions from rtsx_pci_init_hw to individual
extra_init_hw
  mfd:rtsx: Clear hardware PFM mode in rtl8411b
  mfd:rtsx: Configure to enter a deeper power-saving mode in S3
  mfd:rtsx: Modify copyright comments

 drivers/mfd/rtl8411.c   |   90 ---
 drivers/mfd/rts5209.c   |   61 +++--
 drivers/mfd/rts5227.c   |  113 ++-
 drivers/mfd/rts5229.c   |   51 --
 drivers/mfd/rts5249.c   |  108 +
 drivers/mfd/rtsx_pcr.c  |   76 +++---
 drivers/mfd/rtsx_pcr.h  |   32 ++-
 include/linux/mfd/rtsx_common.h |3 +-
 include/linux/mfd/rtsx_pci.h|   51 --
 9 files changed, 482 insertions(+), 103 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/

[PATCH v3 5/6] mfd:rtsx: Configure to enter a deeper power-saving mode in S3

[wei_wang]

From: Wei WANG wei_w...@realsil.com.cn

Set a bit to enable rts5227 and rts5249 to enter a deeper internal
power-saving mode in S3, and recover it after resuming.

Signed-off-by: Wei WANG wei_w...@realsil.com.cn
---
 drivers/mfd/rtl8411.c|2 +-
 drivers/mfd/rts5209.c|2 +-
 drivers/mfd/rts5227.c|6 +-
 drivers/mfd/rts5229.c|2 +-
 drivers/mfd/rts5249.c|6 +-
 drivers/mfd/rtsx_pcr.c   |2 +-
 include/linux/mfd/rtsx_pci.h |2 +-
 7 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index d183fa0..37367fb 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -86,7 +86,7 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtl8411b_reg_to_sd30_drive_sel_3v3(reg));
 }
 
-static void rtl8411_force_power_down(struct rtsx_pcr *pcr)
+static void rtl8411_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
 }
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 03a15f7..ef6a59f 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -59,7 +59,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
}
 }
 
-static void rts5209_force_power_down(struct rtsx_pcr *pcr)
+static void rts5209_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
rtsx_pci_write_register(pcr, FPDCTL, 0x07, 0x07);
 }
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 724ce4c5..c72abd6 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -83,13 +83,16 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr-flags |= PCR_REVERSE_SOCKET;
 }
 
-static void rts5227_force_power_down(struct rtsx_pcr *pcr)
+static void rts5227_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
 
+   if (pm_state == HOST_ENTER_S3)
+   rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
 
@@ -123,6 +126,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
AUTOLOAD_CFG_BASE + 3, 0xB8, 0x88);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index e8261d7..afb0f24 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -56,7 +56,7 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
map_sd_drive(rtsx_reg_to_sd30_drive_sel_3v3(reg));
 }
 
-static void rts5229_force_power_down(struct rtsx_pcr *pcr)
+static void rts5229_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index c5e54d7..384b30b 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -88,13 +88,16 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
pcr-flags |= PCR_REVERSE_SOCKET;
 }
 
-static void rts5249_force_power_down(struct rtsx_pcr *pcr)
+static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
 {
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
 
+   if (pm_state == HOST_ENTER_S3)
+   rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
 }
 
@@ -119,6 +122,7 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
AUTOLOAD_CFG_BASE + 3, 0xB0, 0x80);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
 
return rtsx_pci_send_cmd(pcr, 100);
 }
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index ffd393c..29932a0 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -939,7 +939,7 @@ static void rtsx_pci_power_off(struct rtsx_pcr *pcr, u8 
pm_state)
rtsx_pci_write_register(pcr, HOST_SLEEP_STATE, 0x03, pm_state);
 
if (pcr-ops-force_power_down)
-   pcr-ops-force_power_down(pcr);
+   pcr-ops-force_power_down(pcr, pm_state);
 }
 
 static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 9a16276..dd0bd58 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ 

Re: [PATCHv3 3/4] clk: sunxi: Add A31 clocks support

[Maxime Ripard]

Hi Emilio,

On Mon, Aug 19, 2013 at 05:14:57PM -0300, Emilio López wrote:
 El 05/08/13 17:43, Maxime Ripard escribió:
 The A31 has a mostly different clock set compared to the other older
 SoCs currently supported in the Allwinner clock driver.
 
 Add support for the basic useful clocks. The other ones will come in
 eventually.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 
 I had another quick look at it and overall it looks good to go,
 
 Reviewed-by: Emilio López emi...@elopez.com.ar

Thanks!

 ---
   Documentation/devicetree/bindings/clock/sunxi.txt  |   6 +
   .../bindings/clock/sunxi/sun6i-a31-gates.txt   |  83 ++
   drivers/clk/sunxi/clk-sunxi.c  | 124 
  +
   3 files changed, 213 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
 
 diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
 b/Documentation/devicetree/bindings/clock/sunxi.txt
 index b24de10..c383d12 100644
 --- a/Documentation/devicetree/bindings/clock/sunxi.txt
 +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
 @@ -8,6 +8,7 @@ Required properties:
   - compatible : shall be one of the following:
  allwinner,sun4i-osc-clk - for a gatable oscillator
  allwinner,sun4i-pll1-clk - for the main PLL clock
 +allwinner,sun6i-a31-pll1-clk - for the main PLL clock on A31
  allwinner,sun4i-cpu-clk - for the CPU multiplexer clock
  allwinner,sun4i-axi-clk - for the AXI clock
  allwinner,sun4i-axi-gates-clk - for the AXI gates
 @@ -15,6 +16,8 @@ Required properties:
  allwinner,sun4i-ahb-gates-clk - for the AHB gates on A10
  allwinner,sun5i-a13-ahb-gates-clk - for the AHB gates on A13
  allwinner,sun5i-a10s-ahb-gates-clk - for the AHB gates on A10s
 +allwinner,sun6i-a31-ahb1-mux-clk - for the AHB1 multiplexer on A31
 +allwinner,sun6i-a31-ahb1-gates-clk - for the AHB1 gates on A31
  allwinner,sun4i-apb0-clk - for the APB0 clock
  allwinner,sun4i-apb0-gates-clk - for the APB0 gates on A10
  allwinner,sun5i-a13-apb0-gates-clk - for the APB0 gates on A13
 @@ -24,6 +27,9 @@ Required properties:
  allwinner,sun4i-apb1-gates-clk - for the APB1 gates on A10
  allwinner,sun5i-a13-apb1-gates-clk - for the APB1 gates on A13
  allwinner,sun5i-a10s-apb1-gates-clk - for the APB1 gates on A10s
 +allwinner,sun6i-a31-apb1-gates-clk - for the APB1 gates on A31
 +allwinner,sun6i-a31-apb2-div-clk - for the APB2 gates on A31
 +allwinner,sun6i-a31-apb2-gates-clk - for the APB2 gates on A31
 
   Required properties for all clocks:
   - reg : shall be the control register address for the clock.
 diff --git 
 a/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt 
 b/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
 new file mode 100644
 index 000..fe44932
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
 @@ -0,0 +1,83 @@
 +Gate clock outputs
 +--
 +
 +  * AHB1 gates (allwinner,sun6i-a31-ahb1-gates-clk)
 +
 +MIPI DSI1
 +
 +SS  5
 +DMA 6
 +
 +MMC08
 +MMC19
 +MMC210
 +MMC311
 +
 +NAND1   12
 +NAND0   13
 +SDRAM   14
 +
 +GMAC17
 +TS  18
 +HSTIMER 19
 +SPI020
 +SPI121
 +SPI222
 +SPI323
 +USB_OTG 24
 +
 +EHCI0   26
 +EHCI1   27
 +
 +OHCI0   29
 +OHCI1   30
 +OHCI2   31
 +VE  32
 +
 +LCD036
 +LCD137
 +
 +CSI 40
 +
 +HDMI43
 +DE_BE0  44
 +DE_BE1  45
 +DE_FE1  46
 +DE_FE1  47
 +
 +MP  50
 +
 +GPU 52
 +
 +DEU055
 +DEU156
 +DRC0

Re: [PATCH] proc: return on proc_readdir error

[Richard Genoud]

2013/8/20 Marc Dionne marc.c.dio...@gmail.com:
 On Mon, Aug 19, 2013 at 7:49 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 On Mon, Aug 19, 2013 at 1:33 PM, Marc Dionne marc.c.dio...@gmail.com wrote:

 By my reading that commit (f0c3b5093add) also made proc_readdir always
 return 0, so with this patch the effect I see is that no pid entries
 are listed under /proc, breaking ps for instance.  I don't see how
 even the previous version of proc_readdir could return a negative
 value; looks like 1 and 0 were the only possible return values.

 Yes, see the other thread. The return 1 case had gotten lost. I
 think current git should get everything right, but please do test. I
 did some testing of my own with a random little getdents test-program
 (just checking that it got the same results with different (small)
 buffer sizes), but it was by no means exhaustive.

   Linus

 It does fix the symptoms I was seeing, thanks.  ps now has output
 and the pid entries are now visible again under /proc.

 Marc
arg !
I was so focused on getting the non-PID proc entries right that I
didn't even see all the missing PIDs when I tested it !

/me need holidays.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] ARC: gdbserver breakage in Big-Endian configuration #1

[greg Kroah-Hartman]

On Tue, Aug 20, 2013 at 10:50:40AM +0530, Vineet Gupta wrote:
 Hi Greg,
 
 On 08/19/2013 08:27 PM, greg Kroah-Hartman wrote:
  On Mon, Aug 19, 2013 at 09:08:49AM +, Vineet Gupta wrote:
  Hi Greg,
 
  I'd posted these patches for stable backport. Do I need to do anything 
  more to get them included.
 
  https://patchwork.kernel.org/patch/2841153/  [1/2] ARC: gdbserver breakage 
  in Big-Endian configuration 
  #1https://patchwork.kernel.org/patch/2841153/]
  https://patchwork.kernel.org/patch/2841158/  [2/2] ARC: gdbserver breakage 
  in Big-Endian configuration #2https://patchwork.kernel.org/patch/2841158/
  
  I ignored them as I thought you were submitting them for upstream
  inclusion.  If they are already in Linus's tree, then take a look at the
  file, Documentation/stable_kernel_rules.txt for how to send a patch for
  inclusion into a stable release (hint, I need to know the git commit id
  that the patch has in Linus's tree, which I didn't see anywhere here.)
 
 
 I'm sure I mentioned the commit-id in the patch. Hint, please look at 
 annotation
 within ---8--- blocks in changelogs.

You're right, I missed that, sorry.

 The caveat however is we can't apply those exact commits as it is as that 
 warrants
 more changes to be pulled in. However I'm going by the last stable kernel 
 rule It
 or an equivalent fix must already exist in Linus' tree (upstream).
 
 Anyhow, since both these patches are extracted from same commit, I'll respin a
 single patch (with a small addition - again part of the same commit) and send 
 it
 over. OK !

That would be great, thanks.

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

[PATCH] MAX7301 GPIO: Reverting Do not force SPI speed when using OF Platform

[Christophe Leroy]

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

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

--- linux-3.11-rc6/drivers/gpio/gpio-max7301.c  2013-08-17 21:09:17.0 
+0200
+++ linux/drivers/gpio/gpio-max7301.c   2013-08-18 06:31:52.0 +0200
@@ -56,8 +56,7 @@
int ret;
 
/* bits_per_word cannot be configured in platform data */
-   if (spi-dev.platform_data)
-   spi-bits_per_word = 16;
+   spi-bits_per_word = 16;
ret = spi_setup(spi);
if (ret  0)
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/

Re: [PATCH V2 07/11] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

On 19 August 2013 17:15, Amit Kucheria amit.kuche...@linaro.org wrote:
 Why do you create .deb packages to test development kernels? It _is_ slow.

 Instead I'd just add a new grub menu entry to /boot/grub/grub.cfg and
 point it to /boot/MyzImage. After a 'make install; make
 modules_install' just link /boot/MyzImage to the installed kernel in
 /boot. And then generate a new initramfs using 'update-initramfs -c -k
 ver'

initramfs was fixed automatically for me with make install.. Thanks it saved
lots of my time :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 07/11] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

On 20 August 2013 04:52, Rafael J. Wysocki r...@sisk.pl wrote:
 From my experience, however, it is good to figure out what needs to be 
 included
 into your test kernel and configure away everything else.  Also, I'd recommend
 to build as much as possible into the kernel image and avoid compiling too 
 many
 modules, because installing modules takes time too (ideally, if you can get
 away without any modules at all, that's the best option timing-wise).  Just
 select only the drivers that you're going to use and unset all of the options
 that don't apply to your test machine.

I haven't done this exercise yet but I have a workable solution with default
.config as suggested by 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: [PATCH V2 07/11] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

On 19 August 2013 16:57, Viresh Kumar viresh.ku...@linaro.org wrote:
 It wasn't my patch actually.. It only made it visible that's it :)
 The problem is:
 - On suspend all CPUs are removed and so governors are
 stopped.
 - On resume, handle_update() is called for the boot cpu and
 cpu_add_dev for all others.

 handle_update() doesn't start governor but only plays with
 CPUFREQ_GOV_LIMITS.. when we start adding other
 CPUs and call: cpufreq_add_policy_cpu() which fails in
 following call:

 __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 and so cpufreq_policy_cpu never gets initialized to
 policy-cpu and stays at -1, and hence the crash.

 So, there are few problems with core at this point:
 - I don't understand how does the work done in
 cpufreq_add_dev() gets done for boot cpu during
 resume ? And so how does Srivatsa's frozen solution
 really works (I haven't had time to investigate, its not
 that I couldn't understand it :) )..

 - We need to start governor boot cpu in handle_update()
 and things would be solved...

Whatever I wrote here was simply _Bullshit_ :(

I am about to send you a fixup patchset that fixes this issue, and
yes it was my patch which introduced this problem :(, but
because of some mishandling of cpufreq_policy_list :)

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

[PATCH 0/5] cpufreq: Fixes for 3.12

[Viresh Kumar]

Hi Rafael,

You recently did this:

commit 878f6e074e9a7784a6e351512eace4ccb3542eef
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date:   Sun Aug 18 15:35:59 2013 +0200

Revert cpufreq: Use cpufreq_policy_list for iterating over policies

Revert commit eb60852 (cpufreq: Use cpufreq_policy_list for iterating
over policies), because it breaks system suspend/resume on multiple
machines.

It either causes resume to block indefinitely or causes the BUG_ON()
in lock_policy_rwsem_##mode() to trigger on sysfs accesses to cpufreq
attributes.

--xx---

This patchset gets the reverted patch back along with few supporting patches.
Cause of the initial problem you observed was this:

- At suspend all CPUs are removed leaving boot cpu. At this time policies aren't
  freed and also aren't removed from cpufreq_policy_list. And per-cpu variable
  cpufreq_cpu_data is marked as NULL.
- At resume CPUs other than boot cpu called __cpufreq_add_dev(). The tricky
  change that was introduced by my patch was: We iterate over list of policies
  instead of CPUs, where we used to get policy structure associated with
  CPUs using per-cpu variable. Which used to be NULL for first CPU of a policy
  that turned up. For the first cpu we don't want to call
  cpufreq_add_policy_cpu() but want __cpufreq_add_add() to continue.

  When we called cpufreq_add_policy_cpu() it tried to stop the governor (which
  was already stopped) and hence errors leading into unstable state.

This patchset fixes these issues and is tested with suspend-resume over my
thinkpad with ubuntu. Apart from minor cleanups it removes policy from
cpufreq_policy_list in case of suspend/resume as well and hence we will never
call cpufreq_add_policy_cpu() for first cpu of a policy.

--
viresh

Viresh Kumar (5):
  cpufreq: align closing brace '}' of an if block
  cpufreq: remove policy from cpufreq_policy_list in system suspend
  cpufreq: remove unnecessary check in __cpufreq_governor()
  cpufreq: remove cpufreq_policy_cpu per-cpu variable
  cpufreq: Use cpufreq_policy_list for iterating over policies

 drivers/cpufreq/cpufreq.c | 77 +++
 1 file changed, 24 insertions(+), 53 deletions(-)

-- 
1.7.12.rc2.18.g61b472e

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] cpufreq: remove policy from cpufreq_policy_list in system suspend

[Viresh Kumar]

cpufreq_policy_list is a list of active policies. We do remove policies from
this list when all CPUs belonging to that policy are removed. But during suspend
we don't really free a policy struct as it will be used again during resume. And
so we didn't remove it from cpufreq_policy_list as well..

This is incorrect. We are saying this policy isn't valid anymore and must not be
referenced (though we haven't freed it), but it can still be used by code that
iterates over cpufreq_policy_list.

Lets remove policy from this list even in case of suspend as well.. Similarly we
must add it back whenever the first cpu belonging to that policy turns up.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 drivers/cpufreq/cpufreq.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fedc842..0302121 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -950,12 +950,6 @@ err_free_policy:
 
 static void cpufreq_policy_free(struct cpufreq_policy *policy)
 {
-   unsigned long flags;
-
-   write_lock_irqsave(cpufreq_driver_lock, flags);
-   list_del(policy-policy_list);
-   write_unlock_irqrestore(cpufreq_driver_lock, flags);
-
free_cpumask_var(policy-related_cpus);
free_cpumask_var(policy-cpus);
kfree(policy);
@@ -1069,12 +1063,12 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
ret = cpufreq_add_dev_interface(policy, dev);
if (ret)
goto err_out_unregister;
-
-   write_lock_irqsave(cpufreq_driver_lock, flags);
-   list_add(policy-policy_list, cpufreq_policy_list);
-   write_unlock_irqrestore(cpufreq_driver_lock, flags);
}
 
+   write_lock_irqsave(cpufreq_driver_lock, flags);
+   list_add(policy-policy_list, cpufreq_policy_list);
+   write_unlock_irqrestore(cpufreq_driver_lock, flags);
+
cpufreq_init_policy(policy);
 
kobject_uevent(policy-kobj, KOBJ_ADD);
@@ -1280,6 +1274,11 @@ static int __cpufreq_remove_dev(struct device *dev,
if (cpufreq_driver-exit)
cpufreq_driver-exit(policy);
 
+   /* Remove policy from list of active policies */
+   write_lock_irqsave(cpufreq_driver_lock, flags);
+   list_del(policy-policy_list);
+   write_unlock_irqrestore(cpufreq_driver_lock, flags);
+
if (!frozen)
cpufreq_policy_free(policy);
} else {
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 1/5] cpufreq: align closing brace '}' of an if block

[Viresh Kumar]

Following patch caused this:

commit 3de9bdeb28638e164d1f0eb38dd68e3f5d2ac95c
Author: Viresh Kumar viresh.ku...@linaro.org
Date:   Tue Aug 6 22:53:13 2013 +0530

cpufreq: improve error checking on return values of __cpufreq_governor()

Lets fix it.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 drivers/cpufreq/cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index c0ef84d..fedc842 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1253,7 +1253,7 @@ static int __cpufreq_remove_dev(struct device *dev,
__func__);
return ret;
}
-   }
+   }
 
if (!frozen) {
lock_policy_rwsem_read(cpu);
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 3/5] cpufreq: remove unnecessary check in __cpufreq_governor()

[Viresh Kumar]

We don't need to check if event is CPUFREQ_GOV_POLICY_INIT and put governor
module as we are sure event can only be START/STOP here.

And so remove this useless check.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 drivers/cpufreq/cpufreq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0302121..b03a851 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1719,8 +1719,6 @@ static int __cpufreq_governor(struct cpufreq_policy 
*policy,
if ((!policy-governor_enabled  (event == CPUFREQ_GOV_STOP)) ||
(policy-governor_enabled  (event == CPUFREQ_GOV_START))) {
mutex_unlock(cpufreq_governor_lock);
-   if (event == CPUFREQ_GOV_POLICY_INIT)
-   module_put(policy-governor-owner);
return -EBUSY;
}
 
-- 
1.7.12.rc2.18.g61b472e

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

[PATCH 4/5] cpufreq: remove cpufreq_policy_cpu per-cpu variable

[Viresh Kumar]

cpufreq_policy_cpu per-cpu variables are used for storing cpu that manages a cpu
or its policy-cpu. We are also storing policy for each cpu in cpufreq_cpu_data
and so this information is just redundant.

Better use cpufreq_cpu_data to retrieve policy and get policy-cpu from there.
And so this patch removes cpufreq_policy_cpu per-cpu variable.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 drivers/cpufreq/cpufreq.c | 45 ++---
 1 file changed, 10 insertions(+), 35 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b03a851..0586bd2 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -64,15 +64,14 @@ static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], 
cpufreq_cpu_governor);
  * - Lock should not be held across
  * __cpufreq_governor(data, CPUFREQ_GOV_STOP);
  */
-static DEFINE_PER_CPU(int, cpufreq_policy_cpu);
 static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
 
 #define lock_policy_rwsem(mode, cpu)   \
 static int lock_policy_rwsem_##mode(int cpu)   \
 {  \
-   int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);  \
-   BUG_ON(policy_cpu == -1);   \
-   down_##mode(per_cpu(cpu_policy_rwsem, policy_cpu));\
+   struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
+   BUG_ON(!policy);\
+   down_##mode(per_cpu(cpu_policy_rwsem, policy-cpu));   \
\
return 0;   \
 }
@@ -83,9 +82,9 @@ lock_policy_rwsem(write, cpu);
 #define unlock_policy_rwsem(mode, cpu) \
 static void unlock_policy_rwsem_##mode(int cpu)
\
 {  \
-   int policy_cpu = per_cpu(cpufreq_policy_cpu, cpu);  \
-   BUG_ON(policy_cpu == -1);   \
-   up_##mode(per_cpu(cpu_policy_rwsem, policy_cpu));  \
+   struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
+   BUG_ON(!policy);\
+   up_##mode(per_cpu(cpu_policy_rwsem, policy-cpu)); \
 }
 
 unlock_policy_rwsem(read, cpu);
@@ -887,7 +886,6 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy 
*policy,
write_lock_irqsave(cpufreq_driver_lock, flags);
 
cpumask_set_cpu(cpu, policy-cpus);
-   per_cpu(cpufreq_policy_cpu, cpu) = policy-cpu;
per_cpu(cpufreq_cpu_data, cpu) = policy;
write_unlock_irqrestore(cpufreq_driver_lock, flags);
 
@@ -1013,9 +1011,6 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
policy-governor = CPUFREQ_DEFAULT_GOVERNOR;
cpumask_copy(policy-cpus, cpumask_of(cpu));
 
-   /* Initially set CPU itself as the policy_cpu */
-   per_cpu(cpufreq_policy_cpu, cpu) = cpu;
-
init_completion(policy-kobj_unregister);
INIT_WORK(policy-update, handle_update);
 
@@ -1053,10 +1048,8 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
 #endif
 
write_lock_irqsave(cpufreq_driver_lock, flags);
-   for_each_cpu(j, policy-cpus) {
+   for_each_cpu(j, policy-cpus)
per_cpu(cpufreq_cpu_data, j) = policy;
-   per_cpu(cpufreq_policy_cpu, j) = policy-cpu;
-   }
write_unlock_irqrestore(cpufreq_driver_lock, flags);
 
if (!frozen) {
@@ -1080,15 +1073,11 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
 
 err_out_unregister:
write_lock_irqsave(cpufreq_driver_lock, flags);
-   for_each_cpu(j, policy-cpus) {
+   for_each_cpu(j, policy-cpus)
per_cpu(cpufreq_cpu_data, j) = NULL;
-   if (j != cpu)
-   per_cpu(cpufreq_policy_cpu, j) = -1;
-   }
write_unlock_irqrestore(cpufreq_driver_lock, flags);
 
 err_set_policy_cpu:
-   per_cpu(cpufreq_policy_cpu, cpu) = -1;
cpufreq_policy_free(policy);
 nomem_out:
up_read(cpufreq_rwsem);
@@ -1112,14 +1101,9 @@ static int cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif)
 
 static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
 {
-   int j;
-
policy-last_cpu = policy-cpu;
policy-cpu = cpu;
 
-   for_each_cpu(j, policy-cpus)
-   per_cpu(cpufreq_policy_cpu, j) = cpu;
-
 #ifdef CONFIG_CPU_FREQ_TABLE
cpufreq_frequency_table_update_policy_cpu(policy);
 #endif
@@ -1131,7 +1115,6 @@ static int cpufreq_nominate_new_policy_cpu(struct 
cpufreq_policy *policy,

[PATCH 5/5] cpufreq: Use cpufreq_policy_list for iterating over policies

[Viresh Kumar]

To iterate over all policies we currently iterate over all CPUs and
then get the policy for each of them.  Let's use the newly created
cpufreq_policy_list for this purpose.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 drivers/cpufreq/cpufreq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0586bd2..81ceea6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -961,8 +961,8 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
struct cpufreq_policy *policy;
unsigned long flags;
 #ifdef CONFIG_HOTPLUG_CPU
+   struct cpufreq_policy *tpolicy;
struct cpufreq_governor *gov;
-   int sibling;
 #endif
 
if (cpu_is_offline(cpu))
@@ -985,11 +985,10 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
 #ifdef CONFIG_HOTPLUG_CPU
/* Check if this cpu was hot-unplugged earlier and has siblings */
read_lock_irqsave(cpufreq_driver_lock, flags);
-   for_each_online_cpu(sibling) {
-   struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
-   if (cp  cpumask_test_cpu(cpu, cp-related_cpus)) {
+   list_for_each_entry(tpolicy, cpufreq_policy_list, policy_list) {
+   if (cpumask_test_cpu(cpu, tpolicy-related_cpus)) {
read_unlock_irqrestore(cpufreq_driver_lock, flags);
-   ret = cpufreq_add_policy_cpu(cp, cpu, dev, frozen);
+   ret = cpufreq_add_policy_cpu(tpolicy, cpu, dev, frozen);
up_read(cpufreq_rwsem);
return ret;
}
-- 
1.7.12.rc2.18.g61b472e

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