Re: [RFC 16/17] openrisc: default GENERIC_GPIO to false

[Jonas Bonn]

On 03/12/13 11:12, Alexandre Courbot wrote:

This is one step towards the removal of the GENERIC_GPIO option.
OpenRISC mandates the use of GPIOLIB, which enables GENERIC_GPIO anyway,
so this patch should be a no-op.


Acked-by: Jonas Bonn 


Signed-off-by: Alexandre Courbot 
---
  arch/openrisc/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 28df179..5366bbf 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -46,7 +46,7 @@ config NO_IOPORT
def_bool y
  
  config GENERIC_GPIO

-   def_bool y
+   def_bool n
  
  config TRACE_IRQFLAGS_SUPPORT

  def_bool y


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

[Stephen Rothwell]

Hi all,

Changes since 20130312:

The input tree lost its build failure.

The net-next tree lost its conflict.

The drm-intel still had its build failure for which I reverted a commit.

The trivial tree gained a conflict against the virtio tree.

The gpio tree still had its build failure for which I reverted a commit.

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

The staging tree gained a build failure for which I applied a patch.

The akpm tree gained a conflicts against the workqueues and rcu trees.



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 217 trees (counting Linus' and 28 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 (4febd95 Select VIRT_TO_BUS directly where needed)
Merging fixes/master (d287b87 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arc-current/for-curr (180d406 ARC: ABIv3: fork/vfork wrappers not 
needed in "no-legacy-syscall" ABI)
Merging arm-current/fixes (418df63a ARM: 7670/1: fix the memset fix)
Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. 
CONFIG_HAS_DMA)
Merging powerpc-merge/merge (54c9b225 powerpc: Set DSCR bit in FSCR setup)
Merging sparc/master (76950e6 sparc64: correctly recognize SPARC64-X chips)
Merging net/master (c80a851 net/core: move vlan_depth out of while loop in 
skb_network_protocol())
Merging ipsec/master (85dfb74 af_key: initialize satype in 
key_notify_policy_flush())
Merging sound-current/for-linus (281a6ac ALSA: usb-audio: add a workaround for 
the NuForce UDH-100)
Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing 
a device)
Merging wireless/master (de12198 Merge tag 'nfc-fixes-3.9-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes)
Merging driver-core.current/driver-core-linus (f6161aa Linux 3.9-rc2)
Merging tty.current/tty-linus (c51d41a tty: serial: fix typo "SERIAL_S3C2412")
Merging usb.current/usb-linus (c0f5ece USB: cdc-wdm: fix buffer overflow)
Merging staging.current/staging-linus (564c526 staging: comedi: dt9812: use 
CR_CHAN() for channel number)
Merging char-misc.current/char-misc-linus (3d374d0 final removal of 
CONFIG_EXPERIMENTAL)
Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable 
and disable paths)
Merging md-current/for-linus (f3378b4 md: expedite metadata update when 
switching  read-auto -> active)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied 
strings are nul-terminated)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option)
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/powerpc/Kconfig
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/m

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Bill Huang]

On Wed, 2013-03-13 at 13:24 +0800, Stephen Warren wrote:
> On 03/12/2013 11:08 PM, Bill Huang wrote:
> > On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote:
> >> On 03/12/2013 07:47 PM, Bill Huang wrote:
> >>> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
>  On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> > Add the below four notifier events so drivers which are interested in
> > knowing the clock status can act accordingly. This is extremely useful
> > in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
> >
> > PRE_CLK_ENABLE
> > POST_CLK_ENABLE
> > PRE_CLK_DISABLE
> > POST_CLK_DISABLE
> >
> > Signed-off-by: Bill Huang 
> 
>  NAK.  *Sigh* NO, this is the wrong level to be doing stuff like this.
> 
>  The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() 
>  should
>  *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and
>  clk_unprepare().  Those two functions are *merely* helpers for drivers
>  who don't wish to make the individual calls.
> 
>  Drivers are still completely free to call the individual functions, at
>  which point your proposal breaks horribly - and they _do_ call the
>  individual functions.
> >>>
> >>> I'm proposing to give device driver a choice when it knows that some
> >>> driver might be interested in knowing its clock's enabled/disabled state
> >>> change at runtime, this is very important for centralized DVFS core
> >>> driver. It is not meant to be covering all cases especially for drivers
> >>> which is not part of the DVFS, so we don't care if it is calling
> >>> clk_enable/disable directly or not.
> >>
> >> I believe the point Russell is making is not that the idea behind this
> >> patch is wrong, but simply that the function where you put the hooks is
> >> wrong. The hooks should at least be in clk_enable/clk_disable and not
> >> clk_prepare_enable/clk_disable_unprepare, since any driver is free to
> >> call clk_prepare separately from clk_enable. The hooks should be
> >> implemented in the lowest-level common function that all
> >> driver-accessible paths call through.
> > 
> > Thanks, I know the point, but unfortunately there is no good choice for
> > hooking this since those low level functions clk_enable/clk_disable will
> > be called in interrupt context so it is not possible to send notify. We
> > might need to come out a better approach if we can think of any.
> > Currently I still think this is acceptable (Having all the drivers which
> > are using our interested clocks call these function to enable/disable
> > clock in their runtime_pm calls) though it's not perfect. 
> 
> No, that definitely won't work. Not all drivers use those APIs, nor
> should they.
> 
That will be too bad, it looks like we deadlock in the mechanism, we
cannot change existing drivers behavior (that means some call
clk_disable/enable directly, some are not), and we cannot hook notifier
in clk_disable/enable either, that means there seems no any chance to
get what we want, any idea?


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

[Stephen Rothwell]

Hi all,

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

drivers/staging/dwc2/hcd.c: In function '_dwc2_hcd_urb_enqueue':
drivers/staging/dwc2/hcd.c:2387:3: error: implicit declaration of function 
'bus_to_virt' [-Werror=implicit-function-declaration]
drivers/staging/dwc2/hcd.c:2387:7: warning: assignment makes pointer from 
integer without a cast [enabled by default]

Caused by commit 7359d482eb4d ("staging: HCD files for the DWC2 driver").

From Documentation/bus-virt-phys-mapping.txt:

"[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
superseded by the functionality provided by the PCI DMA interface
(see Documentation/DMA-API-HOWTO.txt).  They continue
to be documented below for historical purposes, but new code
must not use them. --davidm 00/12/12 ]"

See also Documentation/DMA-API-HOWTO.txt.

I have added this patch for today:

From: Stephen Rothwell 
Date: Wed, 13 Mar 2013 16:35:50 +1100
Subject: [PATCH] staging: the DWC2 driver uses bus_to_virt

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/dwc2/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/dwc2/Kconfig b/drivers/staging/dwc2/Kconfig
index 610418a..bc4cdfe 100644
--- a/drivers/staging/dwc2/Kconfig
+++ b/drivers/staging/dwc2/Kconfig
@@ -1,6 +1,7 @@
 config USB_DWC2
tristate "DesignWare USB2 DRD Core Support"
depends on USB
+   depends on VIRT_TO_BUS
select USB_OTG_UTILS
help
  Say Y or M here if your system has a Dual Role HighSpeed
-- 
1.8.1


-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpV5br2mheXH.pgp
Description: PGP signature

Re: [PATCH v2, part1 25/29] mm/x86: use common help functions to free reserved pages

[Yasuaki Ishimatsu]

Hi Jiang,

2013/03/10 15:27, Jiang Liu wrote:
> Use common help functions to free reserved pages.
> 
> Signed-off-by: Jiang Liu 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> ---
>   arch/x86/mm/init.c|5 +
>   arch/x86/mm/init_64.c |5 ++---
>   2 files changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 4903a03..4a705e6 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -516,11 +516,8 @@ void free_init_pages(char *what, unsigned long begin, 
> unsigned long end)

>   printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 10);
>   
>   for (; addr < end; addr += PAGE_SIZE) {
> - ClearPageReserved(virt_to_page(addr));
> - init_page_count(virt_to_page(addr));
>   memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
> - free_page(addr);
> - totalram_pages++;
> + free_reserved_page(virt_to_page(addr));
>   }

If I don't misread your code, avobe codes can replace to free_reserved_area()
as follow:

free_reserved_area(addr, end, POISON_FREE_INITMEM, what)

Am I wrong?

Thanks,
Yasuaki Ishimatsu

>   #endif
>   }
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 474e28f..2ef81f1 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1067,10 +1067,9 @@ void __init mem_init(void)
>   
>   /* clear_bss() already clear the empty_zero_page */
>   
> - reservedpages = 0;
> -
> - /* this will put all low memory onto the freelists */
>   register_page_bootmem_info();
> +
> + /* this will put all memory onto the freelists */
>   totalram_pages = free_all_bootmem();
>   
>   absent_pages = absent_pages_in_range(0, max_pfn);
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/14] mailbox: rename pl320-ipc specific mailbox.h

[Anna, Suman]

> On Tue, Mar 12, 2013 at 10:23:50PM -0500, Suman Anna wrote:
> > The patch 30058677 "ARM / highbank: add support for pl320 IPC"
> > added a pl320 IPC specific header file as a generic mailbox.h.
> > This file has been renamed appropriately to allow the introduction of
> > the generic mailbox API framework.
> >
> > Signed-off-by: Suman Anna 
> > Cc: Mark Langsdorf 
> > Cc: Rafael J. Wysocki 
> > ---
> >  drivers/cpufreq/highbank-cpufreq.c |  2 +-
> >  drivers/mailbox/pl320-ipc.c|  2 +-
> >  include/linux/mailbox.h| 17 -
> >  include/linux/pl320-ipc.h  | 17 +
> >  4 files changed, 19 insertions(+), 19 deletions(-)  delete mode
> > 100644 include/linux/mailbox.h  create mode 100644
> > include/linux/pl320-ipc.h
> 
> Why are you sending these To: me?  I'm not the mailbox maintainer, and have
> never handled them before that I can remember.  Who is the maintainer?

Er.. sorry Greg, I have taken the recipient list from the original series 
posting, but this series should have been directed to the ARM-SoC maintainer. 
The patches are generalizing the OMAP mailbox driver to add support for ST's 
mailbox as well,  and moving it to under /drivers/mailbox. The folder is new in 
3.9, and the code under this, so far,  has all been for ARM based chips. I 
guess the maintainer for this folder needs to be sorted out for the long-term.

Regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Stephen Warren]

On 03/12/2013 11:08 PM, Bill Huang wrote:
> On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote:
>> On 03/12/2013 07:47 PM, Bill Huang wrote:
>>> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
 On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> Add the below four notifier events so drivers which are interested in
> knowing the clock status can act accordingly. This is extremely useful
> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
>
> PRE_CLK_ENABLE
> POST_CLK_ENABLE
> PRE_CLK_DISABLE
> POST_CLK_DISABLE
>
> Signed-off-by: Bill Huang 

 NAK.  *Sigh* NO, this is the wrong level to be doing stuff like this.

 The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should
 *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and
 clk_unprepare().  Those two functions are *merely* helpers for drivers
 who don't wish to make the individual calls.

 Drivers are still completely free to call the individual functions, at
 which point your proposal breaks horribly - and they _do_ call the
 individual functions.
>>>
>>> I'm proposing to give device driver a choice when it knows that some
>>> driver might be interested in knowing its clock's enabled/disabled state
>>> change at runtime, this is very important for centralized DVFS core
>>> driver. It is not meant to be covering all cases especially for drivers
>>> which is not part of the DVFS, so we don't care if it is calling
>>> clk_enable/disable directly or not.
>>
>> I believe the point Russell is making is not that the idea behind this
>> patch is wrong, but simply that the function where you put the hooks is
>> wrong. The hooks should at least be in clk_enable/clk_disable and not
>> clk_prepare_enable/clk_disable_unprepare, since any driver is free to
>> call clk_prepare separately from clk_enable. The hooks should be
>> implemented in the lowest-level common function that all
>> driver-accessible paths call through.
> 
> Thanks, I know the point, but unfortunately there is no good choice for
> hooking this since those low level functions clk_enable/clk_disable will
> be called in interrupt context so it is not possible to send notify. We
> might need to come out a better approach if we can think of any.
> Currently I still think this is acceptable (Having all the drivers which
> are using our interested clocks call these function to enable/disable
> clock in their runtime_pm calls) though it's not perfect. 

No, that definitely won't work. Not all drivers use those APIs, nor
should they.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/17] Remove GENERIC_GPIO from architecture code

[Linus Walleij]

On Tue, Mar 12, 2013 at 11:12 AM, Alexandre Courbot  wrote:

> This series makes sure the GENERIC_GPIO option can only be set through GPIOLIB
> (and not by individual architectures), as a first step towards its removal.

Nice!
Acked-by: Linus Walleij 

I bet something will break, anyway: no pain no gain.

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

linux-next: build failure after merge of the final tree (cgroup tree related)

[Stephen Rothwell]

Hi all,

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

In file included from include/linux/memcontrol.h:22:0,
 from include/linux/swap.h:8,
 from include/linux/suspend.h:4,
 from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/cgroup.h:748:13: warning: 'struct cgroupstats' declared inside 
parameter list [enabled by default]
include/linux/cgroup.h:748:13: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
cc1: all warnings being treated as errors

and many more similar.

Caused by commit c2c9ad164fa3 ("cgroup: remove unneeded includes from
cgroup.h").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpLNNfD7L2CH.pgp
Description: PGP signature

RE: [PATCH] ASoC: samsung: remove last traces of neo1973-gta01

[Kukjin Kim]

Paul Bolle wrote:
> 
> The (rudimentary) support for the Openmoko Neo1973 GTA01 got removed in
> commit 1ae5cbc52e7c6619a3f44b87809fd25370df31bb ("ASoC: neo1973_wm8753:
> remove references to the neo1973-gta01 machine"). Remove its last traces
> in the Kconfig file too.
> 
> Signed-off-by: Paul Bolle 

Acked-by: Kukjin Kim 

- Kukjin

> ---
> Untested.
> 
>  sound/soc/samsung/Kconfig | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
> index 90e7e66..475fb0d 100644
> --- a/sound/soc/samsung/Kconfig
> +++ b/sound/soc/samsung/Kconfig
> @@ -35,11 +35,10 @@ config SND_SAMSUNG_I2S
>   tristate
> 
>  config SND_SOC_SAMSUNG_NEO1973_WM8753
> - tristate "Audio support for Openmoko Neo1973 Smartphones (GTA01/GTA02)"
> - depends on SND_SOC_SAMSUNG && (MACH_NEO1973_GTA01 || MACH_NEO1973_GTA02)
> + tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
> + depends on SND_SOC_SAMSUNG && MACH_NEO1973_GTA02
>   select SND_S3C24XX_I2S
>   select SND_SOC_WM8753
> - select SND_SOC_LM4857 if MACH_NEO1973_GTA01
>   select SND_SOC_DFBMCS320
>   help
> Say Y here to enable audio support for the Openmoko Neo1973
> --
> 1.7.11.7

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

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Bill Huang]

On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote:
> On 03/12/2013 07:47 PM, Bill Huang wrote:
> > On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
> >> On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> >>> Add the below four notifier events so drivers which are interested in
> >>> knowing the clock status can act accordingly. This is extremely useful
> >>> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
> >>>
> >>> PRE_CLK_ENABLE
> >>> POST_CLK_ENABLE
> >>> PRE_CLK_DISABLE
> >>> POST_CLK_DISABLE
> >>>
> >>> Signed-off-by: Bill Huang 
> >>
> >> NAK.  *Sigh* NO, this is the wrong level to be doing stuff like this.
> >>
> >> The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should
> >> *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and
> >> clk_unprepare().  Those two functions are *merely* helpers for drivers
> >> who don't wish to make the individual calls.
> >>
> >> Drivers are still completely free to call the individual functions, at
> >> which point your proposal breaks horribly - and they _do_ call the
> >> individual functions.
> >
> > I'm proposing to give device driver a choice when it knows that some
> > driver might be interested in knowing its clock's enabled/disabled state
> > change at runtime, this is very important for centralized DVFS core
> > driver. It is not meant to be covering all cases especially for drivers
> > which is not part of the DVFS, so we don't care if it is calling
> > clk_enable/disable directly or not.
> 
> I believe the point Russell is making is not that the idea behind this
> patch is wrong, but simply that the function where you put the hooks is
> wrong. The hooks should at least be in clk_enable/clk_disable and not
> clk_prepare_enable/clk_disable_unprepare, since any driver is free to
> call clk_prepare separately from clk_enable. The hooks should be
> implemented in the lowest-level common function that all
> driver-accessible paths call through.

Thanks, I know the point, but unfortunately there is no good choice for
hooking this since those low level functions clk_enable/clk_disable will
be called in interrupt context so it is not possible to send notify. We
might need to come out a better approach if we can think of any.
Currently I still think this is acceptable (Having all the drivers which
are using our interested clocks call these function to enable/disable
clock in their runtime_pm calls) though it's not perfect. 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] perf: remove unused perf_session__remove_thread

[David Ahern]

Signed-off-by: David Ahern 
---
 tools/perf/util/session.c |   12 
 tools/perf/util/session.h |1 -
 2 files changed, 13 deletions(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index bd85280b..ab265c2 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1365,18 +1365,6 @@ size_t perf_session__fprintf(struct perf_session 
*session, FILE *fp)
return machine__fprintf(>machines.host, fp);
 }
 
-void perf_session__remove_thread(struct perf_session *session,
-struct thread *th)
-{
-   /*
-* FIXME: This one makes no sense, we need to remove the thread from
-* the machine it belongs to, perf_session can have many machines, so
-* doing it always on ->machines.host is wrong.  Fix when auditing all
-* the 'perf kvm' code.
-*/
-   machine__remove_thread(>machines.host, th);
-}
-
 struct perf_evsel *perf_session__find_first_evtype(struct perf_session 
*session,
  unsigned int type)
 {
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index b5c0847..6b51d47 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -72,7 +72,6 @@ void perf_event__attr_swap(struct perf_event_attr *attr);
 int perf_session__create_kernel_maps(struct perf_session *self);
 
 void perf_session__set_id_hdr_size(struct perf_session *session);
-void perf_session__remove_thread(struct perf_session *self, struct thread *th);
 
 static inline
 struct machine *perf_session__find_machine(struct perf_session *self, pid_t 
pid)
-- 
1.7.10.1

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

[PATCH 0/4] perf: remove unused functions

[David Ahern]

Hi Arnaldo:

Going through my backlog of perf cleanup patches. These remove unused
functions and then makes a sole callee static.

David Ahern (4):
  perf: remove unused print_event function
  perf: remove unused print_trace_event function
  perf: remove unused perf_session__remove_thread
  perf: move machine__remove_thread and make static

 tools/perf/util/machine.c   |   22 ++---
 tools/perf/util/machine.h   |1 -
 tools/perf/util/session.c   |   12 
 tools/perf/util/session.h   |1 -
 tools/perf/util/trace-event-parse.c |   37 ---
 tools/perf/util/trace-event.h   |4 
 6 files changed, 11 insertions(+), 66 deletions(-)

-- 
1.7.10.1

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

[PATCH 1/4] perf: remove unused print_event function

[David Ahern]

Signed-off-by: David Ahern 
---
 tools/perf/util/trace-event-parse.c |   24 
 tools/perf/util/trace-event.h   |3 ---
 2 files changed, 27 deletions(-)

diff --git a/tools/perf/util/trace-event-parse.c 
b/tools/perf/util/trace-event-parse.c
index 3aabcd6..8450bec 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -196,30 +196,6 @@ void print_trace_event(struct pevent *pevent, int cpu, 
void *data, int size)
event_format__print(event, cpu, data, size);
 }
 
-void print_event(struct pevent *pevent, int cpu, void *data, int size,
-unsigned long long nsecs, char *comm)
-{
-   struct pevent_record record;
-   struct trace_seq s;
-   int pid;
-
-   pevent->latency_format = latency_format;
-
-   record.ts = nsecs;
-   record.cpu = cpu;
-   record.size = size;
-   record.data = data;
-   pid = pevent_data_pid(pevent, );
-
-   if (!pevent_pid_is_registered(pevent, pid))
-   pevent_register_comm(pevent, comm, pid);
-
-   trace_seq_init();
-   pevent_print_event(pevent, , );
-   trace_seq_do_printf();
-   printf("\n");
-}
-
 void parse_proc_kallsyms(struct pevent *pevent,
 char *file, unsigned int size __maybe_unused)
 {
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index a55fd37..99f621f 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -34,9 +34,6 @@ void print_trace_event(struct pevent *pevent, int cpu, void 
*data, int size);
 void event_format__print(struct event_format *event,
 int cpu, void *data, int size);
 
-void print_event(struct pevent *pevent, int cpu, void *data, int size,
-unsigned long long nsecs, char *comm);
-
 int parse_ftrace_file(struct pevent *pevent, char *buf, unsigned long size);
 int parse_event_file(struct pevent *pevent,
 char *buf, unsigned long size, char *sys);
-- 
1.7.10.1

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

[PATCH 4/4] perf: move machine__remove_thread and make static

[David Ahern]

Signed-off-by: David Ahern 
---
 tools/perf/util/machine.c |   22 +++---
 tools/perf/util/machine.h |1 -
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index efdb38e..c5e3b12 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1003,6 +1003,17 @@ int machine__process_fork_event(struct machine *machine, 
union perf_event *event
return 0;
 }
 
+static void machine__remove_thread(struct machine *machine, struct thread *th)
+{
+   machine->last_match = NULL;
+   rb_erase(>rb_node, >threads);
+   /*
+* We may have references to this thread, for instance in some 
hist_entry
+* instances, so just move them to a separate list.
+*/
+   list_add_tail(>node, >dead_threads);
+}
+
 int machine__process_exit_event(struct machine *machine, union perf_event 
*event)
 {
struct thread *thread = machine__find_thread(machine, event->fork.tid);
@@ -1039,17 +1050,6 @@ int machine__process_event(struct machine *machine, 
union perf_event *event)
return ret;
 }
 
-void machine__remove_thread(struct machine *machine, struct thread *th)
-{
-   machine->last_match = NULL;
-   rb_erase(>rb_node, >threads);
-   /*
-* We may have references to this thread, for instance in some 
hist_entry
-* instances, so just move them to a separate list.
-*/
-   list_add_tail(>node, >dead_threads);
-}
-
 static bool symbol__match_parent_regex(struct symbol *sym)
 {
if (sym->name && !regexec(_regex, sym->name, 0, NULL, 0))
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 5ac5892..e0b2c00 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -97,7 +97,6 @@ static inline bool machine__is_host(struct machine *machine)
 }
 
 struct thread *machine__findnew_thread(struct machine *machine, pid_t pid);
-void machine__remove_thread(struct machine *machine, struct thread *th);
 
 size_t machine__fprintf(struct machine *machine, FILE *fp);
 
-- 
1.7.10.1

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

[PATCH 2/4] perf: remove unused print_trace_event function

[David Ahern]

Signed-off-by: David Ahern 
---
 tools/perf/util/trace-event-parse.c |   13 -
 tools/perf/util/trace-event.h   |1 -
 2 files changed, 14 deletions(-)

diff --git a/tools/perf/util/trace-event-parse.c 
b/tools/perf/util/trace-event-parse.c
index 8450bec..4454835 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -183,19 +183,6 @@ void event_format__print(struct event_format *event,
trace_seq_do_printf();
 }
 
-void print_trace_event(struct pevent *pevent, int cpu, void *data, int size)
-{
-   int type = trace_parse_common_type(pevent, data);
-   struct event_format *event = pevent_find_event(pevent, type);
-
-   if (!event) {
-   warning("ug! no event found for type %d", type);
-   return;
-   }
-
-   event_format__print(event, cpu, data, size);
-}
-
 void parse_proc_kallsyms(struct pevent *pevent,
 char *file, unsigned int size __maybe_unused)
 {
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index 99f621f..28ccde8 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -30,7 +30,6 @@ enum {
 int bigendian(void);
 
 struct pevent *read_trace_init(int file_bigendian, int host_bigendian);
-void print_trace_event(struct pevent *pevent, int cpu, void *data, int size);
 void event_format__print(struct event_format *event,
 int cpu, void *data, int size);
 
-- 
1.7.10.1

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

[PATCH 6/6] KVM: MMU: fast zap all shadow pages

[Xiao Guangrong]

The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse if guest uses more memory or vcpus. It is not good for
scalability.

Since all shadow page will be zapped, we can directly zap the mmu-cache
and rmap so that vcpu will fault on the new mmu-cache, after that, we can
directly free the memory used by old mmu-cache.

The root shadow page is little especial since they are currently used by
vcpus, we can not directly free them. So, we zap the root shadow pages and
re-add them into the new mmu-cache.

After this patch, kvm_mmu_zap_all can be faster 113% than before

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |   62 ++-
 1 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index e326099..536d9ce 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4186,18 +4186,68 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm, 
int slot)

 void kvm_mmu_zap_all(struct kvm *kvm)
 {
-   struct kvm_mmu_page *sp, *node;
+   LIST_HEAD(root_mmu_pages);
LIST_HEAD(invalid_list);
+   struct list_head pte_list_descs;
+   struct kvm_mmu_cache *cache = >arch.mmu_cache;
+   struct kvm_mmu_page *sp, *node;
+   struct pte_list_desc *desc, *ndesc;
+   int root_sp = 0;

spin_lock(>mmu_lock);
+
 restart:
-   list_for_each_entry_safe(sp, node,
- >arch.mmu_cache.active_mmu_pages, link)
-   if (kvm_mmu_prepare_zap_page(kvm, sp, _list))
-   goto restart;
+   /*
+* The root shadow pages are being used on vcpus that can not
+* directly removed, we filter them out and re-add them to the
+* new mmu cache.
+*/
+   list_for_each_entry_safe(sp, node, >active_mmu_pages, link)
+   if (sp->root_count) {
+   int ret;
+
+   root_sp++;
+   ret = kvm_mmu_prepare_zap_page(kvm, sp, _list);
+   list_move(>link, _mmu_pages);
+   if (ret)
+   goto restart;
+   }
+
+   list_splice(>active_mmu_pages, _list);
+   list_replace(>pte_list_descs, _list_descs);
+
+   /*
+* Reset the mmu cache so that later vcpu will fault on the new
+* mmu cache.
+*/
+   memset(cache, 0, sizeof(*cache));
+   kvm_mmu_init(kvm);
+
+   /*
+* Now, the mmu cache has been reset, we can re-add the root shadow
+* pages into the cache.
+*/
+   list_replace(_mmu_pages, >active_mmu_pages);
+   kvm_mod_used_mmu_pages(kvm, root_sp);
+
+   /* Reset gfn's rmap and lpage info. */
+   kvm_clear_all_gfn_page_info(kvm);
+
+   /*
+* Flush all TLBs so that vcpu can not use the invalid mappings.
+* Do not disturb vcpus if root shadow pages have been zapped
+* since KVM_REQ_MMU_RELOAD will force TLB to be flushed.
+*/
+   if (!root_sp && !list_empty(_list))
+   kvm_flush_remote_tlbs(kvm);

-   kvm_mmu_commit_zap_page(kvm, _list);
spin_unlock(>mmu_lock);
+
+   list_for_each_entry_safe(sp, node, _list, link)
+   kvm_mmu_free_page(sp);
+
+   list_for_each_entry_safe(desc, ndesc, _list_descs, list)
+   mmu_free_pte_list_desc(desc);
 }

 static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc)
-- 
1.7.7.6

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

[PATCH 5/6] KVM: MMU: delete shadow page from hash list in kvm_mmu_prepare_zap_page

[Xiao Guangrong]

Move deletion shadow page from the hash list from kvm_mmu_commit_zap_page to
kvm_mmu_prepare_zap_page, we that we can free the shadow page out of mmu-lock.

Also, delete the invalid shadow page from the hash list since this page can
not be reused anymore. This makes reset mmu-cache more easier - we do not need
to care all hash entries after reset mmu-cache

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 4152766..e326099 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1469,7 +1469,7 @@ static inline void kvm_mod_used_mmu_pages(struct kvm 
*kvm, int nr)
 static void kvm_mmu_free_page(struct kvm_mmu_page *sp)
 {
ASSERT(is_empty_shadow_page(sp->spt));
-   hlist_del(>hash_link);
+
list_del(>link);
free_page((unsigned long)sp->spt);
if (!sp->role.direct)
@@ -1658,7 +1658,8 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,

 #define for_each_gfn_indirect_valid_sp(_kvm, _sp, _gfn)
\
for_each_gfn_sp(_kvm, _sp, _gfn)\
-   if ((_sp)->role.direct || (_sp)->role.invalid) {} else
+   if ((_sp)->role.direct ||   \
+ ((_sp)->role.invalid && WARN_ON(1))) {} else

 /* @sp->gfn should be write-protected at the call site */
 static int __kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
@@ -2079,6 +2080,9 @@ static int kvm_mmu_prepare_zap_page(struct kvm *kvm, 
struct kvm_mmu_page *sp,
unaccount_shadowed(kvm, sp->gfn);
if (sp->unsync)
kvm_unlink_unsync_page(kvm, sp);
+
+   hlist_del_init(>hash_link);
+
if (!sp->root_count) {
/* Count self */
ret++;
-- 
1.7.7.6

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

[PATCH 4/6] KVM: x86: introduce kvm_clear_all_gfn_page_info

[Xiao Guangrong]

This function is used to reset the rmaps and page info of all guest page
which will be used in later patch

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/x86.c   |   31 +++
 include/linux/kvm_host.h |1 +
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2cf3722..3cb7685 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6881,6 +6881,37 @@ memslot_set_lpage_disallowed(struct kvm_memory_slot 
*slot,
}
 }

+static void clear_memslot_page_info(struct kvm_memory_slot *slot)
+{
+   int i;
+
+   for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) {
+   int lpages;
+   int level = i + 1;
+
+   lpages = gfn_to_index(slot->base_gfn + slot->npages - 1,
+ slot->base_gfn, level) + 1;
+
+   memset(slot->arch.rmap[i], 0,
+  lpages * sizeof(*slot->arch.rmap[i]));
+
+   if (i) {
+   memset(slot->arch.lpage_info[i - 1], 0,
+  sizeof(*slot->arch.lpage_info[i - 1]));
+   memslot_set_lpage_disallowed(slot, slot->npages, i,
+lpages);
+   }
+   }
+}
+
+void kvm_clear_all_gfn_page_info(struct kvm *kvm)
+{
+   struct kvm_memory_slot *slot;
+
+   kvm_for_each_memslot(slot, kvm->memslots)
+   clear_memslot_page_info(slot);
+}
+
 int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
 {
int i;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9fa13eb..449126f 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -490,6 +490,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
struct kvm_userspace_memory_region *mem);
 void kvm_arch_free_memslot(struct kvm_memory_slot *free,
   struct kvm_memory_slot *dont);
+void kvm_clear_all_gfn_page_info(struct kvm *kvm);
 int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long 
npages);
 int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
-- 
1.7.7.6

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

[PATCH 3/6] KVM: x86: introduce memslot_set_lpage_disallowed

[Xiao Guangrong]

It is used to set disallowed lage page on the specified level, can be
used in later patch

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/x86.c |   53 ++-
 1 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7083568..2cf3722 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6847,12 +6847,45 @@ void kvm_arch_free_memslot(struct kvm_memory_slot *free,
}
 }

+static void
+memslot_set_lpage_disallowed(struct kvm_memory_slot *slot,
+unsigned long npages, int lpage_size,
+int lpages)
+{
+   struct kvm_lpage_info *lpage_info;
+   unsigned long ugfn;
+   int level = lpage_size + 1;
+
+   WARN_ON(!lpage_size);
+
+   lpage_info = slot->arch.lpage_info[lpage_size - 1];
+
+   if (slot->base_gfn & (KVM_PAGES_PER_HPAGE(level) - 1))
+   lpage_info[0].write_count = 1;
+
+   if ((slot->base_gfn + npages) & (KVM_PAGES_PER_HPAGE(level) - 1))
+   lpage_info[lpages - 1].write_count = 1;
+
+   ugfn = slot->userspace_addr >> PAGE_SHIFT;
+   /*
+* If the gfn and userspace address are not aligned wrt each
+* other, or if explicitly asked to, disable large page
+* support for this slot
+*/
+   if ((slot->base_gfn ^ ugfn) & (KVM_PAGES_PER_HPAGE(level) - 1) ||
+ !kvm_largepages_enabled()) {
+   unsigned long j;
+
+   for (j = 0; j < lpages; ++j)
+   lpage_info[j].write_count = 1;
+   }
+}
+
 int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
 {
int i;

for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) {
-   unsigned long ugfn;
int lpages;
int level = i + 1;

@@ -6871,23 +6904,7 @@ int kvm_arch_create_memslot(struct kvm_memory_slot 
*slot, unsigned long npages)
if (!slot->arch.lpage_info[i - 1])
goto out_free;

-   if (slot->base_gfn & (KVM_PAGES_PER_HPAGE(level) - 1))
-   slot->arch.lpage_info[i - 1][0].write_count = 1;
-   if ((slot->base_gfn + npages) & (KVM_PAGES_PER_HPAGE(level) - 
1))
-   slot->arch.lpage_info[i - 1][lpages - 1].write_count = 
1;
-   ugfn = slot->userspace_addr >> PAGE_SHIFT;
-   /*
-* If the gfn and userspace address are not aligned wrt each
-* other, or if explicitly asked to, disable large page
-* support for this slot
-*/
-   if ((slot->base_gfn ^ ugfn) & (KVM_PAGES_PER_HPAGE(level) - 1) 
||
-   !kvm_largepages_enabled()) {
-   unsigned long j;
-
-   for (j = 0; j < lpages; ++j)
-   slot->arch.lpage_info[i - 1][j].write_count = 1;
-   }
+   memslot_set_lpage_disallowed(slot, npages, i, lpages);
}

return 0;
-- 
1.7.7.6

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

Re: [lm-sensors] [PATCH v4] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Guenter Roeck]

On Tue, Mar 12, 2013 at 09:52:26PM -0700, Guenter Roeck wrote:
> On Wed, Mar 13, 2013 at 09:38:20AM +0530, Naveen Krishna Chatradhi wrote:
> > This patch adds DT support to NTC driver to parse the
> > platform data.
> > 
> > Also adds the support to work as an iio device.
> > 
> > During the probe ntc driver gets the respective channels of ADC
> > and uses iio_raw_read calls to get the ADC converted value.
> > 
> > Signed-off-by: Naveen Krishna Chatradhi 
> 
> Unfortunately there is still something we'll need to sort out:
> 
> fs/sysfs/Kconfig:1: symbol SYSFS is selected by AT91_ADC
> drivers/iio/adc/Kconfig:85: symbol AT91_ADC depends on IIO
> drivers/iio/Kconfig:5:  symbol IIO is selected by SENSORS_NTC_THERMISTOR
> drivers/hwmon/Kconfig:900:  symbol SENSORS_NTC_THERMISTOR depends on HWMON
> drivers/hwmon/Kconfig:5:symbol HWMON is selected by EEEPC_LAPTOP
> drivers/platform/x86/Kconfig:477:   symbol EEEPC_LAPTOP depends on
> HOTPLUG_PCI
> drivers/pci/hotplug/Kconfig:5:  symbol HOTPLUG_PCI depends on SYSFS
> 
> So we can not just select IIO. I'll see if I can find a solution.
> 
Here it is:

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index f7adbe8..47d2176 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -899,7 +899,7 @@ config SENSORS_MCP3021

 config SENSORS_NTC_THERMISTOR
 tristate "NTC thermistor support"
-select IIO if OF
+depends on (!OF && !IIO) || (OF && IIO)
 help
This driver supports NTC thermistors sensor reading and its
interpretation. The driver can also monitor the temperature and

I'll modify the patch accordingly. No need to resubmit.

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

[PATCH 2/6] KVM: MMU: introduce mmu_cache->pte_list_descs

[Xiao Guangrong]

This list is used to link all the pte_list_desc used by mmu cache, so
we can easily free the memory used by gfn's rmap and parent spte list

[ The new function name: kvm_mmu_init is vey similar with init_kvm_mmu
  which actually init vcpu mmu, will rename init_kvm_mmu to init_vcpu_mmu ]

Signed-off-by: Xiao Guangrong 
 ---
 arch/x86/include/asm/kvm_host.h |1 +
 arch/x86/kvm/mmu.c  |   14 +-
 arch/x86/kvm/mmu.h  |1 +
 arch/x86/kvm/x86.c  |2 +-
 4 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 85291b08..04d8897 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -535,6 +535,7 @@ struct kvm_mmu_cache {
 * Hash table of struct kvm_mmu_page.
 */
struct list_head active_mmu_pages;
+   struct list_head pte_list_descs;
 };

 struct kvm_arch {
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c52d147..4152766 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -156,6 +156,7 @@ module_param(dbg, bool, 0644);
 struct pte_list_desc {
u64 *sptes[PTE_LIST_EXT];
struct pte_list_desc *more;
+   struct list_head list;
 };

 struct kvm_shadow_walk_iterator {
@@ -701,11 +702,16 @@ static void *mmu_memory_cache_alloc(struct 
kvm_mmu_memory_cache *mc)

 static struct pte_list_desc *mmu_alloc_pte_list_desc(struct kvm_vcpu *vcpu)
 {
-   return mmu_memory_cache_alloc(>arch.mmu_pte_list_desc_cache);
+   struct pte_list_desc *desc;
+
+   desc = mmu_memory_cache_alloc(>arch.mmu_pte_list_desc_cache);
+   list_add(>list, >kvm->arch.mmu_cache.pte_list_descs);
+   return desc;
 }

 static void mmu_free_pte_list_desc(struct pte_list_desc *pte_list_desc)
 {
+   list_del(_list_desc->list);
kmem_cache_free(pte_list_desc_cache, pte_list_desc);
 }

@@ -4320,6 +4326,12 @@ int kvm_mmu_get_spte_hierarchy(struct kvm_vcpu *vcpu, 
u64 addr, u64 sptes[4])
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_get_spte_hierarchy);

+void kvm_mmu_init(struct kvm *kvm)
+{
+   INIT_LIST_HEAD(>arch.mmu_cache.active_mmu_pages);
+   INIT_LIST_HEAD(>arch.mmu_cache.pte_list_descs);
+}
+
 void kvm_mmu_destroy(struct kvm_vcpu *vcpu)
 {
ASSERT(vcpu);
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 2e61c24..76adc5f 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -50,6 +50,7 @@
 #define PFERR_RSVD_MASK (1U << 3)
 #define PFERR_FETCH_MASK (1U << 4)

+void kvm_mmu_init(struct kvm *kvm);
 int kvm_mmu_get_spte_hierarchy(struct kvm_vcpu *vcpu, u64 addr, u64 sptes[4]);
 void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask);
 int handle_mmio_page_fault_common(struct kvm_vcpu *vcpu, u64 addr, bool 
direct);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9cb899c..7083568 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6757,7 +6757,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
if (type)
return -EINVAL;

-   INIT_LIST_HEAD(>arch.mmu_cache.active_mmu_pages);
+   kvm_mmu_init(kvm);
INIT_LIST_HEAD(>arch.assigned_dev_head);

/* Reserve bit 0 of irq_sources_bitmap for userspace irq source */
-- 
1.7.7.6

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

[PATCH 1/6] KVM: MMU: move mmu related members into a separate struct

[Xiao Guangrong]

Move all mmu related members from kvm_arch to a separate struct named
kvm_mmu_cache, so we can easily reset the mmu cache when we zap all shadow
pages

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |6 +-
 arch/x86/kvm/mmu.c  |   36 
 arch/x86/kvm/mmu.h  |4 ++--
 arch/x86/kvm/mmu_audit.c|2 +-
 arch/x86/kvm/x86.c  |   11 ++-
 5 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 635a74d..85291b08 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -525,7 +525,7 @@ struct kvm_apic_map {
struct kvm_lapic *logical_map[16][16];
 };

-struct kvm_arch {
+struct kvm_mmu_cache {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
unsigned int n_max_mmu_pages;
@@ -535,6 +535,10 @@ struct kvm_arch {
 * Hash table of struct kvm_mmu_page.
 */
struct list_head active_mmu_pages;
+};
+
+struct kvm_arch {
+   struct kvm_mmu_cache mmu_cache;
struct list_head assigned_dev_head;
struct iommu_domain *iommu_domain;
int iommu_flags;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index fdacabb..c52d147 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -751,7 +751,7 @@ static void account_shadowed(struct kvm *kvm, gfn_t gfn)
linfo = lpage_info_slot(gfn, slot, i);
linfo->write_count += 1;
}
-   kvm->arch.indirect_shadow_pages++;
+   kvm->arch.mmu_cache.indirect_shadow_pages++;
 }

 static void unaccount_shadowed(struct kvm *kvm, gfn_t gfn)
@@ -767,7 +767,7 @@ static void unaccount_shadowed(struct kvm *kvm, gfn_t gfn)
linfo->write_count -= 1;
WARN_ON(linfo->write_count < 0);
}
-   kvm->arch.indirect_shadow_pages--;
+   kvm->arch.mmu_cache.indirect_shadow_pages--;
 }

 static int has_wrprotected_page(struct kvm *kvm,
@@ -1456,7 +1456,7 @@ static int is_empty_shadow_page(u64 *spt)
  */
 static inline void kvm_mod_used_mmu_pages(struct kvm *kvm, int nr)
 {
-   kvm->arch.n_used_mmu_pages += nr;
+   kvm->arch.mmu_cache.n_used_mmu_pages += nr;
percpu_counter_add(_total_used_mmu_pages, nr);
 }

@@ -1507,7 +1507,7 @@ static struct kvm_mmu_page *kvm_mmu_alloc_page(struct 
kvm_vcpu *vcpu,
if (!direct)
sp->gfns = mmu_memory_cache_alloc(>arch.mmu_page_cache);
set_page_private(virt_to_page(sp->spt), (unsigned long)sp);
-   list_add(>link, >kvm->arch.active_mmu_pages);
+   list_add(>link, >kvm->arch.mmu_cache.active_mmu_pages);
sp->parent_ptes = 0;
mmu_page_add_parent_pte(vcpu, sp, parent_pte);
kvm_mod_used_mmu_pages(vcpu->kvm, +1);
@@ -1646,7 +1646,8 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,

 #define for_each_gfn_sp(_kvm, _sp, _gfn)   \
hlist_for_each_entry(_sp,   \
- &(_kvm)->arch.mmu_page_hash[kvm_page_table_hashfn(_gfn)], hash_link) \
+   &(_kvm)->arch.mmu_cache.mmu_page_hash[kvm_page_table_hashfn(_gfn)],\
+  hash_link)   \
if ((_sp)->gfn != (_gfn)) {} else

 #define for_each_gfn_indirect_valid_sp(_kvm, _sp, _gfn)
\
@@ -1842,6 +1843,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct 
kvm_vcpu *vcpu,
 unsigned access,
 u64 *parent_pte)
 {
+   struct kvm_mmu_cache *cache;
union kvm_mmu_page_role role;
unsigned quadrant;
struct kvm_mmu_page *sp;
@@ -1886,8 +1888,9 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct 
kvm_vcpu *vcpu,
return sp;
sp->gfn = gfn;
sp->role = role;
+   cache = >kvm->arch.mmu_cache;
hlist_add_head(>hash_link,
-   >kvm->arch.mmu_page_hash[kvm_page_table_hashfn(gfn)]);
+  >mmu_page_hash[kvm_page_table_hashfn(gfn)]);
if (!direct) {
if (rmap_write_protect(vcpu->kvm, gfn))
kvm_flush_remote_tlbs(vcpu->kvm);
@@ -2076,7 +2079,7 @@ static int kvm_mmu_prepare_zap_page(struct kvm *kvm, 
struct kvm_mmu_page *sp,
list_move(>link, invalid_list);
kvm_mod_used_mmu_pages(kvm, -1);
} else {
-   list_move(>link, >arch.active_mmu_pages);
+   list_move(>link, >arch.mmu_cache.active_mmu_pages);
kvm_reload_remote_mmus(kvm);
}

@@ -2115,10 +2118,10 @@ static bool prepare_zap_oldest_mmu_page(struct kvm *kvm,
 {
struct kvm_mmu_page *sp;

-   if (list_empty(>arch.active_mmu_pages))
+   if (list_empty(>arch.mmu_cache.active_mmu_pages))
return false;

-   sp = 

linux-next: manual merge of the akpm tree with the rcu tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/rcutree.c between commit 3c62110a0cd6 ("rcu: Tone down debugging
during boot-up and shutdown") from the rcu tree and commit "kernel/:
rename random32() to prandom_u32()" from the akpm tree.

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

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

diff --cc kernel/rcutree.c
index 2d5f94c,2f8530b..000
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@@ -1441,8 -1319,7 +1441,8 @@@ static int rcu_gp_init(struct rcu_stat
rnp->grphi, rnp->qsmask);
raw_spin_unlock_irq(>lock);
  #ifdef CONFIG_PROVE_RCU_DELAY
-   if ((random32() % (rcu_num_nodes * 8)) == 0 &&
 -  if ((prandom_u32() % (rcu_num_nodes * 8)) == 0)
++  if ((prandom_u32() % (rcu_num_nodes * 8)) == 0 &&
 +  system_state == SYSTEM_RUNNING)
schedule_timeout_uninterruptible(2);
  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
cond_resched();


pgp_v9tqYK5t5.pgp
Description: PGP signature

Re: [PATCH v4] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Guenter Roeck]

On Wed, Mar 13, 2013 at 09:38:20AM +0530, Naveen Krishna Chatradhi wrote:
> This patch adds DT support to NTC driver to parse the
> platform data.
> 
> Also adds the support to work as an iio device.
> 
> During the probe ntc driver gets the respective channels of ADC
> and uses iio_raw_read calls to get the ADC converted value.
> 
> Signed-off-by: Naveen Krishna Chatradhi 

Unfortunately there is still something we'll need to sort out:

fs/sysfs/Kconfig:1: symbol SYSFS is selected by AT91_ADC
drivers/iio/adc/Kconfig:85: symbol AT91_ADC depends on IIO
drivers/iio/Kconfig:5:  symbol IIO is selected by SENSORS_NTC_THERMISTOR
drivers/hwmon/Kconfig:900:  symbol SENSORS_NTC_THERMISTOR depends on HWMON
drivers/hwmon/Kconfig:5:symbol HWMON is selected by EEEPC_LAPTOP
drivers/platform/x86/Kconfig:477:   symbol EEEPC_LAPTOP depends on
HOTPLUG_PCI
drivers/pci/hotplug/Kconfig:5:  symbol HOTPLUG_PCI depends on SYSFS

So we can not just select IIO. I'll see if I can find a solution.

Guenter

> ---
> Changes since v3:
> 1. Added a NULL check before iio_channel_release
> 2. Modified a return statement
> 
> Guenter Roeck, Its wonderful working with you. Thanks.
> 
>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   29 
>  drivers/hwmon/Kconfig  |1 +
>  drivers/hwmon/ntc_thermistor.c |  145 
> +---
>  include/linux/platform_data/ntc_thermistor.h   |8 +-
>  4 files changed, 163 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> new file mode 100644
> index 000..c6f6667
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> @@ -0,0 +1,29 @@
> +NTC Thermistor hwmon sensors
> +---
> +
> +Requires node properties:
> +- "compatible" value : one of
> + "ntc,ncp15wb473"
> + "ntc,ncp18wb473"
> + "ntc,ncp21wb473"
> + "ntc,ncp03wb473"
> + "ntc,ncp15wl333"
> +- "pullup-uv"Pull up voltage in micro volts
> +- "pullup-ohm"   Pull up resistor value in ohms
> +- "pulldown-ohm" Pull down resistor value in ohms
> +- "connected-positive" Always ON, If not specified.
> + Status change is possible.
> +- "io-channels"  Channel node of ADC to be used for
> + conversion.
> +
> +Read more about iio bindings at
> + Documentation/devicetree/bindings/iio/iio-bindings.txt
> +
> +Example:
> + ncp15wb473@0 {
> + compatible = "ntc,ncp15wb473";
> + pullup-uv = <180>;
> + pullup-ohm = <47000>;
> + pulldown-ohm = <0>;
> + io-channels = < 3>;
> + };
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..cc47c12 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -879,6 +879,7 @@ config SENSORS_MCP3021
>  
>  config SENSORS_NTC_THERMISTOR
>   tristate "NTC thermistor support"
> + select IIO if OF
>   help
> This driver supports NTC thermistors sensor reading and its
> interpretation. The driver can also monitor the temperature and
> diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
> index b5f63f9..a6997a1 100644
> --- a/drivers/hwmon/ntc_thermistor.c
> +++ b/drivers/hwmon/ntc_thermistor.c
> @@ -26,9 +26,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -37,6 +44,15 @@ struct ntc_compensation {
>   unsigned intohm;
>  };
>  
> +static const struct platform_device_id ntc_thermistor_id[] = {
> + { "ncp15wb473", TYPE_NCPXXWB473 },
> + { "ncp18wb473", TYPE_NCPXXWB473 },
> + { "ncp21wb473", TYPE_NCPXXWB473 },
> + { "ncp03wb473", TYPE_NCPXXWB473 },
> + { "ncp15wl333", TYPE_NCPXXWL333 },
> + { },
> +};
> +
>  /*
>   * A compensation table should be sorted by the values of .ohm
>   * in descending order.
> @@ -125,6 +141,92 @@ struct ntc_data {
>   char name[PLATFORM_NAME_SIZE];
>  };
>  
> +#ifdef CONFIG_OF
> +static int ntc_adc_iio_read(struct ntc_thermistor_platform_data *pdata)
> +{
> + struct iio_channel *channel = pdata->chan;
> + unsigned int result;
> + int val, ret;
> +
> + ret = iio_read_channel_raw(channel, );
> + if (ret < 0) {
> + pr_err("read channel() error: %d\n", ret);
> + return ret;
> + }
> +
> + /* unit: mV */
> + result = pdata->pullup_uV * val;
> + result >>= 12;
> +
> + return result;
> +}
> +
> +static const struct of_device_id ntc_match[] = {
> + { .compatible = "ntc,ncp15wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp18wb473",
> + .data = 

[PATCH v3] iio: adc: exynos5_adc: fix compilation warnings

[Naveen Krishna Chatradhi]

Fixes the compilation warnings and potential NULL pointer
dereferencing pointed out by "Dan Carpenter".

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Jonathan Cameron 
Cc: Lars-Peter Clausen 
Series-To: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
To: Dan Carpenter 
---
Changes since v2:
1. Timeout should be long not int
2. Remove unnecessary variable version, use ret instead.

Apologize me for top posting.

Doug, There was a comment from Lars regarding the match not
being NULL, if driver depends on CONFIG_OF. So, i've removed
the NULL check in v2 of this patch.
https://patchwork.kernel.org/patch/841/

I'm checking the return value of get_version() for -ve values before
assigning to info->version. So, i left the (unsigned int) unchanged.

If required, I will resubmit with both these comments addressed.

 drivers/iio/adc/Kconfig  |1 +
 drivers/iio/adc/exynos_adc.c |   18 --
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 04311f8..da67626 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -93,6 +93,7 @@ config AT91_ADC
 
 config EXYNOS_ADC
bool "Exynos ADC driver support"
+   depends on OF
help
  Core support for the ADC block found in the Samsung EXYNOS series
  of SoCs for drivers such as the touchscreen and hwmon to use to share
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ed6fdd7..2d41bb5 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -92,7 +92,7 @@ struct exynos_adc {
struct completion   completion;
 
u32 value;
-   unsigned intversion;
+   unsigned intversion;
 };
 
 static const struct of_device_id exynos_adc_match[] = {
@@ -102,12 +102,12 @@ static const struct of_device_id exynos_adc_match[] = {
 };
 MODULE_DEVICE_TABLE(of, exynos_adc_match);
 
-static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
+static inline int exynos_adc_get_version(struct platform_device *pdev)
 {
const struct of_device_id *match;
 
match = of_match_node(exynos_adc_match, pdev->dev.of_node);
-   return (unsigned int)match->data;
+   return (int)match->data;
 }
 
 static int exynos_read_raw(struct iio_dev *indio_dev,
@@ -117,7 +117,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
long mask)
 {
struct exynos_adc *info = iio_priv(indio_dev);
-   unsigned long timeout;
+   long timeout;
u32 con1, con2;
 
if (mask != IIO_CHAN_INFO_RAW)
@@ -268,6 +268,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
 
info = iio_priv(indio_dev);
 
+   ret = exynos_adc_get_version(pdev);
+   if (ret < 0) {
+   dev_err(>dev, "no matching of_node, err = %d\n", ret);
+   goto err_iio;
+   }
+
+   info->version = ret;
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
info->regs = devm_request_and_ioremap(>dev, mem);
@@ -311,8 +319,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
 
-   info->version = exynos_adc_get_version(pdev);
-
platform_set_drvdata(pdev, indio_dev);
 
indio_dev->name = dev_name(>dev);
-- 
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/

linux-next: manual merge of the akpm tree with the workqueues tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/workqueue.c between commit fa1b54e69bc6 ("workqueue: update
synchronization rules on worker_pool_idr") from the workqueues tree and
commit "workqueue: convert to idr_alloc()" from the akpm tree.

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

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

diff --cc kernel/workqueue.c
index 2f43753,09bee1d..000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -456,31 -456,40 +456,31 @@@ static int worker_pool_assign_id(struc
  {
int ret;
  
 -  mutex_lock(_pool_idr_mutex);
 -  ret = idr_alloc(_pool_idr, pool, 0, 0, GFP_KERNEL);
 -  if (ret >= 0)
 -  pool->id = ret;
 -  mutex_unlock(_pool_idr_mutex);
 +  do {
-   if (!idr_pre_get(_pool_idr, GFP_KERNEL))
-   return -ENOMEM;
- 
++  idr_preload(GFP_KERNEL);
 +  spin_lock_irq(_lock);
-   ret = idr_get_new(_pool_idr, pool, >id);
++  ret = idr_alloc(_pool_idr, pool, 0, 0, GFP_NOWAIT);
++  if (ret >= 0)
++  pool->id = ret;
 +  spin_unlock_irq(_lock);
 +  } while (ret == -EAGAIN);
  
-   return ret;
+   return ret < 0 ? ret : 0;
  }
  
 -/*
 - * Lookup worker_pool by id.  The idr currently is built during boot and
 - * never modified.  Don't worry about locking for now.
 +/**
 + * first_pwq - return the first pool_workqueue of the specified workqueue
 + * @wq: the target workqueue
 + *
 + * This must be called either with workqueue_lock held or sched RCU read
 + * locked.  If the pwq needs to be used beyond the locking in effect, the
 + * caller is responsible for guaranteeing that the pwq stays online.
   */
 -static struct worker_pool *worker_pool_by_id(int pool_id)
 -{
 -  return idr_find(_pool_idr, pool_id);
 -}
 -
 -static struct worker_pool *get_std_worker_pool(int cpu, bool highpri)
 -{
 -  struct worker_pool *pools = std_worker_pools(cpu);
 -
 -  return [highpri];
 -}
 -
 -static struct pool_workqueue *get_pwq(unsigned int cpu,
 -struct workqueue_struct *wq)
 +static struct pool_workqueue *first_pwq(struct workqueue_struct *wq)
  {
 -  if (!(wq->flags & WQ_UNBOUND)) {
 -  if (likely(cpu < nr_cpu_ids))
 -  return per_cpu_ptr(wq->pool_wq.pcpu, cpu);
 -  } else if (likely(cpu == WORK_CPU_UNBOUND))
 -  return wq->pool_wq.single;
 -  return NULL;
 +  assert_rcu_or_wq_lock();
 +  return list_first_or_null_rcu(>pwqs, struct pool_workqueue,
 +pwqs_node);
  }
  
  static unsigned int work_color_to_flags(int color)


pgp0TEBK9bghS.pgp
Description: PGP signature

Re: [PATCH v4] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Guenter Roeck]

On Wed, Mar 13, 2013 at 09:38:20AM +0530, Naveen Krishna Chatradhi wrote:
> This patch adds DT support to NTC driver to parse the
> platform data.
> 
> Also adds the support to work as an iio device.
> 
> During the probe ntc driver gets the respective channels of ADC
> and uses iio_raw_read calls to get the ADC converted value.
> 
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> Changes since v3:
> 1. Added a NULL check before iio_channel_release
> 2. Modified a return statement
> 
> Guenter Roeck, Its wonderful working with you. Thanks.
> 
My pleasure.

Patch looks ok to me now. I'll wait a couple of days to see if there is some
feedback from the devicetree folks. Unless there are objections, I'll then queue
it for 3.10.

Thanks,
Guenter

>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   29 
>  drivers/hwmon/Kconfig  |1 +
>  drivers/hwmon/ntc_thermistor.c |  145 
> +---
>  include/linux/platform_data/ntc_thermistor.h   |8 +-
>  4 files changed, 163 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> new file mode 100644
> index 000..c6f6667
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> @@ -0,0 +1,29 @@
> +NTC Thermistor hwmon sensors
> +---
> +
> +Requires node properties:
> +- "compatible" value : one of
> + "ntc,ncp15wb473"
> + "ntc,ncp18wb473"
> + "ntc,ncp21wb473"
> + "ntc,ncp03wb473"
> + "ntc,ncp15wl333"
> +- "pullup-uv"Pull up voltage in micro volts
> +- "pullup-ohm"   Pull up resistor value in ohms
> +- "pulldown-ohm" Pull down resistor value in ohms
> +- "connected-positive" Always ON, If not specified.
> + Status change is possible.
> +- "io-channels"  Channel node of ADC to be used for
> + conversion.
> +
> +Read more about iio bindings at
> + Documentation/devicetree/bindings/iio/iio-bindings.txt
> +
> +Example:
> + ncp15wb473@0 {
> + compatible = "ntc,ncp15wb473";
> + pullup-uv = <180>;
> + pullup-ohm = <47000>;
> + pulldown-ohm = <0>;
> + io-channels = < 3>;
> + };
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..cc47c12 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -879,6 +879,7 @@ config SENSORS_MCP3021
>  
>  config SENSORS_NTC_THERMISTOR
>   tristate "NTC thermistor support"
> + select IIO if OF
>   help
> This driver supports NTC thermistors sensor reading and its
> interpretation. The driver can also monitor the temperature and
> diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
> index b5f63f9..a6997a1 100644
> --- a/drivers/hwmon/ntc_thermistor.c
> +++ b/drivers/hwmon/ntc_thermistor.c
> @@ -26,9 +26,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -37,6 +44,15 @@ struct ntc_compensation {
>   unsigned intohm;
>  };
>  
> +static const struct platform_device_id ntc_thermistor_id[] = {
> + { "ncp15wb473", TYPE_NCPXXWB473 },
> + { "ncp18wb473", TYPE_NCPXXWB473 },
> + { "ncp21wb473", TYPE_NCPXXWB473 },
> + { "ncp03wb473", TYPE_NCPXXWB473 },
> + { "ncp15wl333", TYPE_NCPXXWL333 },
> + { },
> +};
> +
>  /*
>   * A compensation table should be sorted by the values of .ohm
>   * in descending order.
> @@ -125,6 +141,92 @@ struct ntc_data {
>   char name[PLATFORM_NAME_SIZE];
>  };
>  
> +#ifdef CONFIG_OF
> +static int ntc_adc_iio_read(struct ntc_thermistor_platform_data *pdata)
> +{
> + struct iio_channel *channel = pdata->chan;
> + unsigned int result;
> + int val, ret;
> +
> + ret = iio_read_channel_raw(channel, );
> + if (ret < 0) {
> + pr_err("read channel() error: %d\n", ret);
> + return ret;
> + }
> +
> + /* unit: mV */
> + result = pdata->pullup_uV * val;
> + result >>= 12;
> +
> + return result;
> +}
> +
> +static const struct of_device_id ntc_match[] = {
> + { .compatible = "ntc,ncp15wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp18wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp21wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp03wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp15wl333",
> + .data = _thermistor_id[TYPE_NCPXXWL333] },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, ntc_match);
> +
> +static struct ntc_thermistor_platform_data *

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Stephen Warren]

On 03/12/2013 07:47 PM, Bill Huang wrote:
> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
>> On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
>>> Add the below four notifier events so drivers which are interested in
>>> knowing the clock status can act accordingly. This is extremely useful
>>> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
>>>
>>> PRE_CLK_ENABLE
>>> POST_CLK_ENABLE
>>> PRE_CLK_DISABLE
>>> POST_CLK_DISABLE
>>>
>>> Signed-off-by: Bill Huang 
>>
>> NAK.  *Sigh* NO, this is the wrong level to be doing stuff like this.
>>
>> The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should
>> *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and
>> clk_unprepare().  Those two functions are *merely* helpers for drivers
>> who don't wish to make the individual calls.
>>
>> Drivers are still completely free to call the individual functions, at
>> which point your proposal breaks horribly - and they _do_ call the
>> individual functions.
>
> I'm proposing to give device driver a choice when it knows that some
> driver might be interested in knowing its clock's enabled/disabled state
> change at runtime, this is very important for centralized DVFS core
> driver. It is not meant to be covering all cases especially for drivers
> which is not part of the DVFS, so we don't care if it is calling
> clk_enable/disable directly or not.

I believe the point Russell is making is not that the idea behind this
patch is wrong, but simply that the function where you put the hooks is
wrong. The hooks should at least be in clk_enable/clk_disable and not
clk_prepare_enable/clk_disable_unprepare, since any driver is free to
call clk_prepare separately from clk_enable. The hooks should be
implemented in the lowest-level common function that all
driver-accessible paths call through.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 000/100] 3.8.3-stable review

[Greg Kroah-Hartman]

On Tue, Mar 12, 2013 at 09:56:04PM -0600, Shuah Khan wrote:
> On Tue, Mar 12, 2013 at 4:30 PM, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 3.8.3 release.
> > There are 100 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Mar 14 22:30:28 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.3-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Patches applied cleanly to 3.0.68, 3.4.35, and 3.8.2
> 
> Compiled and booted on the following systems:

Thanks for testing and letting us know.

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

[PATCH v4] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Naveen Krishna Chatradhi]

This patch adds DT support to NTC driver to parse the
platform data.

Also adds the support to work as an iio device.

During the probe ntc driver gets the respective channels of ADC
and uses iio_raw_read calls to get the ADC converted value.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v3:
1. Added a NULL check before iio_channel_release
2. Modified a return statement

Guenter Roeck, Its wonderful working with you. Thanks.

 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   29 
 drivers/hwmon/Kconfig  |1 +
 drivers/hwmon/ntc_thermistor.c |  145 +---
 include/linux/platform_data/ntc_thermistor.h   |8 +-
 4 files changed, 163 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt

diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
new file mode 100644
index 000..c6f6667
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -0,0 +1,29 @@
+NTC Thermistor hwmon sensors
+---
+
+Requires node properties:
+- "compatible" value : one of
+   "ntc,ncp15wb473"
+   "ntc,ncp18wb473"
+   "ntc,ncp21wb473"
+   "ntc,ncp03wb473"
+   "ntc,ncp15wl333"
+- "pullup-uv"  Pull up voltage in micro volts
+- "pullup-ohm" Pull up resistor value in ohms
+- "pulldown-ohm" Pull down resistor value in ohms
+- "connected-positive" Always ON, If not specified.
+   Status change is possible.
+- "io-channels"Channel node of ADC to be used for
+   conversion.
+
+Read more about iio bindings at
+   Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Example:
+   ncp15wb473@0 {
+   compatible = "ntc,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = < 3>;
+   };
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 89ac1cb..cc47c12 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -879,6 +879,7 @@ config SENSORS_MCP3021
 
 config SENSORS_NTC_THERMISTOR
tristate "NTC thermistor support"
+   select IIO if OF
help
  This driver supports NTC thermistors sensor reading and its
  interpretation. The driver can also monitor the temperature and
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index b5f63f9..a6997a1 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -26,9 +26,16 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 
@@ -37,6 +44,15 @@ struct ntc_compensation {
unsigned intohm;
 };
 
+static const struct platform_device_id ntc_thermistor_id[] = {
+   { "ncp15wb473", TYPE_NCPXXWB473 },
+   { "ncp18wb473", TYPE_NCPXXWB473 },
+   { "ncp21wb473", TYPE_NCPXXWB473 },
+   { "ncp03wb473", TYPE_NCPXXWB473 },
+   { "ncp15wl333", TYPE_NCPXXWL333 },
+   { },
+};
+
 /*
  * A compensation table should be sorted by the values of .ohm
  * in descending order.
@@ -125,6 +141,92 @@ struct ntc_data {
char name[PLATFORM_NAME_SIZE];
 };
 
+#ifdef CONFIG_OF
+static int ntc_adc_iio_read(struct ntc_thermistor_platform_data *pdata)
+{
+   struct iio_channel *channel = pdata->chan;
+   unsigned int result;
+   int val, ret;
+
+   ret = iio_read_channel_raw(channel, );
+   if (ret < 0) {
+   pr_err("read channel() error: %d\n", ret);
+   return ret;
+   }
+
+   /* unit: mV */
+   result = pdata->pullup_uV * val;
+   result >>= 12;
+
+   return result;
+}
+
+static const struct of_device_id ntc_match[] = {
+   { .compatible = "ntc,ncp15wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp18wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp21wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp03wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp15wl333",
+   .data = _thermistor_id[TYPE_NCPXXWL333] },
+   { },
+};
+MODULE_DEVICE_TABLE(of, ntc_match);
+
+static struct ntc_thermistor_platform_data *
+ntc_thermistor_parse_dt(struct platform_device *pdev)
+{
+   struct iio_channel *chan;
+   struct device_node *np = pdev->dev.of_node;
+   struct ntc_thermistor_platform_data *pdata;
+
+   if (!np)
+   return NULL;
+
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
+
+   chan = iio_channel_get(>dev, NULL);
+   if (IS_ERR(chan))
+   return 

Re: [PATCH] bounce:fix bug, avoid to flush dcache on slab page from jbd2.

[Andrew Morton]

On Wed, 13 Mar 2013 11:35:15 +0800 Shuge  wrote:

> Hi all
> >>> The bounce accept slab pages from jbd2, and flush dcache on them.
> >>> When enabling VM_DEBUG, it will tigger VM_BUG_ON in page_mapping().
> >>> So, check PageSlab to avoid it in __blk_queue_bounce().
> >>>
> >>> Bug URL: http://lkml.org/lkml/2013/3/7/56
> >>>
> >>> ...
> >>>
> >> ..
> >>
> > That sure is strange.  I didn't see any obvious reasons why we'd end up 
> > with a
> >
> ..
> 
>  Well, this problem not only appear in arm64, but also arm32. And my 
> kernel version is 3.3.0, arch is arm32.
> Following the newest kernel, the problem shoulde be exist.
>  I agree with Darrick's modification. Hum, if 
> CONFIG_NEED_BOUNCE_POOL is not set, it also flush dcahce on
> the pages of b_frozen_data, some of them are allocated by kmem_cache_alloc.
>  As we know, jbd2_alloc allocate a buffer from jbd2_xk slab pool, 
> when the size is smaller than PAGE_SIZE.
> The b_frozen_data  is not mapped to usrspace, not aliasing cache. It cat 
> be lazy flush or other. Is it right?

Please reread my email.  The page at b_frozen_data was allocated with
GFP_NOFS.  Hence it should not need bounce treatment (if arm is
anything like x86).

And yet it *did* receive bounce treatment.  Why?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hw_random: mxc-rnga: Use devm_ioremap_resource()

[Fabio Estevam]

From: Fabio Estevam 

Using devm_ioremap_resource() can make the code cleaner and simpler.

Signed-off-by: Fabio Estevam 
---
 drivers/char/hw_random/mxc-rnga.c |   21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/char/hw_random/mxc-rnga.c 
b/drivers/char/hw_random/mxc-rnga.c
index f05d857..93fc741 100644
--- a/drivers/char/hw_random/mxc-rnga.c
+++ b/drivers/char/hw_random/mxc-rnga.c
@@ -142,7 +142,7 @@ static void mxc_rnga_cleanup(struct hwrng *rng)
 static int __init mxc_rnga_probe(struct platform_device *pdev)
 {
int err = -ENODEV;
-   struct resource *res, *mem;
+   struct resource *res;
struct mxc_rng *mxc_rng;
 
mxc_rng = devm_kzalloc(>dev, sizeof(struct mxc_rng),
@@ -172,15 +172,9 @@ static int __init mxc_rnga_probe(struct platform_device 
*pdev)
goto err_region;
}
 
-   mem = request_mem_region(res->start, resource_size(res), pdev->name);
-   if (mem == NULL) {
-   err = -EBUSY;
-   goto err_region;
-   }
-
-   mxc_rng->mem = ioremap(res->start, resource_size(res));
-   if (!mxc_rng->mem) {
-   err = -ENOMEM;
+   mxc_rng->mem = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(mxc_rng->mem)) {
+   err = PTR_ERR(mxc_rng->mem);
goto err_ioremap;
}
 
@@ -195,8 +189,6 @@ static int __init mxc_rnga_probe(struct platform_device 
*pdev)
return 0;
 
 err_ioremap:
-   release_mem_region(res->start, resource_size(res));
-
 err_region:
clk_disable_unprepare(mxc_rng->clk);
 
@@ -206,15 +198,10 @@ out:
 
 static int __exit mxc_rnga_remove(struct platform_device *pdev)
 {
-   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct mxc_rng *mxc_rng = platform_get_drvdata(pdev);
 
hwrng_unregister(_rng->rng);
 
-   iounmap(mxc_rng->mem);
-
-   release_mem_region(res->start, resource_size(res));
-
clk_disable_unprepare(mxc_rng->clk);
 
return 0;
-- 
1.7.9.5

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

Re: [ 00/40] 3.4.36-stable review

[Shuah Khan]

On Tue, Mar 12, 2013 at 4:43 PM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 3.4.36 release.
> There are 40 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Mar 14 22:31:37 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.36-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Patches applied cleanly to 3.0.68, 3.4.35, and 3.8.2

Compiled and booted on the following systems:

HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

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

Re: [ 00/21] 3.0.69-stable review

[Shuah Khan]

On Tue, Mar 12, 2013 at 4:44 PM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 3.0.69 release.
> There are 21 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Mar 14 22:32:21 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.69-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Patches applied cleanly to 3.0.68, 3.4.35, and 3.8.2

Compiled and booted on the following systems:

HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

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

[Shuah Khan]

On Tue, Mar 12, 2013 at 4:30 PM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 3.8.3 release.
> There are 100 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Mar 14 22:30:28 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.3-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Patches applied cleanly to 3.0.68, 3.4.35, and 3.8.2

Compiled and booted on the following systems:

HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/14] mailbox: rename pl320-ipc specific mailbox.h

[Greg Kroah-Hartman]

On Tue, Mar 12, 2013 at 10:23:50PM -0500, Suman Anna wrote:
> The patch 30058677 "ARM / highbank: add support for pl320 IPC"
> added a pl320 IPC specific header file as a generic mailbox.h.
> This file has been renamed appropriately to allow the
> introduction of the generic mailbox API framework.
> 
> Signed-off-by: Suman Anna 
> Cc: Mark Langsdorf 
> Cc: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/highbank-cpufreq.c |  2 +-
>  drivers/mailbox/pl320-ipc.c|  2 +-
>  include/linux/mailbox.h| 17 -
>  include/linux/pl320-ipc.h  | 17 +
>  4 files changed, 19 insertions(+), 19 deletions(-)
>  delete mode 100644 include/linux/mailbox.h
>  create mode 100644 include/linux/pl320-ipc.h

Why are you sending these To: me?  I'm not the mailbox maintainer, and
have never handled them before that I can remember.  Who is the
maintainer?

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] bounce:fix bug, avoid to flush dcache on slab page from jbd2.

[Shuge]

Hi all

The bounce accept slab pages from jbd2, and flush dcache on them.
When enabling VM_DEBUG, it will tigger VM_BUG_ON in page_mapping().
So, check PageSlab to avoid it in __blk_queue_bounce().

Bug URL: http://lkml.org/lkml/2013/3/7/56

...


..


That sure is strange.  I didn't see any obvious reasons why we'd end up with a


..

Well, this problem not only appear in arm64, but also arm32. And my 
kernel version is 3.3.0, arch is arm32.

Following the newest kernel, the problem shoulde be exist.
I agree with Darrick's modification. Hum, if 
CONFIG_NEED_BOUNCE_POOL is not set, it also flush dcahce on

the pages of b_frozen_data, some of them are allocated by kmem_cache_alloc.
As we know, jbd2_alloc allocate a buffer from jbd2_xk slab pool, 
when the size is smaller than PAGE_SIZE.
The b_frozen_data  is not mapped to usrspace, not aliasing cache. It cat 
be lazy flush or other. Is it right?


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

[PATCHv3 02/14] ARM: OMAP2+: mbox: remove dependencies with soc.h

[Suman Anna]

The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.

The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of mailbox devices and register with the
mailbox driver. This data is now represented in a concise format
and moved to the respective omap_hwmod data files and published
to the driver through the platform data.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/devices.c  |   9 +-
 arch/arm/mach-omap2/mailbox.c  | 240 ++---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  12 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  11 ++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  11 ++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  13 ++
 arch/arm/plat-omap/include/plat/mailbox.h  |   2 +-
 include/linux/platform_data/mailbox-omap.h |  53 +++
 8 files changed, 190 insertions(+), 161 deletions(-)
 create mode 100644 include/linux/platform_data/mailbox-omap.h

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1ec7f05..039f6d7 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -332,14 +333,20 @@ static inline void __init omap_init_mbox(void)
 {
struct omap_hwmod *oh;
struct platform_device *pdev;
+   struct omap_mbox_pdata *pdata;
 
oh = omap_hwmod_lookup("mailbox");
if (!oh) {
pr_err("%s: unable to find hwmod\n", __func__);
return;
}
+   if (!oh->dev_attr) {
+   pr_err("%s: hwmod doesn't have valid attrs\n", __func__);
+   return;
+   }
 
-   pdev = omap_device_build("omap-mailbox", -1, oh, NULL, 0);
+   pdata = (struct omap_mbox_pdata *)oh->dev_attr;
+   pdev = omap_device_build("omap-mailbox", -1, oh, pdata, sizeof(*pdata));
WARN(IS_ERR(pdev), "%s: could not build device, err %ld\n",
__func__, PTR_ERR(pdev));
 }
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0b08026..8f5bcd8 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -11,16 +11,16 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-#include "soc.h"
-
 #define MAILBOX_REVISION   0x000
 #define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
 #define MAILBOX_FIFOSTATUS(m)  (0x080 + 4 * (m))
@@ -59,6 +59,7 @@ struct omap_mbox2_priv {
u32 notfull_bit;
u32 ctx[OMAP4_MBOX_NR_REGS];
unsigned long irqdisable;
+   u32 intr_type;
 };
 
 static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
@@ -141,7 +142,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
struct omap_mbox2_priv *p = mbox->priv;
u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
 
-   if (!cpu_is_omap44xx())
+   if (!p->intr_type)
bit = mbox_read_reg(p->irqdisable) & ~bit;
 
mbox_write_reg(bit, p->irqdisable);
@@ -175,7 +176,8 @@ static void omap2_mbox_save_ctx(struct omap_mbox *mbox)
int i;
struct omap_mbox2_priv *p = mbox->priv;
int nr_regs;
-   if (cpu_is_omap44xx())
+
+   if (p->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
else
nr_regs = MBOX_NR_REGS;
@@ -192,7 +194,8 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
int i;
struct omap_mbox2_priv *p = mbox->priv;
int nr_regs;
-   if (cpu_is_omap44xx())
+
+   if (p->intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
else
nr_regs = MBOX_NR_REGS;
@@ -220,185 +223,104 @@ static struct omap_mbox_ops omap2_mbox_ops = {
.restore_ctx= omap2_mbox_restore_ctx,
 };
 
-/*
- * MAILBOX 0: ARM -> DSP,
- * MAILBOX 1: ARM <- DSP.
- * MAILBOX 2: ARM -> IVA,
- * MAILBOX 3: ARM <- IVA.
- */
-
-/* FIXME: the following structs should be filled automatically by the user id 
*/
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
-/* DSP */
-static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
-   .tx_fifo = {
-   .msg= MAILBOX_MESSAGE(0),
-   .fifo_stat  = MAILBOX_FIFOSTATUS(0),
-   },
-   .rx_fifo = {
-   .msg= MAILBOX_MESSAGE(1),
-   .msg_stat   = MAILBOX_MSGSTATUS(1),
-   },
-   .irqenable  = MAILBOX_IRQENABLE(0),
-   .irqstatus  = MAILBOX_IRQSTATUS(0),
-   .notfull_bit= MAILBOX_IRQ_NOTFULL(0),
-   .newmsg_bit = MAILBOX_IRQ_NEWMSG(1),
-   .irqdisable = MAILBOX_IRQENABLE(0),
-};
-
-struct omap_mbox mbox_dsp_info = {
-   .name   = "dsp",
-   .ops= _mbox_ops,
-   .priv   = _mbox_dsp_priv,
-};
-#endif

[PATCHv3 00/14] drivers: mailbox: framework creation

[Suman Anna]

Hi,
Please find the updated mailbox patch series for pulling into linux-next.
The series is rebased on top of 3.9-rc2, and includes one new patch to
rename an existing mailbox.h added as part of the highbank cpufreq
support for 3.9 merge window [1]. 

The rest of the patches are mostly unchanged from the previous version,
other than the required changes as part of rebasing. The main changes
are:
- a new patch to rename existing mailbox.h to pl320-ipc.h (patch 1)
- updated patch to fix cleanup issues in probe & remove of omap2 mailbox
  file including minor variable name changes in hwmod files (patch 2)
- includes the updated dbx500 mailbox patch addressing review
  comments, same as [2] (patch 11)
- removes the MULTIPLATFORM Kconfig dependencies added to mailbox and
  remoteproc drivers for 3.9
- minor rebase changes include whitespace formatting

I am wondering if Patch 1 can be absorbed into 3.9 itself, since the
PL320 IPC and associated header file is introduced in 3.9-rc1.

Stephen,
I have hosted the series at [3]. Can you pull this into linux-next
sometime next week?

v2: [4]
After commit e8d3d47 (ARM: OMAP2+: Drop plat/cpu.h for omap2plus), the
cpu_is_xxx() checks for OMAP are restricted to arch/arm/mach-omap2. The
series includes 4 new patches, first patch removes these arch specific
calls of OMAP mailbox driver code (dependencies with soc.h), and the
last three patches include minor fixes in mailbox driver code.

This series is based on v3.8-rc7 and includes the necessary updates/fixes
required for validating remoteproc on OMAP4 and tidspbridge on OMAP3.

Other changes include:
- adaptations to remoteproc and tidspbridge to use the new mailbox
  api, and relying on the pdata field in the mailbox_msg structure
  instead of the previous header field (addressing review comments)
- ST-Ericsson driver update
- Kconfig fixes to fix build errors and choose proper ARCH dependencies
- 3 new patches for minor fixes in mailbox driver code
- rebased to include the devinit/devexit cleanup changes
- checkpatch errors/warnings fixes

v1:
OMAP and ST-Ericsson platforms are both using mailbox to communicate with some 
coprocessors.
Based on OMAP existing mailbox framework, this series proposes a generic 
framework, living under drivers/mailbox.

This series:
- moves omap-mailbox framework to a newly drivers/mailbox folder
  (part of plat-omap code cleaning)
- creates API header file
- replaces "omap" prefix by "mailbox"
- opens interface and make framework independent from omap HW
- adapts existing omap1 and omap2 drivers to new changes
- creates dbx500 mailbox driver for ST-Ericsson platforms

[1] http://www.spinics.net/lists/cpufreq/msg04031.html
[2] http://marc.info/?l=linux-omap=136079313704751=2
[3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
[4] http://marc.info/?l=linux-omap=136064540007076=2

Loic Pallardy (7):
  mailbox: rename omap_mbox in mailbox
  mailbox: create opened message type
  mailbox: change protection mechanisms
  mailbox: add shared memory mailbox type
  mailbox: add IRQF_NO_SUSPEND flag
  mailbox: add no_irq send message
  mailbox: create dbx500 mailbox driver

Omar Ramirez Luna (2):
  mailbox: OMAP: introduce mailbox framework
  mailbox: split internal header from API header

Suman Anna (5):
  mailbox: rename pl320-ipc specific mailbox.h
  ARM: OMAP2+: mbox: remove dependencies with soc.h
  mailbox/omap: check iomem resource before dereferencing it
  mailbox: check for NULL nb in mailbox_put
  mailbox: call request_irq after mbox queues are allocated

 .../devicetree/bindings/mailbox/dbx500-mailbox.txt |  27 +
 arch/arm/configs/omap1_defconfig   |   3 +-
 arch/arm/mach-omap1/Makefile   |   4 -
 arch/arm/mach-omap1/mailbox.c  | 199 ---
 arch/arm/mach-omap2/Makefile   |   3 -
 arch/arm/mach-omap2/devices.c  |  13 +-
 arch/arm/mach-omap2/mailbox.c  | 430 --
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  12 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  11 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  11 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  13 +
 arch/arm/plat-omap/Kconfig |  16 -
 arch/arm/plat-omap/Makefile|   3 -
 arch/arm/plat-omap/include/plat/mailbox.h  | 105 
 arch/arm/plat-omap/mailbox.c   | 435 --
 drivers/cpufreq/highbank-cpufreq.c |   2 +-
 drivers/mailbox/Kconfig|  41 ++
 drivers/mailbox/Makefile   |   5 +
 drivers/mailbox/mailbox-dbx500.c   | 648 +
 drivers/mailbox/mailbox-omap1.c| 229 
 drivers/mailbox/mailbox-omap2.c| 370 
 drivers/mailbox/mailbox.c  | 552 ++
 

[PATCHv3 08/14] mailbox: add shared memory mailbox type

[Suman Anna]

From: Loic Pallardy 

Some mailboxes are made up of cross interrupts
and associated shared memory.
Shared memory mapping is fixed and cross interrupt/shared
memory relation make impossible the use of virtio.
Mailbox framework must be enough opened to support
any kind of mailbox.

Signed-off-by: Loic Pallardy 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/mailbox-omap1.c| 34 +-
 drivers/mailbox/mailbox-omap2.c| 16 
 drivers/mailbox/mailbox.c  | 38 +++---
 drivers/mailbox/mailbox_internal.h | 18 +-
 4 files changed, 61 insertions(+), 45 deletions(-)

diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index 9268f98..7b30157 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mailbox_internal.h"
 
@@ -38,6 +39,7 @@ struct omap_mbox1_priv {
struct omap_mbox1_fifo tx_fifo;
struct omap_mbox1_fifo rx_fifo;
u32 data;
+   bool empty_flag;
 };
 
 static inline int mbox_read_reg(size_t ofs)
@@ -59,6 +61,7 @@ static void omap1_mbox_fifo_read(struct mailbox *mbox, struct 
mailbox_msg *msg)
priv->data = mbox_read_reg(fifo->data);
priv->data |= ((u32) mbox_read_reg(fifo->cmd)) << 16;
MAILBOX_FILL_MSG((*msg), 0, priv->data, 0);
+   priv->empty_flag = false;
 }
 
 static int
@@ -76,7 +79,11 @@ omap1_mbox_fifo_write(struct mailbox *mbox, struct 
mailbox_msg *msg)
 
 static int omap1_mbox_fifo_empty(struct mailbox *mbox)
 {
-   return 0;
+   struct omap_mbox1_priv *priv = (struct omap_mbox1_priv *)mbox->priv;
+   if (priv->empty_flag)
+   return 0;
+   else
+   return 1;
 }
 
 static int omap1_mbox_fifo_full(struct mailbox *mbox)
@@ -87,6 +94,18 @@ static int omap1_mbox_fifo_full(struct mailbox *mbox)
return mbox_read_reg(fifo->flag);
 }
 
+static int omap1_mbox_poll_for_space(struct mailbox *mbox)
+{
+   int ret = 0, i = 1000;
+
+   while (omap1_mbox_fifo_full(mbox)) {
+   if (--i == 0)
+   return -1;
+   udelay(1);
+   }
+   return ret;
+}
+
 /* irq */
 static void
 omap1_mbox_enable_irq(struct mailbox *mbox, mailbox_type_t irq)
@@ -105,17 +124,22 @@ omap1_mbox_disable_irq(struct mailbox *mbox, 
mailbox_type_t irq)
 static int
 omap1_mbox_is_irq(struct mailbox *mbox, mailbox_type_t irq)
 {
+   struct omap_mbox1_priv *priv = (struct omap_mbox1_priv *)mbox->priv;
+
if (irq == IRQ_TX)
return 0;
+   if (irq == IRQ_RX)
+   priv->empty_flag = true;
+
return 1;
 }
 
 static struct mailbox_ops omap1_mbox_ops = {
.type   = MBOX_HW_FIFO1_TYPE,
-   .fifo_read  = omap1_mbox_fifo_read,
-   .fifo_write = omap1_mbox_fifo_write,
-   .fifo_empty = omap1_mbox_fifo_empty,
-   .fifo_full  = omap1_mbox_fifo_full,
+   .read   = omap1_mbox_fifo_read,
+   .write  = omap1_mbox_fifo_write,
+   .empty  = omap1_mbox_fifo_empty,
+   .poll_for_space = omap1_mbox_poll_for_space,
.enable_irq = omap1_mbox_enable_irq,
.disable_irq= omap1_mbox_disable_irq,
.is_irq = omap1_mbox_is_irq,
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 43704fd..72f8368 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -129,6 +129,14 @@ static int omap2_mbox_fifo_full(struct mailbox *mbox)
return mbox_read_reg(fifo->fifo_stat);
 }
 
+static int omap2_mbox_poll_for_space(struct mailbox *mbox)
+{
+   if (omap2_mbox_fifo_full(mbox))
+   return -1;
+
+   return 0;
+}
+
 /* Mailbox IRQ handle functions */
 static void omap2_mbox_enable_irq(struct mailbox *mbox,
mailbox_type_t irq)
@@ -216,10 +224,10 @@ static struct mailbox_ops omap2_mbox_ops = {
.type   = MBOX_HW_FIFO2_TYPE,
.startup= omap2_mbox_startup,
.shutdown   = omap2_mbox_shutdown,
-   .fifo_read  = omap2_mbox_fifo_read,
-   .fifo_write = omap2_mbox_fifo_write,
-   .fifo_empty = omap2_mbox_fifo_empty,
-   .fifo_full  = omap2_mbox_fifo_full,
+   .read   = omap2_mbox_fifo_read,
+   .write  = omap2_mbox_fifo_write,
+   .empty  = omap2_mbox_fifo_empty,
+   .poll_for_space = omap2_mbox_poll_for_space,
.enable_irq = omap2_mbox_enable_irq,
.disable_irq= omap2_mbox_disable_irq,
.ack_irq= omap2_mbox_ack_irq,
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index ff6595a..08da5b0 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -44,21 +44,17 @@ module_param(mbox_kfifo_size, uint, S_IRUGO);
 MODULE_PARM_DESC(mbox_kfifo_size, "Size of mailbox 

[PATCHv3 10/14] mailbox: add no_irq send message

[Suman Anna]

From: Loic Pallardy 

For debug purpose, mailbox must be available when
interrupts are disabled to collect dump information.

Signed-off-by: Loic Pallardy 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/mailbox.c | 66 +++
 include/linux/mailbox.h   |  3 +++
 2 files changed, 69 insertions(+)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 35813f5..eaaf87e 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -110,6 +110,72 @@ out:
 }
 EXPORT_SYMBOL(mailbox_msg_send);
 
+#define TRANSFER_TIMEOUT 3 /* Becomes ~3s timeout */
+
+static struct mailbox_msg no_irq_msg_res;
+
+struct mailbox_msg *mailbox_msg_send_receive_no_irq(struct mailbox *mbox,
+   struct mailbox_msg *msg)
+{
+   int ret = 0;
+   int count = 0;
+
+   BUG_ON(!irqs_disabled());
+
+   if (likely(mbox->ops->write && mbox->ops->read)) {
+   if (__mbox_poll_for_space(mbox)) {
+   ret = -EBUSY;
+   goto out;
+   }
+   mbox->ops->write(mbox, msg);
+   while (!is_mbox_irq(mbox, IRQ_RX)) {
+   udelay(100);
+   cpu_relax();
+   count++;
+   if (count > TRANSFER_TIMEOUT) {
+   pr_err("%s: Error: transfer timed out\n",
+   __func__);
+   ret = -EINVAL;
+   goto out;
+   }
+   }
+   mbox->ops->read(mbox, _irq_msg_res);
+   ack_mbox_irq(mbox, IRQ_RX);
+   } else {
+   ret = -EINVAL;
+   }
+
+out:
+   BUG_ON(ret < 0);
+
+   return _irq_msg_res;
+}
+EXPORT_SYMBOL(mailbox_msg_send_receive_no_irq);
+
+int mailbox_msg_send_no_irq(struct mailbox *mbox,
+   struct mailbox_msg *msg)
+{
+   int ret = 0;
+
+   BUG_ON(!irqs_disabled());
+
+   if (likely(mbox->ops->write)) {
+   if (__mbox_poll_for_space(mbox)) {
+   ret = -EBUSY;
+   goto out;
+   }
+   mbox->ops->write(mbox, msg);
+   } else {
+   ret = -EINVAL;
+   }
+
+out:
+   WARN_ON(ret < 0);
+
+   return ret;
+}
+EXPORT_SYMBOL(mailbox_msg_send_no_irq);
+
 void mailbox_save_ctx(struct mailbox *mbox)
 {
if (!mbox->ops->save_ctx) {
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
index f8730b4..a41b67d 100644
--- a/include/linux/mailbox.h
+++ b/include/linux/mailbox.h
@@ -28,6 +28,9 @@ struct mailbox_msg {
 }
 
 int mailbox_msg_send(struct mailbox *, struct mailbox_msg *msg);
+struct mailbox_msg *mailbox_msg_send_receive_no_irq(struct mailbox *,
+   struct mailbox_msg *msg);
+int mailbox_msg_send_no_irq(struct mailbox *, struct mailbox_msg *msg);
 
 struct mailbox *mailbox_get(const char *, struct notifier_block *nb);
 void mailbox_put(struct mailbox *mbox, struct notifier_block *nb);
-- 
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/

[PATCHv3 14/14] mailbox: call request_irq after mbox queues are allocated

[Suman Anna]

The mailbox startup code is enabling the interrupt even before
any of the associated mailbox queues are allocated. Any pending
received mailbox message could cause a kernel panic as soon as
the interrupt is enabled due to the dereferencing of non-existing
mailbox queues within the ISR.

Signed-off-by: Fernando Guzman Lugo 
Signed-off-by: Suman Anna 
---
 drivers/mailbox/mailbox.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index c38241a..5fea5c2 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -377,14 +377,6 @@ static int mailbox_startup(struct mailbox *mbox)
}
 
if (!mbox->use_count++) {
-   ret = request_irq(mbox->irq, mbox_interrupt,
-   IRQF_SHARED | IRQF_NO_SUSPEND,
-   mbox->name, mbox);
-   if (unlikely(ret)) {
-   pr_err("failed to register mailbox interrupt:%d\n",
-   ret);
-   goto fail_request_irq;
-   }
mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
if (!mq) {
ret = -ENOMEM;
@@ -399,17 +391,25 @@ static int mailbox_startup(struct mailbox *mbox)
}
mbox->rxq = mq;
mq->mbox = mbox;
+   ret = request_irq(mbox->irq, mbox_interrupt,
+   IRQF_SHARED | IRQF_NO_SUSPEND,
+   mbox->name, mbox);
+   if (unlikely(ret)) {
+   pr_err("failed to register mailbox interrupt:%d\n",
+   ret);
+   goto fail_request_irq;
+   }
 
mailbox_enable_irq(mbox, IRQ_RX);
}
mutex_unlock(_configured_lock);
return 0;
 
+fail_request_irq:
+   mbox_queue_free(mbox->rxq);
 fail_alloc_rxq:
mbox_queue_free(mbox->txq);
 fail_alloc_txq:
-   free_irq(mbox->irq, mbox);
-fail_request_irq:
if (mbox->ops->shutdown)
mbox->ops->shutdown(mbox);
mbox->use_count--;
-- 
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/

[PATCHv3 12/14] mailbox/omap: check iomem resource before dereferencing it

[Suman Anna]

Add a NULL check for iomem resource in mailbox probe functions.

Signed-off-by: Fernando Guzman Lugo 
Signed-off-by: Suman Anna 
---
 drivers/mailbox/mailbox-omap1.c | 3 +++
 drivers/mailbox/mailbox-omap2.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index 7b30157..4441872 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -179,6 +179,9 @@ static int omap1_mbox_probe(struct platform_device *pdev)
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!mem)
+   return -ENOMEM;
+
mbox_base = ioremap(mem->start, resource_size(mem));
if (!mbox_base)
return -ENOMEM;
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 72f8368..eed5a3d 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -296,6 +296,11 @@ static int omap2_mbox_probe(struct platform_device *pdev)
}
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!mem) {
+   ret = -ENOMEM;
+   goto free_privblk;
+   }
+
mbox_base = ioremap(mem->start, resource_size(mem));
if (!mbox_base) {
ret = -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/

[PATCHv3 11/14] mailbox: create dbx500 mailbox driver

[Suman Anna]

From: Loic Pallardy 

Add STEriccson DBX500 PRCM mailbox support.

Signed-off-by: Loic Pallardy 
Signed-off-by: Linus Walleij 
---
 .../devicetree/bindings/mailbox/dbx500-mailbox.txt |  27 +
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   1 +
 drivers/mailbox/mailbox-dbx500.c   | 648 +
 include/linux/platform_data/mailbox-dbx500.h   |  12 +
 5 files changed, 695 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
 create mode 100644 drivers/mailbox/mailbox-dbx500.c
 create mode 100644 include/linux/platform_data/mailbox-dbx500.h

diff --git a/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
new file mode 100644
index 000..df0f594
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
@@ -0,0 +1,27 @@
+ST-Ericsson DBx500 PRCM Mailbox Driver
+
+Required properties:
+- compatible   : Should be
+ "stericsson,db8500-mailbox" for db8500 and db9500
+ "stericsson,db9540-mailbox" for db9540
+- reg  : Physical base address and length of mailbox's
+ registers and shared memory
+- reg-names: Should contain the reg names "prcm-reg" and
+ "prcmu-tcdm"
+- interrupts   : contains the IRQ line for the PRCM mailbox
+- interrupt-names  : Should contain the interrupt name "irq"
+- legacy-offset: Memory offset in shared mem for legacy 
mailboxes
+
+Optional properties:
+- upap-offset  : Memory offset in shared mem for upap mailboxes
+
+Examples:
+
+mailbox {
+   compatible = "stericsson,db8500-mailbox";
+   reg = <0x80157000 0x1000>, <0x801B8000 0x2000>;
+   reg-names = "prcm-reg", "prcmu-tcdm";
+   interrupts = <0 47 0x4>;
+   interrupt-names = "irq";
+   legacy-offset = <0xdd4>;
+};
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index d7692a7..438ea21 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -33,6 +33,12 @@ config OMAP2PLUS_MBOX
  OMAP2/3; or IPU, IVA HD and DSP in OMAP4. Say Y here if you want
  to use OMAP2+ Mailbox framework support.
 
+config DBX500_MBOX
+   tristate "DBx500 Mailbox driver support"
+   depends on ARCH_U8500
+   help
+ Say Y here if you want to use DBx500 Mailbox driver support for
+ power coprocessor access on Ux500 and Ux540 families
 
 config MBOX_KFIFO_SIZE
int "Mailbox kfifo default buffer size (bytes)"
@@ -44,6 +50,7 @@ config MBOX_KFIFO_SIZE
 
 config MBOX_DATA_SIZE
int "Mailbox associated data max size (bytes)"
+   default 64 if DBX500_MBOX
default 4
help
  Specify the default size of mailbox's associated data buffer
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 9ee0fcb..ee5fb1e 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PL320_MBOX)+= pl320-ipc.o
 obj-$(CONFIG_MAILBOX)  += mailbox.o
 obj-$(CONFIG_OMAP1_MBOX)   += mailbox-omap1.o
 obj-$(CONFIG_OMAP2PLUS_MBOX)   += mailbox-omap2.o
+obj-$(CONFIG_DBX500_MBOX)  += mailbox-dbx500.o
diff --git a/drivers/mailbox/mailbox-dbx500.c b/drivers/mailbox/mailbox-dbx500.c
new file mode 100644
index 000..e9d2b0a
--- /dev/null
+++ b/drivers/mailbox/mailbox-dbx500.c
@@ -0,0 +1,648 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2012
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Loic Pallardy  for ST-Ericsson
+ * DBX500 PRCM Mailbox driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mailbox_internal.h"
+
+#define MAILBOX_LEGACY 0
+#define MAILBOX_UPAP   1
+
+enum {
+   MAILBOX_BLOCKING,
+   MAILBOX_ATOMIC,
+};
+
+/* CPU mailbox registers */
+#define PRCM_MBOX_CPU_VAL  0x0fc
+#define PRCM_MBOX_CPU_SET  0x100
+#define PRCM_MBOX_CPU_CLR  0x104
+
+#define PRCM_ARM_IT1_CLR   0x48C
+#define PRCM_ARM_IT1_VAL   0x494
+
+#define NUM_MB 8
+#define MBOX_BIT BIT
+#define ALL_MBOX_BITS (MBOX_BIT(NUM_MB) - 1)
+
+/* CPU mailbox shared memory */
+#define PRCM_MBOX_LEGACY_SIZE  0x220
+#define _PRCM_MBOX_HEADER  0x214 /* 16 bytes */
+#define PRCM_MBOX_HEADER_REQ_MB0   (_PRCM_MBOX_HEADER + 0x0)
+#define PRCM_MBOX_HEADER_REQ_MB1   (_PRCM_MBOX_HEADER + 0x1)
+#define PRCM_MBOX_HEADER_REQ_MB2   (_PRCM_MBOX_HEADER + 0x2)
+#define PRCM_MBOX_HEADER_REQ_MB3   (_PRCM_MBOX_HEADER + 0x3)
+#define PRCM_MBOX_HEADER_REQ_MB4   (_PRCM_MBOX_HEADER + 0x4)
+#define PRCM_MBOX_HEADER_REQ_MB5   (_PRCM_MBOX_HEADER + 0x5)
+#define PRCM_MBOX_HEADER_ACK_MB0   (_PRCM_MBOX_HEADER + 0x8)
+
+/* Req Mailboxes */
+#define PRCM_REQ_MB0   0x208 /* 

[PATCHv3 04/14] mailbox: split internal header from API header

[Suman Anna]

From: Omar Ramirez Luna 

Now internal structures can remain hidden to the user and just API
related functions and defines are made available.

Signed-off-by: Omar Ramirez Luna 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/mailbox.c  | 34 ++
 drivers/mailbox/mailbox_internal.h | 55 +++
 include/linux/mailbox.h| 90 ++
 3 files changed, 93 insertions(+), 86 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 6c738aa..31303c5 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -116,6 +116,40 @@ out:
 }
 EXPORT_SYMBOL(omap_mbox_msg_send);
 
+void omap_mbox_save_ctx(struct omap_mbox *mbox)
+{
+   if (!mbox->ops->save_ctx) {
+   dev_err(mbox->dev, "%s:\tno save\n", __func__);
+   return;
+   }
+
+   mbox->ops->save_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_save_ctx);
+
+void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+{
+   if (!mbox->ops->restore_ctx) {
+   dev_err(mbox->dev, "%s:\tno restore\n", __func__);
+   return;
+   }
+
+   mbox->ops->restore_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_restore_ctx);
+
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+   mbox->ops->enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
+
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+   mbox->ops->disable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
+
 static void mbox_tx_tasklet(unsigned long tx_data)
 {
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
diff --git a/drivers/mailbox/mailbox_internal.h 
b/drivers/mailbox/mailbox_internal.h
index b39badb..d8896ca 100644
--- a/drivers/mailbox/mailbox_internal.h
+++ b/drivers/mailbox/mailbox_internal.h
@@ -9,6 +9,61 @@
 #ifndef MAILBOX_INTERNAL_H
 #define MAILBOX_INTERNAL_H
 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+typedef int __bitwise omap_mbox_type_t;
+#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
+#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+
+struct omap_mbox_ops {
+   omap_mbox_type_ttype;
+   int (*startup)(struct omap_mbox *mbox);
+   void(*shutdown)(struct omap_mbox *mbox);
+   /* fifo */
+   mbox_msg_t  (*fifo_read)(struct omap_mbox *mbox);
+   void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
+   int (*fifo_empty)(struct omap_mbox *mbox);
+   int (*fifo_full)(struct omap_mbox *mbox);
+   /* irq */
+   void(*enable_irq)(struct omap_mbox *mbox,
+   omap_mbox_irq_t irq);
+   void(*disable_irq)(struct omap_mbox *mbox,
+   omap_mbox_irq_t irq);
+   void(*ack_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+   int (*is_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+   /* ctx */
+   void(*save_ctx)(struct omap_mbox *mbox);
+   void(*restore_ctx)(struct omap_mbox *mbox);
+};
+
+struct omap_mbox_queue {
+   spinlock_t  lock;
+   struct kfifofifo;
+   struct work_struct  work;
+   struct tasklet_struct   tasklet;
+   struct omap_mbox*mbox;
+   bool full;
+};
+
+struct omap_mbox {
+   const char  *name;
+   unsigned intirq;
+   struct omap_mbox_queue  *txq, *rxq;
+   struct omap_mbox_ops*ops;
+   struct device   *dev;
+   void*priv;
+   int use_count;
+   struct blocking_notifier_head   notifier;
+};
+
+void omap_mbox_init_seq(struct omap_mbox *);
+
+int omap_mbox_register(struct device *parent, struct omap_mbox **);
+int omap_mbox_unregister(void);
 
 #endif /* MAILBOX_INTERNAL_H */
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
index 5722b93..e97824e 100644
--- a/include/linux/mailbox.h
+++ b/include/linux/mailbox.h
@@ -9,12 +9,6 @@
 #ifndef MAILBOX_H
 #define MAILBOX_H
 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 typedef u32 mbox_msg_t;
 struct omap_mbox;
 
@@ -22,90 +16,14 @@ typedef int __bitwise omap_mbox_irq_t;
 #define IRQ_TX ((__force omap_mbox_irq_t) 1)
 #define IRQ_RX ((__force omap_mbox_irq_t) 2)
 
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
-
-struct omap_mbox_ops {
-   omap_mbox_type_ttype;
-   int (*startup)(struct omap_mbox *mbox);
-   void(*shutdown)(struct omap_mbox *mbox);
-   /* fifo */
-   mbox_msg_t  (*fifo_read)(struct omap_mbox *mbox);
-   void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
-   int  

[PATCHv3 05/14] mailbox: rename omap_mbox in mailbox

[Suman Anna]

From: Loic Pallardy 

In order to create a generic mailbox framework, functions
and structures should be renamed in mailbox.

Taking care of remoteproc and tidspbridge while at it.

Signed-off-by: Loic Pallardy 
Signed-off-by: Omar Ramirez Luna 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/Kconfig   |   2 +-
 drivers/mailbox/mailbox-omap1.c   |  28 ++---
 drivers/mailbox/mailbox-omap2.c   |  50 
 drivers/mailbox/mailbox.c | 133 +++---
 drivers/mailbox/mailbox_internal.h|  52 -
 drivers/remoteproc/omap_remoteproc.c  |  18 +--
 drivers/staging/tidspbridge/core/_tiomap.h|   2 +-
 drivers/staging/tidspbridge/core/chnl_sm.c|   8 +-
 drivers/staging/tidspbridge/core/tiomap3430.c |   6 +-
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c |   6 +-
 drivers/staging/tidspbridge/core/tiomap_io.c  |   6 +-
 include/linux/mailbox.h   |  22 ++--
 12 files changed, 166 insertions(+), 167 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 22d6f8d..15ccdde 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -34,7 +34,7 @@ config OMAP2PLUS_MBOX
  to use OMAP2+ Mailbox framework support.
 
 
-config OMAP_MBOX_KFIFO_SIZE
+config MBOX_KFIFO_SIZE
int "Mailbox kfifo default buffer size (bytes)"
default 256
help
diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index dbf40e2..a9e5e58 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -50,7 +50,7 @@ static inline void mbox_write_reg(u32 val, size_t ofs)
 }
 
 /* msg */
-static mbox_msg_t omap1_mbox_fifo_read(struct omap_mbox *mbox)
+static mbox_msg_t omap1_mbox_fifo_read(struct mailbox *mbox)
 {
struct omap_mbox1_fifo *fifo =
&((struct omap_mbox1_priv *)mbox->priv)->rx_fifo;
@@ -63,7 +63,7 @@ static mbox_msg_t omap1_mbox_fifo_read(struct omap_mbox *mbox)
 }
 
 static void
-omap1_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
+omap1_mbox_fifo_write(struct mailbox *mbox, mbox_msg_t msg)
 {
struct omap_mbox1_fifo *fifo =
&((struct omap_mbox1_priv *)mbox->priv)->tx_fifo;
@@ -72,12 +72,12 @@ omap1_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t 
msg)
mbox_write_reg(msg >> 16, fifo->cmd);
 }
 
-static int omap1_mbox_fifo_empty(struct omap_mbox *mbox)
+static int omap1_mbox_fifo_empty(struct mailbox *mbox)
 {
return 0;
 }
 
-static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
+static int omap1_mbox_fifo_full(struct mailbox *mbox)
 {
struct omap_mbox1_fifo *fifo =
&((struct omap_mbox1_priv *)mbox->priv)->rx_fifo;
@@ -87,29 +87,29 @@ static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
 
 /* irq */
 static void
-omap1_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_type_t irq)
+omap1_mbox_enable_irq(struct mailbox *mbox, mailbox_type_t irq)
 {
if (irq == IRQ_RX)
enable_irq(mbox->irq);
 }
 
 static void
-omap1_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_type_t irq)
+omap1_mbox_disable_irq(struct mailbox *mbox, mailbox_type_t irq)
 {
if (irq == IRQ_RX)
disable_irq(mbox->irq);
 }
 
 static int
-omap1_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_type_t irq)
+omap1_mbox_is_irq(struct mailbox *mbox, mailbox_type_t irq)
 {
if (irq == IRQ_TX)
return 0;
return 1;
 }
 
-static struct omap_mbox_ops omap1_mbox_ops = {
-   .type   = OMAP_MBOX_TYPE1,
+static struct mailbox_ops omap1_mbox_ops = {
+   .type   = MBOX_HW_FIFO1_TYPE,
.fifo_read  = omap1_mbox_fifo_read,
.fifo_write = omap1_mbox_fifo_write,
.fifo_empty = omap1_mbox_fifo_empty,
@@ -135,19 +135,19 @@ static struct omap_mbox1_priv omap1_mbox_dsp_priv = {
},
 };
 
-static struct omap_mbox mbox_dsp_info = {
+static struct mailbox mbox_dsp_info = {
.name   = "dsp",
.ops= _mbox_ops,
.priv   = _mbox_dsp_priv,
 };
 
-static struct omap_mbox *omap1_mboxes[] = { _dsp_info, NULL };
+static struct mailbox *omap1_mboxes[] = { _dsp_info, NULL };
 
 static int omap1_mbox_probe(struct platform_device *pdev)
 {
struct resource *mem;
int ret;
-   struct omap_mbox **list;
+   struct mailbox **list;
 
list = omap1_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
@@ -157,7 +157,7 @@ static int omap1_mbox_probe(struct platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
 
-   ret = omap_mbox_register(>dev, list);
+   ret = mailbox_register(>dev, list);
if (ret) {
iounmap(mbox_base);
return ret;
@@ -168,7 +168,7 @@ static int omap1_mbox_probe(struct platform_device *pdev)
 
 static int omap1_mbox_remove(struct 

[PATCHv3 06/14] mailbox: create opened message type

[Suman Anna]

From: Loic Pallardy 

Current message type is a u32 to fit HW fifo format.
This should be extended to support any message exchanges
and type of mailbox.

Proposed structure owns the original u32 and an optional
pointer on additional data.

Adaptations made to remoteproc and tidspbridge drivers.

Signed-off-by: Loic Pallardy 
Signed-off-by: Omar Ramirez Luna 
Signed-off-by: Suman Anna 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/Kconfig  |  9 
 drivers/mailbox/mailbox-omap1.c  | 26 +-
 drivers/mailbox/mailbox-omap2.c  | 17 ---
 drivers/mailbox/mailbox.c| 73 +++-
 drivers/mailbox/mailbox_internal.h   |  6 ++-
 drivers/remoteproc/omap_remoteproc.c | 20 +---
 drivers/staging/tidspbridge/core/io_sm.c |  5 +-
 drivers/staging/tidspbridge/core/tiomap_io.c |  5 +-
 include/linux/mailbox.h  | 15 +-
 9 files changed, 122 insertions(+), 54 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 15ccdde..d7692a7 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -41,4 +41,13 @@ config MBOX_KFIFO_SIZE
  Specify the default size of mailbox's kfifo buffers (bytes).
  This can also be changed at runtime (via the mbox_kfifo_size
  module parameter).
+
+config MBOX_DATA_SIZE
+   int "Mailbox associated data max size (bytes)"
+   default 4
+   help
+ Specify the default size of mailbox's associated data buffer
+ (bytes)
+  This can also be changed at runtime (via the mbox_kfifo_size
+  module parameter).
 endif
diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index a9e5e58..9268f98 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -37,6 +37,7 @@ struct omap_mbox1_fifo {
 struct omap_mbox1_priv {
struct omap_mbox1_fifo tx_fifo;
struct omap_mbox1_fifo rx_fifo;
+   u32 data;
 };
 
 static inline int mbox_read_reg(size_t ofs)
@@ -50,26 +51,27 @@ static inline void mbox_write_reg(u32 val, size_t ofs)
 }
 
 /* msg */
-static mbox_msg_t omap1_mbox_fifo_read(struct mailbox *mbox)
+static void omap1_mbox_fifo_read(struct mailbox *mbox, struct mailbox_msg *msg)
 {
-   struct omap_mbox1_fifo *fifo =
-   &((struct omap_mbox1_priv *)mbox->priv)->rx_fifo;
-   mbox_msg_t msg;
+   struct omap_mbox1_priv *priv = mbox->priv;
+   struct omap_mbox1_fifo *fifo = >rx_fifo;
 
-   msg = mbox_read_reg(fifo->data);
-   msg |= ((mbox_msg_t) mbox_read_reg(fifo->cmd)) << 16;
-
-   return msg;
+   priv->data = mbox_read_reg(fifo->data);
+   priv->data |= ((u32) mbox_read_reg(fifo->cmd)) << 16;
+   MAILBOX_FILL_MSG((*msg), 0, priv->data, 0);
 }
 
-static void
-omap1_mbox_fifo_write(struct mailbox *mbox, mbox_msg_t msg)
+static int
+omap1_mbox_fifo_write(struct mailbox *mbox, struct mailbox_msg *msg)
 {
struct omap_mbox1_fifo *fifo =
&((struct omap_mbox1_priv *)mbox->priv)->tx_fifo;
+   u32 data = (u32)msg->pdata;
+
+   mbox_write_reg(data & 0x, fifo->data);
+   mbox_write_reg(data >> 16, fifo->cmd);
 
-   mbox_write_reg(msg & 0x, fifo->data);
-   mbox_write_reg(msg >> 16, fifo->cmd);
+   return 0;
 }
 
 static int omap1_mbox_fifo_empty(struct mailbox *mbox)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 20cb846..43704fd 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -60,6 +60,7 @@ struct omap_mbox2_priv {
u32 ctx[OMAP4_MBOX_NR_REGS];
unsigned long irqdisable;
u32 intr_type;
+   u32 data;
 };
 
 static void omap2_mbox_enable_irq(struct mailbox *mbox,
@@ -96,18 +97,22 @@ static void omap2_mbox_shutdown(struct mailbox *mbox)
 }
 
 /* Mailbox FIFO handle functions */
-static mbox_msg_t omap2_mbox_fifo_read(struct mailbox *mbox)
+static void omap2_mbox_fifo_read(struct mailbox *mbox, struct mailbox_msg *msg)
 {
-   struct omap_mbox2_fifo *fifo =
-   &((struct omap_mbox2_priv *)mbox->priv)->rx_fifo;
-   return (mbox_msg_t) mbox_read_reg(fifo->msg);
+   struct omap_mbox2_priv *priv = mbox->priv;
+   struct omap_mbox2_fifo *fifo = >rx_fifo;
+   priv->data = mbox_read_reg(fifo->msg);
+   MAILBOX_FILL_MSG((*msg), 0, priv->data, 0);
 }
 
-static void omap2_mbox_fifo_write(struct mailbox *mbox, mbox_msg_t msg)
+static int omap2_mbox_fifo_write(struct mailbox *mbox, struct mailbox_msg *msg)
 {
struct omap_mbox2_fifo *fifo =
&((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
-   mbox_write_reg(msg, fifo->msg);
+
+   mbox_write_reg((u32)msg->pdata, fifo->msg);
+
+   return 0;
 }
 
 static int omap2_mbox_fifo_empty(struct mailbox *mbox)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 7856fbd..6b43e7c 100644
--- 

[PATCHv3 13/14] mailbox: check for NULL nb in mailbox_put

[Suman Anna]

The mailbox_put function must check the notifier block for
NULL before trying to unregister it.

Signed-off-by: Fernando Guzman Lugo 
Signed-off-by: Suman Anna 
---
 drivers/mailbox/mailbox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index eaaf87e..c38241a 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -473,7 +473,8 @@ EXPORT_SYMBOL(mailbox_get);
 
 void mailbox_put(struct mailbox *mbox, struct notifier_block *nb)
 {
-   blocking_notifier_chain_unregister(>notifier, nb);
+   if (nb)
+   blocking_notifier_chain_unregister(>notifier, nb);
mailbox_fini(mbox);
 }
 EXPORT_SYMBOL(mailbox_put);
-- 
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/

[PATCHv3 07/14] mailbox: change protection mechanisms

[Suman Anna]

From: Loic Pallardy 

TX: replace spin by mutex to release CPU
during wait on mailbox resource.

Signed-off-by: Loic Pallardy 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/mailbox.c  | 5 +++--
 drivers/mailbox/mailbox_internal.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 6b43e7c..ff6595a 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -94,7 +94,7 @@ int mailbox_msg_send(struct mailbox *mbox, struct mailbox_msg 
*msg)
struct mailbox_queue *mq = mbox->txq;
int ret = 0, len;
 
-   spin_lock_bh(>lock);
+   mutex_lock(>mlock);
 
if (kfifo_avail(>fifo) < (sizeof(msg) + msg->size)) {
ret = -ENOMEM;
@@ -118,7 +118,7 @@ int mailbox_msg_send(struct mailbox *mbox, struct 
mailbox_msg *msg)
tasklet_schedule(>txq->tasklet);
 
 out:
-   spin_unlock_bh(>lock);
+   mutex_unlock(>mlock);
return ret;
 }
 EXPORT_SYMBOL(mailbox_msg_send);
@@ -289,6 +289,7 @@ static struct mailbox_queue *mbox_queue_alloc(struct 
mailbox *mbox,
return NULL;
 
spin_lock_init(>lock);
+   mutex_init(>mlock);
 
if (kfifo_alloc(>fifo, mbox_kfifo_size, GFP_KERNEL))
goto error;
diff --git a/drivers/mailbox/mailbox_internal.h 
b/drivers/mailbox/mailbox_internal.h
index da5e263..7ac8bb8 100644
--- a/drivers/mailbox/mailbox_internal.h
+++ b/drivers/mailbox/mailbox_internal.h
@@ -43,6 +43,7 @@ struct mailbox_ops {
 
 struct mailbox_queue {
spinlock_t  lock;
+   struct mutexmlock;
struct kfifofifo;
struct work_struct  work;
struct tasklet_struct   tasklet;
-- 
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/

[PATCHv3 09/14] mailbox: add IRQF_NO_SUSPEND flag

[Suman Anna]

From: Loic Pallardy 

Coprocessor must be accessible during suspend transitions.

Signed-off-by: Loic Pallardy 
Signed-off-by: Linus Walleij 
---
 drivers/mailbox/mailbox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 08da5b0..35813f5 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -311,7 +311,8 @@ static int mailbox_startup(struct mailbox *mbox)
}
 
if (!mbox->use_count++) {
-   ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
+   ret = request_irq(mbox->irq, mbox_interrupt,
+   IRQF_SHARED | IRQF_NO_SUSPEND,
mbox->name, mbox);
if (unlikely(ret)) {
pr_err("failed to register mailbox interrupt:%d\n",
-- 
1.8.1.2

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

[PATCHv3 01/14] mailbox: rename pl320-ipc specific mailbox.h

[Suman Anna]

The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.

Signed-off-by: Suman Anna 
Cc: Mark Langsdorf 
Cc: Rafael J. Wysocki 
---
 drivers/cpufreq/highbank-cpufreq.c |  2 +-
 drivers/mailbox/pl320-ipc.c|  2 +-
 include/linux/mailbox.h| 17 -
 include/linux/pl320-ipc.h  | 17 +
 4 files changed, 19 insertions(+), 19 deletions(-)
 delete mode 100644 include/linux/mailbox.h
 create mode 100644 include/linux/pl320-ipc.h

diff --git a/drivers/cpufreq/highbank-cpufreq.c 
b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..3118b87 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #define HB_CPUFREQ_CHANGE_NOTE 0x8001
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cba..f3755e0 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #define IPCMxSOURCE(m) ((m) * 0x40)
 #define IPCMxDSET(m)   (((m) * 0x40) + 0x004)
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
deleted file mode 100644
index 5161f63..000
--- a/include/linux/mailbox.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-int pl320_ipc_transmit(u32 *data);
-int pl320_ipc_register_notifier(struct notifier_block *nb);
-int pl320_ipc_unregister_notifier(struct notifier_block *nb);
diff --git a/include/linux/pl320-ipc.h b/include/linux/pl320-ipc.h
new file mode 100644
index 000..5161f63
--- /dev/null
+++ b/include/linux/pl320-ipc.h
@@ -0,0 +1,17 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+int pl320_ipc_transmit(u32 *data);
+int pl320_ipc_register_notifier(struct notifier_block *nb);
+int pl320_ipc_unregister_notifier(struct notifier_block *nb);
-- 
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 11/12] rwsem: wake all readers when first waiter is a reader

[Dave Chinner]

On Mon, Mar 11, 2013 at 11:43:34PM -0700, Michel Lespinasse wrote:
> Hi Dave,
> 
> On Mon, Mar 11, 2013 at 7:36 PM, Dave Chinner  wrote:
> > On Sun, Mar 10, 2013 at 10:17:42PM -0700, Michel Lespinasse wrote:
> >> - since all readers are woken at once, you might see burst of direct
> >> IO operations followed by bursts of truncate operations, instead of
> >> having them interleaved in smaller groups as before.
> >
> > And this will result in the same application IO pattern giving
> > vastly different results. e.g. a read IO promoted ahead of a
> > truncate will now return data instead of -1 (beyond EOF).
> 
> I will reply to this part first, as I think this gives a more concrete
> anchor to the discussion.
> 
> The crucial point is that the truncate system call hasn't completed
> yet - that thread is still queued in the rwsem.
> 
> You still have the guarantee that the truncate will complete
> eventually (even if there is a never-ending stream of IOs), and that
> all IO system calls that start after the truncate system call
> completes will see the file as truncated.

Sure, but the problem is not about when the syscall completes - the
problem is that you are changing where in the pipeline of IO the
truncate is initially executed.  i.e. ordering is not defined by
when an operation completes, but by the order ing which the queue is
processed after a blocking operation completes. That is not when the
syscall completes, but when the filesystem drops the exclusive lock.

>From a single threaded userspace application perspective or
multithreaded apps with their own userspace locking, truncates
complete when either the syscall completes or some time after when
the application drops it's lock. Either way, we're looking at
completion time serialisation, and in that case what XFS or the
kernel does simply doesn't matter.

However, if we are talking about userspace applications that use
lockless IO algorithms or kernel side applications (like knfsd) that
are exposed directly to the filesystem locking semantics,
serialisation behaviour is actually defined by filesystem's
submission side locking behaviour. There is no external
serialisation of IO completion, so serialisation and ordering is
defined (for XFS) solely by the rwsem behaviour.

> You don't have guarantees about which system call will "appear to run
> before the other" if the execution times of the two system calls
> overlap each other, but you actually never had such a guarantee from a
> correctness perspective (i.e. you could never guarantee which of the
> two would get queued on the rwsem ahead of the other).

Sure, but as long as the submission side ordering is deterministic,
it doesn't matter.

> > Ok, so I can see where your latency figure comes from, but it's
> > still a change of ordering in that W2 is no longer a barrier to the
> > reads queued after it.
> 
> My claim is that it's not a visible change from a correctness
> perspective

I am not arguing that it is incorrect. I'm arguing that the change
of ordering semantics breaks assumptions a lot of code makes about
how these locks work.

> > similar to this:
> >
> > W1R1W2R2W3R3.WnRm
> >
> > By my reading of the algorithm you are proposing, after W1 is
> > released, we end up with the queue being treated like this:
> >
> > R1R2R3RmW2W3Wn
> >
> > Right?
> 
> Yes, if what you are representing is the state of the queue at a given
> point of time (which implies R1..Rm must be distinct threads, not just
> the same thread doing repeated requests).

Yup, that's very typical.

> As new requests come in over time, one important point to remember is
> that each writer will see at most one batch of readers wake up ahead
> of it (though this batch may include readers that were originally
> queued both before and after it).

And that's *exactly* the problem with the changes you are proposing
- rwsems will no longer provide strongly ordered write vs read
barrier semantics.

> I find the name 'barrier' actually confusing when used to describe
> synchronous operations.  To me a barrier is usualy between
> asynchronous operations, and it is well defined which operations
> are ahead or behind of the barrier (either because they were
> queued by the same thread, or they were queued by different
> threads which may have synchronized together some other way).

When you have hundreds or thousands of threads doing IO to the one
file, it doesn't matter if the IO is issued synchronously or
asynchronously by the threads - you simply have a huge amount of
data IO concurrency and very, very deep pipelines.

Inserting a metadata modification (truncate, preallocation,
holepunch, etc) into that pipeline currently causes all new
submissions to queue behind the metadata modification, waits for
everything submitted before the metadata modification to complete
and then runs the metadata modification. Once it completes, it then
allows everything queued up to the next metadata modification to
run

That 

Re: linux-next: unneeded merge in the security tree

[Junio C Hamano]

Theodore Ts'o  writes:

> On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
>> Theodore Ts'o  writes:
>> 
>> > [remote "origin"]
>> >url = 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> >fetch = +refs/heads/master:refs/heads/master
>> >mergeoptions = --ff-only
>> >
>> 
>> Is there an escape hatch for that rare case?  IOW, how does a
>> submaintainer who configured the above to override --ff-only?
>
> Hmm, maybe we would need to add a --no-ff-only?  Or they could just
> do:
>
>   git fetch origin
>   git merge FETCH_HEAD

Hmm, neither feel quite nice.

I haven't heard any comments on my alternative proposal, by the
way.  Did the message get lost?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Guenter Roeck]

On Wed, Mar 13, 2013 at 08:25:09AM +0530, Naveen Krishna Chatradhi wrote:
> This patch adds DT support to NTC driver to parse the
> platform data.
> 
> Also adds the support to work as an iio device.
> 
> During the probe ntc driver gets the respective channels of ADC
> and uses iio_raw_read calls to get the ADC converted value.
> 
> Signed-off-by: Naveen Krishna Chatradhi 

Almost there ...

> ---
> Changes since v2:
> 1. Modified Kconfig to select IIO only if OF is defined
> 2. changed "pullup-uV" to "pullup-uv" in dt bindings
> 3. allocate pdata in ntc_thermistor_parse_dt and modify the return
>value to platform data pointer, handled other errors for dt bindings.
> 4. used strlcpy instead of strncpy as the former handles
>null termination
> 5. made a wrapper function for iio_channel release and defined to
>null in case of non-DT
> 6. removed a typecase of (s64) which is not needed.
> 
> Guenter Roeck, Thanks for your valuble time and comments. They really
> are helping me learn and do better on my future patches.
> 
> Doug, Thanks for your support and testing these patches.
> 
>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   29 
>  drivers/hwmon/Kconfig  |1 +
>  drivers/hwmon/ntc_thermistor.c |  144 
> +---
>  include/linux/platform_data/ntc_thermistor.h   |8 +-
>  4 files changed, 162 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> new file mode 100644
> index 000..c6f6667
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> @@ -0,0 +1,29 @@
> +NTC Thermistor hwmon sensors
> +---
> +
> +Requires node properties:
> +- "compatible" value : one of
> + "ntc,ncp15wb473"
> + "ntc,ncp18wb473"
> + "ntc,ncp21wb473"
> + "ntc,ncp03wb473"
> + "ntc,ncp15wl333"
> +- "pullup-uv"Pull up voltage in micro volts
> +- "pullup-ohm"   Pull up resistor value in ohms
> +- "pulldown-ohm" Pull down resistor value in ohms
> +- "connected-positive" Always ON, If not specified.
> + Status change is possible.
> +- "io-channels"  Channel node of ADC to be used for
> + conversion.
> +
> +Read more about iio bindings at
> + Documentation/devicetree/bindings/iio/iio-bindings.txt
> +
> +Example:
> + ncp15wb473@0 {
> + compatible = "ntc,ncp15wb473";
> + pullup-uv = <180>;
> + pullup-ohm = <47000>;
> + pulldown-ohm = <0>;
> + io-channels = < 3>;
> + };
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..cc47c12 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -879,6 +879,7 @@ config SENSORS_MCP3021
>  
>  config SENSORS_NTC_THERMISTOR
>   tristate "NTC thermistor support"
> + select IIO if OF
>   help
> This driver supports NTC thermistors sensor reading and its
> interpretation. The driver can also monitor the temperature and
> diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
> index b5f63f9..ba0f7b0 100644
> --- a/drivers/hwmon/ntc_thermistor.c
> +++ b/drivers/hwmon/ntc_thermistor.c
> @@ -26,9 +26,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -37,6 +44,15 @@ struct ntc_compensation {
>   unsigned intohm;
>  };
>  
> +static const struct platform_device_id ntc_thermistor_id[] = {
> + { "ncp15wb473", TYPE_NCPXXWB473 },
> + { "ncp18wb473", TYPE_NCPXXWB473 },
> + { "ncp21wb473", TYPE_NCPXXWB473 },
> + { "ncp03wb473", TYPE_NCPXXWB473 },
> + { "ncp15wl333", TYPE_NCPXXWL333 },
> + { },
> +};
> +
>  /*
>   * A compensation table should be sorted by the values of .ohm
>   * in descending order.
> @@ -125,6 +141,91 @@ struct ntc_data {
>   char name[PLATFORM_NAME_SIZE];
>  };
>  
> +#ifdef CONFIG_OF
> +static int ntc_adc_iio_read(struct ntc_thermistor_platform_data *pdata)
> +{
> + struct iio_channel *channel = pdata->chan;
> + unsigned int result;
> + int val, ret;
> +
> + ret = iio_read_channel_raw(channel, );
> + if (ret < 0) {
> + pr_err("read channel() error: %d\n", ret);
> + return ret;
> + }
> +
> + /* unit: mV */
> + result = pdata->pullup_uV * val;
> + result >>= 12;
> +
> + return result;
> +}
> +
> +static const struct of_device_id ntc_match[] = {
> + { .compatible = "ntc,ncp15wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp18wb473",
> + .data = _thermistor_id[TYPE_NCPXXWB473] },
> + { .compatible = "ntc,ncp21wb473",
> +

Re: [PATCH] sched: wakeup buddy

[Michael Wang]

On 03/12/2013 06:08 PM, Peter Zijlstra wrote:
> Does something simple like a per-task throttle of wake_affine() gain
> similar benefits? Say something like only do wake_affine() once every
> 10 ms or so (counting on the wakee, not waker).
> 
> The rationale being that wake_affine() relies on load-balance
> statistics that aren't updated that much faster, so calling it more
> often than that seems pointless.

That could works, if we do not have any logical to rely on and just want
to limit the rate of pull, this could be a good solution.

However, we already figure out the logical that wakeup related task
could benefit from closely running, this could promise us somewhat
reliable benefit.

It's just like, tell me how many times that two task continuously wakeup
each other means they related, I will try to pull them together since
they have a big chance to benefit from cache.

IMHO, that sounds a little easier for users than to make the decision on
tell me how long to pull tasks together, they may be confused...

In summary, I think we have two point here need to be considered:

1. what about the missed optimize timing, that may benefit
   some workload (although we haven't found such workload yet).

2. how many benefit could wake_affine() stuff bring to us,
   if limit rate benefit us, why don't we remove it?

Point 1 could be solved by disable wakeup buddy with 0 limitation, and
when users complain about their database performance, we just say "Calm
down and take a try on this knob ;-)".

Point 2 is about the wake_affine() stuff itself.

Later we could try to make the stuff better, but I have the feeling that
some key info is not there (may be we need Ingo's work atom idea here,
just wondering...), whatever, I think we still need a knob finally,
since it doesn't sounds like a general optimization which benefit all
the cases.

And I don't agree to remove the stuff since we have many theories that
this could benefit us, but before it really show the benefit in all the
cases, provide a way to keep it quiet sounds necessary...

Regards,
Michael Wang

> 
> Something like that should take a lot less lines to implement.
> 
> Just wondering..
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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/

linux-next: manual merge of the trivial tree with the virtio tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
Documentation/virtual/virtio-spec.txt between commit 29266e2e29f1
("Remove Documentation/virtual/virtio-spec.txt") from the virtio tree and
commit d097ddaf529f ("doc: virtual: Fix typos in virtio-spec.txt") from
the trivial tree.

The former removed the file, so I did that and can carry the fix as
necessary (no action is required).

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


pgpRrOe9io4k7.pgp
Description: PGP signature

[PATCH v3] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Naveen Krishna Chatradhi]

This patch adds DT support to NTC driver to parse the
platform data.

Also adds the support to work as an iio device.

During the probe ntc driver gets the respective channels of ADC
and uses iio_raw_read calls to get the ADC converted value.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v2:
1. Modified Kconfig to select IIO only if OF is defined
2. changed "pullup-uV" to "pullup-uv" in dt bindings
3. allocate pdata in ntc_thermistor_parse_dt and modify the return
   value to platform data pointer, handled other errors for dt bindings.
4. used strlcpy instead of strncpy as the former handles
   null termination
5. made a wrapper function for iio_channel release and defined to
   null in case of non-DT
6. removed a typecase of (s64) which is not needed.

Guenter Roeck, Thanks for your valuble time and comments. They really
are helping me learn and do better on my future patches.

Doug, Thanks for your support and testing these patches.

 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   29 
 drivers/hwmon/Kconfig  |1 +
 drivers/hwmon/ntc_thermistor.c |  144 +---
 include/linux/platform_data/ntc_thermistor.h   |8 +-
 4 files changed, 162 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt

diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
new file mode 100644
index 000..c6f6667
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -0,0 +1,29 @@
+NTC Thermistor hwmon sensors
+---
+
+Requires node properties:
+- "compatible" value : one of
+   "ntc,ncp15wb473"
+   "ntc,ncp18wb473"
+   "ntc,ncp21wb473"
+   "ntc,ncp03wb473"
+   "ntc,ncp15wl333"
+- "pullup-uv"  Pull up voltage in micro volts
+- "pullup-ohm" Pull up resistor value in ohms
+- "pulldown-ohm" Pull down resistor value in ohms
+- "connected-positive" Always ON, If not specified.
+   Status change is possible.
+- "io-channels"Channel node of ADC to be used for
+   conversion.
+
+Read more about iio bindings at
+   Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Example:
+   ncp15wb473@0 {
+   compatible = "ntc,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = < 3>;
+   };
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 89ac1cb..cc47c12 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -879,6 +879,7 @@ config SENSORS_MCP3021
 
 config SENSORS_NTC_THERMISTOR
tristate "NTC thermistor support"
+   select IIO if OF
help
  This driver supports NTC thermistors sensor reading and its
  interpretation. The driver can also monitor the temperature and
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index b5f63f9..ba0f7b0 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -26,9 +26,16 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 
@@ -37,6 +44,15 @@ struct ntc_compensation {
unsigned intohm;
 };
 
+static const struct platform_device_id ntc_thermistor_id[] = {
+   { "ncp15wb473", TYPE_NCPXXWB473 },
+   { "ncp18wb473", TYPE_NCPXXWB473 },
+   { "ncp21wb473", TYPE_NCPXXWB473 },
+   { "ncp03wb473", TYPE_NCPXXWB473 },
+   { "ncp15wl333", TYPE_NCPXXWL333 },
+   { },
+};
+
 /*
  * A compensation table should be sorted by the values of .ohm
  * in descending order.
@@ -125,6 +141,91 @@ struct ntc_data {
char name[PLATFORM_NAME_SIZE];
 };
 
+#ifdef CONFIG_OF
+static int ntc_adc_iio_read(struct ntc_thermistor_platform_data *pdata)
+{
+   struct iio_channel *channel = pdata->chan;
+   unsigned int result;
+   int val, ret;
+
+   ret = iio_read_channel_raw(channel, );
+   if (ret < 0) {
+   pr_err("read channel() error: %d\n", ret);
+   return ret;
+   }
+
+   /* unit: mV */
+   result = pdata->pullup_uV * val;
+   result >>= 12;
+
+   return result;
+}
+
+static const struct of_device_id ntc_match[] = {
+   { .compatible = "ntc,ncp15wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp18wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp21wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp03wb473",
+   .data = _thermistor_id[TYPE_NCPXXWB473] },
+   { .compatible = "ntc,ncp15wl333",
+   .data = _thermistor_id[TYPE_NCPXXWL333] },
+   { },
+};
+MODULE_DEVICE_TABLE(of, ntc_match);
+
+static 

[PULL] virtio rng fix

[Rusty Russell]

The following changes since commit f7f154f1246ccc5a0a7e9ce50932627d60a0c878:

  hw_random: make buffer usable in scatterlist. (2013-03-05 10:11:41 +1030)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/fixes-for-linus

for you to fetch changes up to e84e7a56a3aa2963db506299e29a5f3f09377f9b:

  virtio: rng: disallow multiple device registrations, fixes crashes 
(2013-03-08 11:30:43 +1100)


Simple virtio-rng fix.

Thanks,
Rusty.


Amit Shah (1):
  virtio: rng: disallow multiple device registrations, fixes crashes

 drivers/char/hw_random/virtio-rng.c |   13 +++--
 1 file changed, 11 insertions(+), 2 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/

Linux IPMI subsystem hang

[Daniel Kahn Gillmor]

Hi Linux kernel folks (Corey is explicitly listed here because of being
the only contact i could find in IPMI.txt)--

I am working with a Lenovo ThinkCentre M78, model 4865-A14, and it seems
to have trouble with the IPMI subsystem.

udev seems to hang for about 3 minutes at startup, ultimately failing
with the following messages:

udevd[416]: worker [495] unexpectedly returned with status 0x0100
udevd[416]: worker [495] failed while handling 
'/devices/pci:00/:00:15.2/:03:00.3'

This hang happens whether i'm running linux kernel 3.2 or 3.8, using
either x86 or x86_64 kernels.

If i blacklist the following modules via /etc/modprobe.d/blacklist.conf,
then there is no hang on startup:

 blacklist ipmi_si
 blacklist ipmi_msghandler

The device in question appears this way to lspci:

03:00.3 IPMI SMIC interface [0c07]: Realtek Semiconductor Co., Ltd. Device 
[10ec:816c] (rev 01) (prog-if 01)
Subsystem: Lenovo Device [17aa:3089]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ipmi_si

This machine is a workstation, and i would be surprised if it actually
has a full-blown IPMI subsystem.  I can find no mention of IPMI in the
BIOS, or in lenovo's hardware maintenance manual [0] or user guide [1]
for this model.

So i suspect that this device is being mistaken for an IPMI device, or
that it is actually a broken/malformed IPMI device that shouldn't be
initialized.  Either that, or the IPMI module itself is doing something
wrong.

Can i do anything to help resolve this problem so that the machine boots
without delay and the ipmi subsystem doesn't get hung on this device?
Is there debugging output i can provide that would be useful, or any
other test you'd like me to run?

I'd be happy to report any requested details.  Also, if you want to
redirect me to a better forum for resolving this problem that would be
appreciated.

I am not subscribed to LKML, so please CC me on any replies.

Regards,

--dkg

[0] http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_pdf/m78_hmm.pdf
[1] 
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_pdf/m78_sff_ug_en.pdf


pgpIPocJc_mqJ.pgp
Description: PGP signature

Re: linux-next: unneeded merge in the security tree

[Theodore Ts'o]

On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
> Theodore Ts'o  writes:
> 
> > [remote "origin"]
> > url = 
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > fetch = +refs/heads/master:refs/heads/master
> > mergeoptions = --ff-only
> >
> 
> Is there an escape hatch for that rare case?  IOW, how does a
> submaintainer who configured the above to override --ff-only?

Hmm, maybe we would need to add a --no-ff-only?  Or they could just
do:

git fetch origin
git merge FETCH_HEAD

On Tue, Mar 12, 2013 at 02:28:39PM -0700, Linus Torvalds wrote:
>
> Of course, I'm not really sure if we want to list the flags. Maybe
> it's better to just introduce the notion of "upstream" directly, and
> make that a flag, and make "origin" default to that when you clone.
> And then have git use different heurstics for pulling upstream (like
> warning by default when doing a back-merge, perhaps?)

What if git automaticallly set up the origin branch to have a certain
set of mergeoptions by default?  That would probably be right for most
users, but it makes it obvious what's going on when they take a look
at the .git/config file, and doesn't make the remote that happens to
have the name "origin" as having certain magic properties.  Using a
set of mergeoptions would also be bit more general, and might have
applications in the future.

   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: Print the correct information in debugfs pinconf-state file

[Laurent Pinchart]

A bad copy resulted in the debugfs pinconf-state file printing the
pin name instead of the state name. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/pinctrl/pinconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 8aefd28..dae927f 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -622,7 +622,7 @@ static const struct file_operations 
pinconf_dbg_pinname_fops = {
 static int pinconf_dbg_state_print(struct seq_file *s, void *d)
 {
if (strlen(dbg_state_name))
-   seq_printf(s, "%s\n", dbg_pinname);
+   seq_printf(s, "%s\n", dbg_state_name);
else
seq_printf(s, "No pin state set\n");
return 0;
-- 
Regards,

Laurent Pinchart

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

[PATCH] USB: ehci-s5p: Fix phy reset

[Alexander Graf]

On my Exynos 5 based Arndale system, I need to pull the reset line down
and then let it go up again to actually perform a reset. Without that
reset, I can't find any USB hubs on my bus, rendering the USB controller
useless.

So this patch implements the above logic, making EHCI and OHCI work on
Arndale systems for me.

Signed-off-by: Alexander Graf 
CC: Vivek Gautam 
CC: Jingoo Han 
CC: Alan Stern 
CC: Kukjin Kim 
CC: Felipe Balbi 
CC: Greg Kroah-Hartman 

---

As this affects 3.9, this patch should definitely be considered for inclusion
there.
---
 drivers/usb/host/ehci-s5p.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..c6d67e4 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -103,9 +103,15 @@ static void s5p_setup_vbus_gpio(struct platform_device 
*pdev)
if (!gpio_is_valid(gpio))
return;
 
-   err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
-   if (err)
+   /* reset pulls the line down, then up again */
+   err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
+   if (err) {
dev_err(>dev, "can't request ehci vbus gpio %d", gpio);
+   return;
+   }
+   mdelay(1);
+   __gpio_set_value(gpio, 1);
+   gpio_free(gpio);
 }
 
 static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
-- 
1.7.12.4

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

Re: [PATCH v2] cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()

[Li Zefan]

On 2013/3/13 9:19, Tejun Heo wrote:
> On Wed, Mar 13, 2013 at 09:17:09AM +0800, Li Zefan wrote:
>> These two functions share most of the code.
>>
>> Signed-off-by: Li Zefan 
>> ---
>>
>> v2: Not necessary to move cgroup_attach_task_all().
> 
> I supposed this one is the one to apply?
> 

yep.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: Detect support for SDIV/UDIV from ISAR0 register

[Stephen Boyd]

The ISAR0 register indicates support for the SDIV and UDIV
instructions in both the Thumb and ARM instruction set. Read the
register to detect the supported instructions and update the
elf_hwcap mask as appropriate. This is better than adding more
and more cpuid checks in proc-v7.S for each new cpu variant that
supports these instructions.

Cc: Will Deacon 
Cc: Stepan Moskovchenko 
Signed-off-by: Stephen Boyd 
---
 arch/arm/kernel/setup.c | 20 
 arch/arm/mm/proc-v7.S   |  4 ++--
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e2c8bbf..bd27a70 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -353,6 +353,23 @@ void __init early_print(const char *str, ...)
printk("%s", buf);
 }
 
+static void __init idiv_setup(void)
+{
+   unsigned int divide_instrs;
+
+   if (cpu_architecture() < CPU_ARCH_ARMv7)
+   return;
+
+   divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
+
+   switch (divide_instrs) {
+   case 2:
+   elf_hwcap |= HWCAP_IDIVA;
+   case 1:
+   elf_hwcap |= HWCAP_IDIVT;
+   }
+}
+
 static void __init feat_v6_fixup(void)
 {
int id = read_cpuid_id();
@@ -483,6 +500,9 @@ static void __init setup_processor(void)
snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
 list->elf_name, ENDIANNESS);
elf_hwcap = list->elf_hwcap;
+
+   idiv_setup();
+
 #ifndef CONFIG_ARM_THUMB
elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT);
 #endif
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a3c015..bcd3d48 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -420,7 +420,7 @@ __v7_pj4b_proc_info:
 __v7_ca7mp_proc_info:
.long   0x410fc070
.long   0xff00
-   __v7_proc __v7_ca7mp_setup, hwcaps = HWCAP_IDIV
+   __v7_proc __v7_ca7mp_setup
.size   __v7_ca7mp_proc_info, . - __v7_ca7mp_proc_info
 
/*
@@ -430,7 +430,7 @@ __v7_ca7mp_proc_info:
 __v7_ca15mp_proc_info:
.long   0x410fc0f0
.long   0xff00
-   __v7_proc __v7_ca15mp_setup, hwcaps = HWCAP_IDIV
+   __v7_proc __v7_ca15mp_setup
.size   __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
 
/*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 1/3] ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n

[Stephen Boyd]

Don't advertise support for the SDIV/UDIV thumb instructions if
the kernel is not compiled with support for thumb userspace. This
is in line with how we remove the THUMB hwcap in these
configurations.

Cc: Will Deacon 
Cc: Stepan Moskovchenko 
Signed-off-by: Stephen Boyd 
---
 arch/arm/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..e2c8bbf 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -484,7 +484,7 @@ static void __init setup_processor(void)
 list->elf_name, ENDIANNESS);
elf_hwcap = list->elf_hwcap;
 #ifndef CONFIG_ARM_THUMB
-   elf_hwcap &= ~HWCAP_THUMB;
+   elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT);
 #endif
 
feat_v6_fixup();
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 0/3] Detect UDIV/SDIV support from ISAR0

[Stephen Boyd]

While attempting to upstream a patch to add the IDIV hwcap for
Krait processors, Will suggested we move the code to read the
ISAR0 register. This patchset does that and also works around
the early Krait CPU designs that don't follow the latest ARM ARM
for the ISAR0 register.

Stephen Boyd (3):
  ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n
  ARM: Detect support for SDIV/UDIV from ISAR0 register
  ARM: Work around faulty ISAR0 register in some Krait CPUs

 arch/arm/kernel/setup.c | 30 +-
 arch/arm/mm/proc-v7.S   |  4 ++--
 2 files changed, 31 insertions(+), 3 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs

[Stephen Boyd]

Some early versions of the Krait CPU design incorrectly indicate
that they only support the UDIV and SDIV instructions in Thumb
mode when they actually support them in ARM and Thumb mode. It
seems that these CPUs follow the DDI0406B ARM ARM which has two
possible values for the divide instructions field, instead of the
DDI0406C document which has three possible values.

Work around this problem by checking the MIDR against Krait CPUs
with this faulty ISAR0 register and force the detection code
to indicate support in both modes.

Cc: Will Deacon 
Cc: Stepan Moskovchenko 
Signed-off-by: Stephen Boyd 
---
 arch/arm/kernel/setup.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index bd27a70..34ec24e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -362,6 +362,14 @@ static void __init idiv_setup(void)
 
divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
 
+   /*
+* Some Krait processors don't indicate support for SDIV and UDIV
+* instructions in the ARM instruction set, even though they actually
+* do support them.
+*/
+   if ((read_cpuid_id() & 0xff0ffc00) == 0x510f0400)
+   divide_instrs = 2;
+
switch (divide_instrs) {
case 2:
elf_hwcap |= HWCAP_IDIVA;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH] ARM: proc: Add Krait proc info

[Stephen Boyd]

On 03/07/13 22:41, Will Deacon wrote:
> On Wed, Mar 06, 2013 at 05:20:32AM +, Stephen Boyd wrote:
>> On 03/05/13 14:03, Stephen Boyd wrote:
>>> On 03/05/13 00:34, Will Deacon wrote:
 I was looking at this the other day and wondered whether we could set
 HWCAP_IDIV in __v7_setup, depending on ID_ISAR0[27:24]. I can't immediately
 think why that would be difficult, but similarly there may well be a reason
 why we assign it like this.

 Fancy taking a look?
>>> Ok I'll take a look. 
>> Hmm. I wonder if we did it this way because between version B and C of
>> DDI0406 the definition of those bits changed.
>>
>> In DDI0406B we have
>>
>> 0 - no support
>> 1 - support
>>
>> and in DDI0406C we have
>>
>> 0 - no support
>> 1 - support in Thumb
>> 2 - support in Thumb and ARM
> Well spotted, although I think this a documentation error. I've checked both
> A7 and A15 and they both advertise '2' (although r0p0 TRM for A7 also gets
> this wrong, the CPU does the right thing).

What about the Cortex-R7? When I google "ARM ISAR0" the first hit is

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363e/Bgbfafej.html

and in there it just says 1.

> What about the Qualcomm CPUs?
>

It's set to 1 in some of our earlier Krait CPU designs, but we corrected
it later on to say 2 because the hardware actually supports the
instructions in both ARM and Thumb mode. Unfortunately, we mass produced
some of these chips that say 1 so we still need to do the same kind of
MIDR check. I'm going to send the patchset right now with all this in it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Bill Huang]

On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
> On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> > Add the below four notifier events so drivers which are interested in
> > knowing the clock status can act accordingly. This is extremely useful
> > in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
> > 
> > PRE_CLK_ENABLE
> > POST_CLK_ENABLE
> > PRE_CLK_DISABLE
> > POST_CLK_DISABLE
> > 
> > Signed-off-by: Bill Huang 
> 
> NAK.  *Sigh* NO, this is the wrong level to be doing stuff like this.
> 
> The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should
> *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and
> clk_unprepare().  Those two functions are *merely* helpers for drivers
> who don't wish to make the individual calls.
> 
> Drivers are still completely free to call the individual functions, at
> which point your proposal breaks horribly - and they _do_ call the
> individual functions.
I'm proposing to give device driver a choice when it knows that some
driver might be interested in knowing its clock's enabled/disabled state
change at runtime, this is very important for centralized DVFS core
driver. It is not meant to be covering all cases especially for drivers
which is not part of the DVFS, so we don't care if it is calling
clk_enable/disable directly or not.

One major side effect being that it affects those existing drivers who
were calling clk_prepare_enable and clk_prepare_disable but it should
not hurt if they don't care the notifier, or maybe we should define a
new set of functions for the purpose?

Mike, how do you think? 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: [PATCH v2] cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()

[Tejun Heo]

On Wed, Mar 13, 2013 at 09:17:09AM +0800, Li Zefan wrote:
> These two functions share most of the code.
> 
> Signed-off-by: Li Zefan 
> ---
> 
> v2: Not necessary to move cgroup_attach_task_all().

I supposed this one is the one to apply?

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

[PATCH v2] cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()

[Li Zefan]

These two functions share most of the code.

Signed-off-by: Li Zefan 
---

v2: Not necessary to move cgroup_attach_task_all().

---
 include/linux/cgroup.h |   3 +-
 kernel/cgroup.c| 109 +
 kernel/cpuset.c|   2 +-
 3 files changed, 23 insertions(+), 91 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 1f75a59..013c6ce 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -691,7 +691,8 @@ struct task_struct *cgroup_iter_next(struct cgroup *cgrp,
struct cgroup_iter *it);
 void cgroup_iter_end(struct cgroup *cgrp, struct cgroup_iter *it);
 int cgroup_scan_tasks(struct cgroup_scanner *scan);
-int cgroup_attach_task(struct cgroup *, struct task_struct *);
+int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk,
+  bool threadgroup);
 int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
 
 /*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 4b92b9a..c157f88 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -59,7 +59,7 @@
 #include  /* TODO: replace with more sophisticated array */
 #include 
 #include 
-#include  /* used in cgroup_attach_proc */
+#include  /* used in cgroup_attach_task */
 #include 
 
 #include 
@@ -1944,82 +1944,6 @@ static void cgroup_task_migrate(struct cgroup *cgrp, 
struct cgroup *oldcgrp,
 }
 
 /**
- * cgroup_attach_task - attach task 'tsk' to cgroup 'cgrp'
- * @cgrp: the cgroup the task is attaching to
- * @tsk: the task to be attached
- *
- * Call with cgroup_mutex and threadgroup locked. May take task_lock of
- * @tsk during call.
- */
-int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
-{
-   int retval = 0;
-   struct cgroup_subsys *ss, *failed_ss = NULL;
-   struct cgroup *oldcgrp;
-   struct cgroupfs_root *root = cgrp->root;
-   struct cgroup_taskset tset = { };
-   struct css_set *newcg;
-
-   /* @tsk either already exited or can't exit until the end */
-   if (tsk->flags & PF_EXITING)
-   return -ESRCH;
-
-   /* Nothing to do if the task is already in that cgroup */
-   oldcgrp = task_cgroup_from_root(tsk, root);
-   if (cgrp == oldcgrp)
-   return 0;
-
-   tset.single.task = tsk;
-   tset.single.cgrp = oldcgrp;
-
-   for_each_subsys(root, ss) {
-   if (ss->can_attach) {
-   retval = ss->can_attach(cgrp, );
-   if (retval) {
-   /*
-* Remember on which subsystem the can_attach()
-* failed, so that we only call cancel_attach()
-* against the subsystems whose can_attach()
-* succeeded. (See below)
-*/
-   failed_ss = ss;
-   goto out;
-   }
-   }
-   }
-
-   newcg = find_css_set(tsk->cgroups, cgrp);
-   if (!newcg) {
-   retval = -ENOMEM;
-   goto out;
-   }
-
-   cgroup_task_migrate(cgrp, oldcgrp, tsk, newcg);
-
-   for_each_subsys(root, ss) {
-   if (ss->attach)
-   ss->attach(cgrp, );
-   }
-
-out:
-   if (retval) {
-   for_each_subsys(root, ss) {
-   if (ss == failed_ss)
-   /*
-* This subsystem was the one that failed the
-* can_attach() check earlier, so we don't need
-* to call cancel_attach() against it or any
-* remaining subsystems.
-*/
-   break;
-   if (ss->cancel_attach)
-   ss->cancel_attach(cgrp, );
-   }
-   }
-   return retval;
-}
-
-/**
  * cgroup_attach_task_all - attach task 'tsk' to all cgroups of task 'from'
  * @from: attach to all cgroups of a given task
  * @tsk: the task to be attached
@@ -2033,7 +1957,7 @@ int cgroup_attach_task_all(struct task_struct *from, 
struct task_struct *tsk)
for_each_active_root(root) {
struct cgroup *from_cg = task_cgroup_from_root(from, root);
 
-   retval = cgroup_attach_task(from_cg, tsk);
+   retval = cgroup_attach_task(from_cg, tsk, false);
if (retval)
break;
}
@@ -2044,21 +1968,22 @@ int cgroup_attach_task_all(struct task_struct *from, 
struct task_struct *tsk)
 EXPORT_SYMBOL_GPL(cgroup_attach_task_all);
 
 /**
- * cgroup_attach_proc - attach all threads in a threadgroup to a cgroup
+ * cgroup_attach_task - attach a task or a whole threadgroup to a cgroup
  * @cgrp: the cgroup to attach to
- * @leader: the 

[PATCH v2] cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()

[Li Zefan]

These two functions share most of the code.

Signed-off-by: Li Zefan 
---

v2: not necessary to move cgroup_attach_task_all()

---
 include/linux/cgroup.h |   3 +-
 kernel/cgroup.c| 107 +
 kernel/cpuset.c|   2 +-
 3 files changed, 22 insertions(+), 90 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 1f75a59..013c6ce 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -691,7 +691,8 @@ struct task_struct *cgroup_iter_next(struct cgroup *cgrp,
struct cgroup_iter *it);
 void cgroup_iter_end(struct cgroup *cgrp, struct cgroup_iter *it);
 int cgroup_scan_tasks(struct cgroup_scanner *scan);
-int cgroup_attach_task(struct cgroup *, struct task_struct *);
+int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk,
+  bool threadgroup);
 int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
 
 /*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 4b92b9a..134d3c5 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -59,7 +59,7 @@
 #include  /* TODO: replace with more sophisticated array */
 #include 
 #include 
-#include  /* used in cgroup_attach_proc */
+#include  /* used in cgroup_attach_task */
 #include 
 
 #include 
@@ -1944,82 +1944,6 @@ static void cgroup_task_migrate(struct cgroup *cgrp, 
struct cgroup *oldcgrp,
 }
 
 /**
- * cgroup_attach_task - attach task 'tsk' to cgroup 'cgrp'
- * @cgrp: the cgroup the task is attaching to
- * @tsk: the task to be attached
- *
- * Call with cgroup_mutex and threadgroup locked. May take task_lock of
- * @tsk during call.
- */
-int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
-{
-   int retval = 0;
-   struct cgroup_subsys *ss, *failed_ss = NULL;
-   struct cgroup *oldcgrp;
-   struct cgroupfs_root *root = cgrp->root;
-   struct cgroup_taskset tset = { };
-   struct css_set *newcg;
-
-   /* @tsk either already exited or can't exit until the end */
-   if (tsk->flags & PF_EXITING)
-   return -ESRCH;
-
-   /* Nothing to do if the task is already in that cgroup */
-   oldcgrp = task_cgroup_from_root(tsk, root);
-   if (cgrp == oldcgrp)
-   return 0;
-
-   tset.single.task = tsk;
-   tset.single.cgrp = oldcgrp;
-
-   for_each_subsys(root, ss) {
-   if (ss->can_attach) {
-   retval = ss->can_attach(cgrp, );
-   if (retval) {
-   /*
-* Remember on which subsystem the can_attach()
-* failed, so that we only call cancel_attach()
-* against the subsystems whose can_attach()
-* succeeded. (See below)
-*/
-   failed_ss = ss;
-   goto out;
-   }
-   }
-   }
-
-   newcg = find_css_set(tsk->cgroups, cgrp);
-   if (!newcg) {
-   retval = -ENOMEM;
-   goto out;
-   }
-
-   cgroup_task_migrate(cgrp, oldcgrp, tsk, newcg);
-
-   for_each_subsys(root, ss) {
-   if (ss->attach)
-   ss->attach(cgrp, );
-   }
-
-out:
-   if (retval) {
-   for_each_subsys(root, ss) {
-   if (ss == failed_ss)
-   /*
-* This subsystem was the one that failed the
-* can_attach() check earlier, so we don't need
-* to call cancel_attach() against it or any
-* remaining subsystems.
-*/
-   break;
-   if (ss->cancel_attach)
-   ss->cancel_attach(cgrp, );
-   }
-   }
-   return retval;
-}
-
-/**
  * cgroup_attach_task_all - attach task 'tsk' to all cgroups of task 'from'
  * @from: attach to all cgroups of a given task
  * @tsk: the task to be attached
@@ -2033,7 +1957,7 @@ int cgroup_attach_task_all(struct task_struct *from, 
struct task_struct *tsk)
for_each_active_root(root) {
struct cgroup *from_cg = task_cgroup_from_root(from, root);
 
-   retval = cgroup_attach_task(from_cg, tsk);
+   retval = cgroup_attach_task(from_cg, tsk, false);
if (retval)
break;
}
@@ -2044,21 +1968,22 @@ int cgroup_attach_task_all(struct task_struct *from, 
struct task_struct *tsk)
 EXPORT_SYMBOL_GPL(cgroup_attach_task_all);
 
 /**
- * cgroup_attach_proc - attach all threads in a threadgroup to a cgroup
+ * cgroup_attach_task - attach a task or a whole threadgroup to a cgroup
  * @cgrp: the cgroup to attach to
- * @leader: the 

Re: [PATCH] bounce:fix bug, avoid to flush dcache on slab page from jbd2.

[Darrick J. Wong]

On Tue, Mar 12, 2013 at 03:32:21PM -0700, Andrew Morton wrote:
> On Fri, 08 Mar 2013 20:37:36 +0800 Shuge  wrote:
> 
> > The bounce accept slab pages from jbd2, and flush dcache on them.
> > When enabling VM_DEBUG, it will tigger VM_BUG_ON in page_mapping().
> > So, check PageSlab to avoid it in __blk_queue_bounce().
> > 
> > Bug URL: http://lkml.org/lkml/2013/3/7/56
> > 
> > ...
> >
> > --- a/mm/bounce.c
> > +++ b/mm/bounce.c
> > @@ -214,7 +214,8 @@ static void __blk_queue_bounce(struct request_queue 
> > *q, struct bio **bio_orig,
> > if (rw == WRITE) {
> > char *vto, *vfrom;
> >   - flush_dcache_page(from->bv_page);
> > +   if (unlikely(!PageSlab(from->bv_page)))
> > +   flush_dcache_page(from->bv_page);
> > vto = page_address(to->bv_page) + to->bv_offset;
> > vfrom = kmap(from->bv_page) + from->bv_offset;
> > memcpy(vto, vfrom, to->bv_len);
> 
> I guess this is triggered by Catalin's f1a0c4aa0937975b ("arm64: Cache
> maintenance routines"), which added a page_mapping() call to arm64's
> arch/arm64/mm/flush.c:flush_dcache_page().
> 
> What's happening is that jbd2 is using kmalloc() to allocate buffer_head
> data.  That gets submitted down the BIO layer and __blk_queue_bounce()
> calls flush_dcache_page() which in the arm64 case calls page_mapping()
> and page_mapping() does VM_BUG_ON(PageSlab) and splat.
> 
> The unusual thing about all of this is that the payload for some disk
> IO is coming from kmalloc, rather than being a user page.  It's oddball
> but we've done this for ages and should continue to support it.
> 
> 
> Now, the page from kmalloc() cannot be in highmem, so why did the
> bounce code decide to bounce it?
> 
> __blk_queue_bounce() does
> 
>   /*
>* is destination page below bounce pfn?
>*/
>   if (page_to_pfn(page) <= queue_bounce_pfn(q) && !force)
>   continue;
> 
> and `force' comes from must_snapshot_stable_pages().  But
> must_snapshot_stable_pages() must have returned false, because if it
> had returned true then it would have been must_snapshot_stable_pages()
> which went BUG, because must_snapshot_stable_pages() calls page_mapping().
> 
> So my tentative diagosis is that arm64 is fishy.  A page which was
> allocated via jbd2_alloc(GFP_NOFS)->kmem_cache_alloc() ended up being
> above arm64's queue_bounce_pfn().  Can you please do a bit of
> investigation to work out if this is what is happening?  Find out why
> __blk_queue_bounce() decided to bounce a page which shouldn't have been
> bounced?

That sure is strange.  I didn't see any obvious reasons why we'd end up with a
kmalloc above queue_bounce_pfn().  But then I don't have any arm64s either.

> This is all terribly fragile :( afaict if someone sets
> bdi_cap_stable_pages_required() against that jbd2 queue, we're going to
> hit that BUG_ON() again, via must_snapshot_stable_pages()'s
> page_mapping() call.  (Darrick, this means you ;))

Wh.  You're right, we shouldn't be calling page_mapping on slab pages.
We can keep walking the bio segments to find a non-slab page that can tell us
MS_SNAP_STABLE is set, since we probably won't need the bounce buffer anyway.

How does something like this look?  (+ the patch above)

--D

Subject: [PATCH] mm: Don't blow up on slab pages being written to disk

Don't assume that all pages attached to a bio are non-slab pages.  This happens
if (for example) jbd2 allocates a buffer out of the slab to hold frozen data.
If we encounter a slab page, just ignore the page and keep searching.
Hopefully filesystems are smart enough to guarantee that slab pages won't
be dirtied while they're also being written to disk.

Signed-off-by: Darrick J. Wong 
---
 mm/bounce.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/bounce.c b/mm/bounce.c
index 5f89017..af34855 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -199,6 +199,8 @@ static int must_snapshot_stable_pages(struct request_queue 
*q, struct bio *bio)
 */
bio_for_each_segment(from, bio, i) {
page = from->bv_page;
+   if (PageSlab(page))
+   continue;
mapping = page_mapping(page);
if (!mapping)
continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] cgroup: a bunch of cleanups

[Li Zefan]

On 2013/3/13 6:38, Tejun Heo wrote:
> On Tue, Mar 12, 2013 at 02:49:52PM +0800, Li Zefan wrote:
>> Hi Tejun,
>>
>> If you're busy with other stuff, just take your time to go through those
>> patches.
>>
>> 0001-cgroup-remove-cgroup_is_descentant.patch
>> 0002-cgroup-remove-unused-variables-in-cgroup_destroy_loc.patch
>> 0003-cgroup-hold-cgroup_mutex-before-calling-css_offline.patch
>> 0004-cgroup-don-t-bother-to-resize-pid-array.patch
>> 0005-cgroup-remove-useless-code-in-cgroup_write_event_con.patch
>> 0006-cgroup-remove-unneeded-includes-from-cgroup.h.patch
>> 0007-cgroup-fix-an-almost-harmless-off-by-one-bug.patch
>> 0008-cgroup-consolidate-cgroup_attach_task-and-cgroup_att.patch
> 
> 0001-0007 applied to cgroup/for-3.10.  0008 looks fine but in the diff
> cgroup_attach_task_all() is removed completely and added back in
> slightly different form.

At first I thought cgroup_attach_task() was static, so I thought I had
to either move cgroup_attach_task_all() after cgroup_attach_task(),
or add a forward declaration of cgroup_attach_task() in order to pass
compile.

Then I found it was extern, but I forgot to revert this diff.

Will send a v2.

> If you wanna keep the functions ordered like
> you posted, please put a separate patch to move
> cgroup_attach_task_all() before the consolidation.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: keep __my_cpu_offset consistent with generic one

[Ming Lei]

On Wed, Mar 13, 2013 at 1:25 AM, Tejun Heo  wrote:
> Hello,
>
> On Tue, Mar 12, 2013 at 07:44:55PM +0800, Ming Lei wrote:
>> On Tue, Mar 12, 2013 at 7:30 PM, Russell King - ARM Linux
>>  wrote:
>> >>
>> >> Ingo and Peter, what is your opinion on the problem?
>> >
>> > Having discussed this with Ben Herrenschmidt, it seems that we do need
>> > to have a more complex patch to sort this out - we need to setup our
>> > private pointer inside setup_per_cpu_areas().
>>
>> Suppose so, seems the patch is still needed to make CPU0 see
>> static variables in '.data..percpu' section correctly.
>
> If my memory serves me right, x86 also has places where CPU0 accesses
> its per-cpu data in .data.percpu.  While those existed (not sure
> they're still there but probably they're) mostly due to historical
> reasons rather than by design, as long as the data is in consistent
> state by and during percpu setup, nothing will break.

Tejun, thanks for your input, yes, nothing will break.  For lockdep,
the percpu variables in non-boot-CPUs may be initialized again after
percpu area is set up.


Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] backlight: da903x_bl: use BL_CORE_SUSPENDRESUME option

[Jingoo Han]

Use BL_CORE_SUSPENDRESUME option to support suspend/resume.
It reduces code size.

Signed-off-by: Jingoo Han 
Cc: Lars-Peter Clausen 
---
 drivers/video/backlight/da903x_bl.c |   30 +-
 1 files changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/video/backlight/da903x_bl.c 
b/drivers/video/backlight/da903x_bl.c
index 8179cef..67cadd3 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -88,16 +88,21 @@ static int da903x_backlight_update_status(struct 
backlight_device *bl)
if (bl->props.fb_blank != FB_BLANK_UNBLANK)
brightness = 0;
 
+   if (bl->props.state & BL_CORE_SUSPENDED)
+   brightness = 0;
+
return da903x_backlight_set(bl, brightness);
 }
 
 static int da903x_backlight_get_brightness(struct backlight_device *bl)
 {
struct da903x_backlight_data *data = bl_get_data(bl);
+
return data->current_brightness;
 }
 
 static const struct backlight_ops da903x_backlight_ops = {
+   .options= BL_CORE_SUSPENDRESUME,
.update_status  = da903x_backlight_update_status,
.get_brightness = da903x_backlight_get_brightness,
 };
@@ -161,35 +166,10 @@ static int da903x_backlight_remove(struct platform_device 
*pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int da903x_backlight_suspend(struct device *dev)
-{
-   struct backlight_device *bl = dev_get_drvdata(dev);
-
-   return da903x_backlight_set(bl, 0);
-}
-
-static int da903x_backlight_resume(struct device *dev)
-{
-   struct backlight_device *bl = dev_get_drvdata(dev);
-
-   backlight_update_status(bl);
-   return 0;
-}
-
-static const struct dev_pm_ops da903x_backlight_pm_ops = {
-   .suspend= da903x_backlight_suspend,
-   .resume = da903x_backlight_resume,
-};
-#endif
-
 static struct platform_driver da903x_backlight_driver = {
.driver = {
.name   = "da903x-backlight",
.owner  = THIS_MODULE,
-#ifdef CONFIG_PM
-   .pm = _backlight_pm_ops,
-#endif
},
.probe  = da903x_backlight_probe,
.remove = da903x_backlight_remove,
-- 
1.7.2.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: linux-3.6.11-rt30 smoke test on ARM

[Frank Rowand]

On 03/11/13 10:34, Sebastian Andrzej Siewior wrote:
> * Frank Rowand | 2013-03-07 20:03:18 [-0800]:
> 
>> panda boot often fails due to a usb timeout, while sending a command on
>> behalf of the smsc95xx ethernet driver.
>>
>> This patch is a temporary hack to force a retry when the timeout occurs.
> 
> It looks like you overrun the chip for some reason. Can you reproduce it
> on mainline? They added a few delayes on register read() it might do the
> trick.

Yes, I can reproduce it on mainline.

Here is the current state of my debugging:

The problem usually occurs within three boot attempts.  But it has also
taken eight boot attempts to see the problem.  I do not know what the
maximum number of boots is required to see the problem, so I can not
state with certainty that a given kernel version does not have the
problem.  If the boot fails then I can state with certainty that the
given kernel version has the problem.

Given that level of uncertainty, I know:

  v3.5  does not appear to have the problem
  v3.6-rc1  has the problem
  v3.6  has the problem
  v3.7  has the problem
  v3.8  does not appear to have the problem
  v3.9-rc1  fails to build

I thought I had bisected the problem to a specific commit, but wanting
to be sure of it, I did extra boots of what should have been the last
good commit.  On the 7th boot, that kernel version had the problem.

I'll probably redo the bisect, but have not had time to do so yet.

The problem manifests as a timeout from at least two different locations
in drivers/net/usb/smsc95xx.c:


 656 static int smsc95xx_set_mac_address(struct usbnet *dev)
 657 {
 ...
 663 ret = smsc95xx_write_reg(dev, ADDRL, addr_lo);
 664 if (ret < 0) {
 665 netdev_warn(dev->net, "Failed to write ADDRL: %d\n", ret);
 666 return ret;
 667 }


751 static int smsc95xx_reset(struct usbnet *dev)
 752 {
 ...
 783 write_buf = PM_CTL_PHY_RST_;
 784 ret = smsc95xx_write_reg(dev, PM_CTRL, write_buf);
 785 if (ret < 0) {
 786 netdev_warn(dev->net, "Failed to write PM_CTRL: %d\n", 
ret);
 787 return ret;
 788 }


Some of the other smsc95xx_write_reg() calls in smsc95xx_reset() are protected 
with
checks for timeout, with up to 100 retries.  I do not know if this one should 
have
the same protection.

-Frank

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

[Tejun Heo]

On Thu, Mar 07, 2013 at 01:44:06PM -0800, Tejun Heo wrote:
> Implement a function which queries whether it currently is running off
> a workqueue rescuer.  This will be used to convert writeback to
> workqueue.
> 
> Signed-off-by: Tejun Heo 

Applied this one to wq/for-3.10.

Thanks.

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

Re: [PATCH] backlight: da903x_bl: switch to using SIMPLE_DEV_PM_OPS

[Jingoo Han]

On Wednesday, March 13, 2013 4:03 AM, Lars-Peter Clausen wrote:
> 
> On 03/12/2013 06:48 AM, Jingoo Han wrote:
> > This reduces #ifdefs in the code. Also, CONFIG_PM_SLEEP is used
> > to avoid warnings of unused functions if CONFIG_PM_SLEEP is not
> > defined.
> >
> > Signed-off-by: Jingoo Han 
> 
> I think you can eliminate the suspend/resume functions all together by using
> the blacklight subsystems CORE_SUSPENDRESUME feature.

Hi Lars-Peter Clausen,

Yes, you're right.
I will use CORE_SUSPENDRESUME feature.
Thank you for your comment :)

Best regards,
Jingoo Han

> 
> E.g.
> 
> diff --git a/drivers/video/backlight/da903x_bl.c
> b/drivers/video/backlight/da903x_bl.c
> index 8179cef..80ba6b3 100644
> --- a/drivers/video/backlight/da903x_bl.c
> +++ b/drivers/video/backlight/da903x_bl.c
> @@ -88,6 +88,9 @@ static int da903x_backlight_update_status(struct
>   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
>   brightness = 0;
> 
> + if (bl->props.state & BL_CORE_SUSPENDED)
> + brightness = 0;
> +
>   return da903x_backlight_set(bl, brightness);
>  }
> 
> @@ -100,6 +103,7 @@ static int da903x_backlight_get_brightness(struct
>  static const struct backlight_ops da903x_backlight_ops = {
>   .update_status  = da903x_backlight_update_status,
>   .get_brightness = da903x_backlight_get_brightness,
> + .options= BL_CORE_SUSPENDRESUME,
>  };
> 
>  static int da903x_backlight_probe(struct platform_device *pdev)
> @@ -161,35 +165,10 @@ static int da903x_backlight_remove(struct
>   return 0;
>  }
> 
> -#ifdef CONFIG_PM
> -static int da903x_backlight_suspend(struct device *dev)
> -{
> - struct backlight_device *bl = dev_get_drvdata(dev);
> -
> - return da903x_backlight_set(bl, 0);
> -}
> -
> -static int da903x_backlight_resume(struct device *dev)
> -{
> - struct backlight_device *bl = dev_get_drvdata(dev);
> -
> - backlight_update_status(bl);
> - return 0;
> -}
> -
> -static const struct dev_pm_ops da903x_backlight_pm_ops = {
> - .suspend= da903x_backlight_suspend,
> - .resume = da903x_backlight_resume,
> -};
> -#endif
> -
>  static struct platform_driver da903x_backlight_driver = {
>   .driver = {
>   .name   = "da903x-backlight",
>   .owner  = THIS_MODULE,
> -#ifdef CONFIG_PM
> - .pm = _backlight_pm_ops,
> -#endif
>   },
>   .probe  = da903x_backlight_probe,
>   .remove = da903x_backlight_remove,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next] linux/linkage.h: fix symbol prefix handling

[Rusty Russell]

Stephen Rothwell  writes:

> Hi Rusty,
>
> Looks partly better.   You seem to be using
> CONFIG_SYMBOL_PREFIX_UNDERSCORE but selecting
> CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.  One trivial comment below.
>
> Maybe this was an unfinished version of the patch?

Indeed.  It was crap now I've applied James' copious fixes, and
actually, y'know, proof-read it.

This is what I'll push into my fixes/ branch now, and if it survives a
day in linux-next, will push to Linus.

Thanks,
Rusty.

v2: Rename CONFIG_SYMBOL_PREFIX_UNDERSCORE to
CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX, which is defined in
arch/Kconfig and selected by the 3 archs which need it.

v3: Clean up remnants of v1, s/VMLINUX_SYMBOL_NAME/VMLINUX_SYMBOL_STR/
in description, note that Al's commit is in linux-next only,
remove whitespace-only hunk.

CONFIG_SYMBOL_PREFIX: cleanup.

We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
"_".  But Al Viro broke this in "consolidate cond_syscall and
SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
do so.

Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
prefix it so something.  So various places define helpers which are
defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:

1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
   CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
   for pasting.

(arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).

Let's solve this properly:
1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
2) Make linux/export.h usable from asm.
3) Define VMLINUX_SYMBOL, VMLINUX_SYMBOL_STR and VMLINUX_SYMBOL_PREFIX_STR.
4) Make everyone use them.

Signed-off-by: Rusty Russell 
Reviewed-by: James Hogan 
Tested-by: James Hogan  (on metag)

diff --git a/Makefile b/Makefile
index a05ea42..10fb6c7 100644
--- a/Makefile
+++ b/Makefile
@@ -1398,7 +1398,7 @@ quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN   
$(wildcard $(rm-files))
 # Run depmod only if we have System.map and depmod is executable
 quiet_cmd_depmod = DEPMOD  $(KERNELRELEASE)
   cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
-   $(KERNELRELEASE) "$(patsubst "%",%,$(CONFIG_SYMBOL_PREFIX))"
+   $(KERNELRELEASE) "$(patsubst 
y,_,$(CONFIG_HAVE_SYMBOL_PREFIX_UNDERSCORE))"
 
 # Create temporary dir for module support files
 # clean it up only when building all modules
diff --git a/arch/Kconfig b/arch/Kconfig
index 5a1779c..12ba8f9 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -391,6 +391,12 @@ config MODULES_USE_ELF_REL
  Modules only use ELF REL relocations.  Modules with ELF RELA
  relocations will give an error.
 
+config HAVE_UNDERSCORE_SYMBOL_PREFIX
+   bool
+   help
+ Some architectures generate an _ in front of C symbols; things like
+ module loading and assembly files need to know about this.
+
 #
 # ABI hall of shame
 #
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 600494c..314ee6a 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -1,7 +1,3 @@
-config SYMBOL_PREFIX
-   string
-   default "_"
-
 config MMU
def_bool n
 
@@ -33,6 +29,7 @@ config BLACKFIN
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_UID16
+   select HAVE_UNDERSCORE_SYMBOL_PREFIX
select HAVE_VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_GENERIC_HARDIRQS
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index ae8551e..2333cf6 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -12,10 +12,7 @@ config H8300
select MODULES_USE_ELF_RELA
select OLD_SIGSUSPEND3
select OLD_SIGACTION
-
-config SYMBOL_PREFIX
-   string
-   default "_"
+   select HAVE_UNDERSCORE_SYMBOL_PREFIX
 
 config MMU
bool
diff --git a/arch/metag/Kconfig b/arch/metag/Kconfig
index afc8973..2099617 100644
--- a/arch/metag/Kconfig
+++ b/arch/metag/Kconfig
@@ -1,7 +1,3 @@
-config SYMBOL_PREFIX
-   string
-   default "_"
-
 config METAG
def_bool y
select EMBEDDED
@@ -27,6 +23,7 @@ config METAG
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_PERF_EVENTS
select HAVE_SYSCALL_TRACEPOINTS
+   select HAVE_UNDERSCORE_SYMBOL_PREFIX
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select OF
diff --git a/drivers/mtd/chips/gen_probe.c b/drivers/mtd/chips/gen_probe.c
index 3b9a284..00d20ad 100644
--- a/drivers/mtd/chips/gen_probe.c
+++ b/drivers/mtd/chips/gen_probe.c
@@ 

Re: [PATCH 5/6][v4]: perf: Create a sysfs entry for Power event format

[Michael Ellerman]

On Tue, Mar 12, 2013 at 08:27:40PM +1100, Paul Mackerras wrote:
> On Tue, Mar 05, 2013 at 09:48:26PM -0800, Sukadev Bhattiprolu wrote:
> > Michael Ellerman [mich...@ellerman.id.au] wrote:
> > | I suspect Arnaldo was either waiting for an ACK from Ben, or was
> > | expecting Ben to take it?
> > 
> > Arnaldo, here is an updated patch. If it is acked by Paul Mackerras,
> > Michael Ellerman or Ben, will you add it to your tree so the whole
> > patchset comes from one place ?
> > 
> > Sukadev
> > 
> > ---
> > >From 50c7a46f14083c0ed10d66b7aed66ba76e798550 Mon Sep 17 00:00:00 2001
> > From: Sukadev Bhattiprolu 
> > Date: Tue, 5 Mar 2013 21:20:56 -0800
> > Subject: [PATCH] [PATCH 5/6][v4]: perf Create a sysfs format entry for 
> > Power7 events
> > 
> > Create a sysfs entry, '/sys/bus/event_source/devices/cpu/format/event'
> > which describes the format of the POWER7 PMU events.
> > 
> > This code is based on corresponding code in x86.
> > 
> > Changelog[v4]:  [Michael Ellerman, Paul Mckerras] The event format is 
> > different
> > for other POWER cpus. So move the code to POWER7-specific,
> > power7-pmu.c Also, the POWER7 format uses bits 0-19 not 0-20.
> > 
> > Changelog[v2]: [Jiri Osla] Use PMU_FORMAT_ATTR rather than duplicating code.
> > 
> > Signed-off-by: Sukadev Bhattiprolu 
> 
> Acked-by: Paul Mackerras 

Tested-by: Michael Ellerman 

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

Re: [PATCH linux-next] procfs: fix rcu-lock/unlock in proc_reg_open() and proc_reg_release()

[Peter Hurley]

On Thu, 2013-03-07 at 11:21 +0400, Konstantin Khlebnikov wrote:
> fix for a21813be23329e2788164eab532e79cb0e513cfc (linux-next)
> "procfs: improve scaling in proc"
> 
> Signed-off-by: Konstantin Khlebnikov 
> Cc: Nathan Zimmer 
> Cc: Andrew Morton 

Konstantin,

Thanks for fixing this. Now -next boots once again :)

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] allow alternative name for PXA serial console

[Сергей Янович]

On 13 March 2013 03:39, Greg Kroah-Hartman  wrote:
> On Wed, Mar 13, 2013 at 03:34:59AM +0400, Сергей Янович wrote:
>> 
>> * Non-8250 serial port support
>> *
>> PXA serial port support (SERIAL_PXA) [Y/n/?] y
>>   Console on PXA serial port (SERIAL_PXA_CONSOLE) [Y/n/?] y
>>   as /dev/ttySA[0-3] (SERIAL_PXA_TTYSA_NAME) [N/y/?] (NEW)
>
> Please make it sane for the single line it is on.

"PXA serial port with SA-1100 major"
"PXA serial port with SA-1100 major number"
"PXA serial port with SA-1100 major device number"

Could anything like that be acceptable?

How long a line could be?

>> Maybe I am missing something obvious, but it seems that such a
>> collision is a kernel bug. Someone assumed that PXA cannot have a 8250
>> tty device and used 8250's parameters in PXA tty driver.
>
> Yes, someone must have messed up, so care to find the root problem here?

Two drivers try to use the same resource. It was in pre-git era, so it
difficult to find out exactly. I would guess that that 8250 have
precedence by at least 5 years. But it is almost guaranteed that lots
of people depend on PXA console having ttyS0 name. So simple
s/ttyS/ttySA/ is not a solution. My patch preserves status quo by
default, but allows to have a correct workaround for those who face a
collision. By correct I mean that it will not create a new collision
since a system cannot run on both SA-1100 and PXA270 at the same time.
This assumption is already documented in
arch/arm/mach-pxa/include/mach/irqs.h line 94.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: ipu: ipu_idmac: Fix section mismatch

[Fabio Estevam]

From: Fabio Estevam 

Since commit 84c1e63c12 (dma: Remove erroneous __exit and __exit_p() references)
the following section mismatch happens:

WARNING: drivers/built-in.o(.text+0x20f94): Section mismatch in reference from 
the function ipu_remove() to the function .exit.text:ipu_idmac_exit()
The function ipu_remove() references a function in an exit section.
Often the function ipu_idmac_exit() has valid usage outside the exit section
and the fix is to remove the __exit annotation of ipu_idmac_exit.

Remove the '__exit' annotation from ipu_idmac_exit in order to fix it. 

Signed-off-by: Fabio Estevam 
---
 drivers/dma/ipu/ipu_idmac.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index d6d5d7e..d39c2cd 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1642,7 +1642,7 @@ static int __init ipu_idmac_init(struct ipu *ipu)
return dma_async_device_register(>dma);
 }
 
-static void __exit ipu_idmac_exit(struct ipu *ipu)
+static void ipu_idmac_exit(struct ipu *ipu)
 {
int i;
struct idmac *idmac = >idmac;
-- 
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 2/2] ARM: imx_v6_v7_defconfig: Select CONFIG_W1_MASTER_MXC

[Fabio Estevam]

Hi Greg,

On Tue, Mar 12, 2013 at 8:24 PM, Greg KH  wrote:
> On Mon, Mar 11, 2013 at 08:18:16PM -0300, Fabio Estevam wrote:
>> From: Fabio Estevam 
>>
>> Select CONFIG_W1_MASTER_MXC.
>
> Why?  Don't tell me what you did, that's obvious, it's the story that is
> needed.
>
> dropped from my queue.

Ok, I will improve the commit log and re-submit it to linux-arm-kernel
list, so that it can go via arm tree and avoid any conflict.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] allow alternative name for PXA serial console

[Greg Kroah-Hartman]

On Wed, Mar 13, 2013 at 03:34:59AM +0400, Сергей Янович wrote:
> On 13 March 2013 03:10, Greg Kroah-Hartman  wrote:
> > On Wed, Mar 13, 2013 at 03:02:22AM +0400, Sergey Yanovich wrote:
> >> +config SERIAL_PXA_TTYSA_NAME
> >> + bool "as /dev/ttySA[0-3]"
> >
> > Does that config text really make sense?  What does it look like when
> > you run "make oldconfig"?
> 
> 
> * Non-8250 serial port support
> *
> PXA serial port support (SERIAL_PXA) [Y/n/?] y
>   Console on PXA serial port (SERIAL_PXA_CONSOLE) [Y/n/?] y
>   as /dev/ttySA[0-3] (SERIAL_PXA_TTYSA_NAME) [N/y/?] (NEW)

Please make it sane for the single line it is on.

> So the kernel will have PXA serial port, a console on it, and it will
> have a name (and numbers) /dev/ttySA0 to /dev/ttySA3.
> 
> >> ICP DAS LP-8x4x is an industrial data acquision device. It is based
> >> on PXA270 CPU. The board containsi a lot of (up to 36) standard UARTi
> >> 8250i serial ports. System console on the board is provided with
> >> an on-chip PXA serial port. Both modules use /dev/ttyS0 by default.
> >>
> >> To solve the collision, PXA ports could be configured with different
> >> name and device numbers.
> 
> > Ugh, why does it matter what it is named?
> >
> > Use udev, or a tool like it, to rename serial ports if you really need
> > it, don't do this in the kernel please.
> 
> It doesn't matter what it is named. It matters that both drivers try
> to use the same major device number. I have to change major device
> number for PXA tty, as a result I need a different name in /dev
> 
> Maybe I am missing something obvious, but it seems that such a
> collision is a kernel bug. Someone assumed that PXA cannot have a 8250
> tty device and used 8250's parameters in PXA tty driver.

Yes, someone must have messed up, so care to find the root problem here?

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] fuse: Fix build after change to synchronize with library

[Arve Hjønnevåg]

On Tue, Mar 12, 2013 at 2:02 AM, Miklos Szeredi  wrote:
> On Mon, 2013-03-11 at 15:54 -0700, Arve Hjønnevåg wrote:
>> __linux__ is not always defined so check __KERNEL__ as well.
>>
>> Signed-off-by: Arve Hjønnevåg 
>> ---
>>  include/uapi/linux/fuse.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
>> index 4c43b44..fc5d400 100644
>> --- a/include/uapi/linux/fuse.h
>> +++ b/include/uapi/linux/fuse.h
>> @@ -95,7 +95,7 @@
>>  #ifndef _LINUX_FUSE_H
>>  #define _LINUX_FUSE_H
>>
>> -#ifdef __linux__
>> +#if defined(__KERNEL__) || defined(__linux__)
>
> Or how about just
>
> #ifdef __KERNEL__
>

I don't think that will give you the same behavior when compiling
user-space code.

-- 
Arve Hjønnevå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] allow alternative name for PXA serial console

[Сергей Янович]

On 13 March 2013 03:10, Greg Kroah-Hartman  wrote:
> On Wed, Mar 13, 2013 at 03:02:22AM +0400, Sergey Yanovich wrote:
>> +config SERIAL_PXA_TTYSA_NAME
>> + bool "as /dev/ttySA[0-3]"
>
> Does that config text really make sense?  What does it look like when
> you run "make oldconfig"?


* Non-8250 serial port support
*
PXA serial port support (SERIAL_PXA) [Y/n/?] y
  Console on PXA serial port (SERIAL_PXA_CONSOLE) [Y/n/?] y
  as /dev/ttySA[0-3] (SERIAL_PXA_TTYSA_NAME) [N/y/?] (NEW)
-

So the kernel will have PXA serial port, a console on it, and it will
have a name (and numbers) /dev/ttySA0 to /dev/ttySA3.

>> ICP DAS LP-8x4x is an industrial data acquision device. It is based
>> on PXA270 CPU. The board containsi a lot of (up to 36) standard UARTi
>> 8250i serial ports. System console on the board is provided with
>> an on-chip PXA serial port. Both modules use /dev/ttyS0 by default.
>>
>> To solve the collision, PXA ports could be configured with different
>> name and device numbers.

> Ugh, why does it matter what it is named?
>
> Use udev, or a tool like it, to rename serial ports if you really need
> it, don't do this in the kernel please.

It doesn't matter what it is named. It matters that both drivers try
to use the same major device number. I have to change major device
number for PXA tty, as a result I need a different name in /dev

Maybe I am missing something obvious, but it seems that such a
collision is a kernel bug. Someone assumed that PXA cannot have a 8250
tty device and used 8250's parameters in PXA tty driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] leds: Add support for Palmas LEDs

[Ian Lartey]

On 12/03/13 18:57, Bryan Wu wrote:

On Thu, Feb 28, 2013 at 7:21 AM, Ian Lartey  wrote:

The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.

Signed-off-by: Graeme Gregory 
Signed-off-by: Ian Lartey 
---
  drivers/leds/leds-palmas.c |  560 
  include/linux/mfd/palmas.h |   60 +
  2 files changed, 620 insertions(+), 0 deletions(-)
  create mode 100644 drivers/leds/leds-palmas.c

diff --git a/drivers/leds/leds-palmas.c b/drivers/leds/leds-palmas.c
new file mode 100644
index 000..73adb32
--- /dev/null
+++ b/drivers/leds/leds-palmas.c
@@ -0,0 +1,560 @@
+/*
+ * Driver for LED part of Palmas PMIC Chips
+ *
+ * Copyright 2011 Texas Instruments Inc.
+ *


Please update this date, like 2011 - 2013.


Hello Bryan,

This patchset has been superseded by "v8 Palmas Update"
and for the LED driver in particular by
"[PATCH v8 09/12] leds: Add support for Palmas LEDs"

I will however incorporate the necessary changes you have
suggested here into the v9 patchset (minus the spinlock change)

I'll also make sure I cc you on the v9 patchset.

Regards,

Ian



+ * Author: Graeme Gregory 
+ * Author: Ian Lartey 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under  the terms of the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct palmas_leds_data;
+
+struct palmas_led {
+   struct led_classdev cdev;
+   struct palmas_leds_data *leds_data;
+   int led_no;
+   struct work_struct work;
+   struct mutex mutex;
+
+   spinlock_t value_lock;
+


I think you don't need this spinlock to protect the value, the mutex is enough.


+   int blink;
+   int on_time;
+   int period;
+   enum led_brightness brightness;
+};
+
+struct palmas_leds_data {
+   struct device *dev;
+   struct led_classdev cdev;
+   struct palmas *palmas;
+
+   struct palmas_led *palmas_led;
+   int no_leds;
+};
+
+#define to_palmas_led(led_cdev) \
+   container_of(led_cdev, struct palmas_led, cdev)
+
+#define LED_ON_62_5MS  0x00
+#define LED_ON_125MS   0x01
+#define LED_ON_250MS   0x02
+#define LED_ON_500MS   0x03
+
+#define LED_PERIOD_OFF 0x00
+#define LED_PERIOD_125MS   0x01
+#define LED_PERIOD_250MS   0x02
+#define LED_PERIOD_500MS   0x03
+#define LED_PERIOD_1000MS  0x04
+#define LED_PERIOD_2000MS  0x05
+#define LED_PERIOD_4000MS  0x06
+#define LED_PERIOD_8000MS  0x07
+
+
+static char *palmas_led_names[] = {
+   "palmas:led1",
+   "palmas:led2",
+   "palmas:led3",
+   "palmas:led4",
+};
+
+static int palmas_led_read(struct palmas_leds_data *leds, unsigned int reg,
+   unsigned int *dest)
+{
+   return palmas_read(leds->palmas, PALMAS_LED_BASE, reg, dest);
+}
+
+static int palmas_led_write(struct palmas_leds_data *leds, unsigned int reg,
+   unsigned int value)
+{
+   return palmas_write(leds->palmas, PALMAS_LED_BASE, reg, value);
+}
+
+static int palmas_led_update_bits(struct palmas_leds_data *leds,
+   unsigned int reg, unsigned int mask, unsigned int value)
+{
+   return palmas_update_bits(leds->palmas, PALMAS_LED_BASE,
+   reg, mask, value);
+}
+
+static void palmas_leds_work(struct work_struct *work)
+{
+   struct palmas_led *led = container_of(work, struct palmas_led, work);
+   unsigned int period, ctrl;
+   unsigned long flags;
+
+   mutex_lock(>mutex);
+
+   palmas_led_read(led->leds_data, PALMAS_LED_CTRL, );
+   palmas_led_read(led->leds_data, PALMAS_LED_PERIOD_CTRL, );
+
+   spin_lock_irqsave(>value_lock, flags);
+
+   switch (led->led_no) {
+   case 1:
+   ctrl &= ~PALMAS_LED_CTRL_LED_1_ON_TIME_MASK;
+   period &= ~PALMAS_LED_PERIOD_CTRL_LED_1_PERIOD_MASK;
+
+   if (led->blink) {
+   ctrl |= led->on_time <<
+   PALMAS_LED_CTRL_LED_1_ON_TIME_SHIFT;
+   period |= led->period <<
+   PALMAS_LED_PERIOD_CTRL_LED_1_PERIOD_SHIFT;
+   } else {
+   /*
+* for off value is zero which we already set by
+* masking earlier.
+*/
+   if (led->brightness) {
+   ctrl |= LED_ON_500MS <<
+   PALMAS_LED_CTRL_LED_1_ON_TIME_SHIFT;
+   period |= LED_PERIOD_500MS <<
+   PALMAS_LED_PERIOD_CTRL_LED_1_PERIOD_SHIFT;
+  

Re: [PATCH v2] hwmon: ntc: Add DT with IIO support to NTC thermistor driver

[Doug Anderson]

Hi,

On Tue, Mar 12, 2013 at 6:45 AM, Guenter Roeck  wrote:
> On Tue, Mar 12, 2013 at 02:09:26PM +0530, Naveen Krishna Chatradhi wrote:
>> This patch adds DT support to NTC driver to parse the
>> platform data.
>>
>> Also adds the support to work as an iio device.
>>
>> During the probe ntc driver gets the respective channels of ADC
>> and uses iio_raw_read calls to get the ADC converted value.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 

I know that there is still work to do to address Guenter's comments,
but I spent a little time playing with this today to see what else was
missing and actually got it working.  :)  I'll add a "Tested-by" once
Naveen reposts.

I sent up my patches that I needed to the ADC + device trees to get it
working, but I just realized that I forgot to CC Guenter.  Doh!  In
case you're curious, you can find them at:
* https://patchwork.kernel.org/patch/2260231/
* https://patchwork.kernel.org/patch/2260211/
* https://patchwork.kernel.org/patch/2260221/
* https://patchwork.kernel.org/patch/2260201/


> You'll still need the conditional dependency on IIO in Kconfig.
> Something like
> depends on IIO if OF
> if that works, or alternatively
> select IIO if OF
> if that is acceptable.

This was important for me.  I had IIO setup as a module and adc
configured an in-kernel.  Without the above I got a nice linker error.
 ;)
The syntax that worked for me was 'select IIO if OF'.  I don't think
you can do a conditional depends on (it didn't work for me and I
couldn't find any examples like that).


>> +Read more about iio bindings at
>> + Documentation/devicetree/bindings/iio/iio-bindings.txt
>> +

BTW: the above line had a whitespace error on it.  Double-check that
it's gone for the next version.


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

Re: [PATCH 3/5] W1: w1-gpio - guard DT IDs with CONFIG_OF

[Greg Kroah-Hartman]

On Sun, Feb 24, 2013 at 10:59:35PM -0800, Dmitry Torokhov wrote:
> This fixes the following warning:
> 
>   CC  drivers/w1/masters/w1-gpio.o
> drivers/w1/masters/w1-gpio.c:50:28: warning: ‘w1_gpio_dt_ids’ defined but not 
> used [-Wunused-variable]
> 
> Also provide stub for w1_gpio_probe_dt() if device tree support is
> disabled.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/w1/masters/w1-gpio.c | 11 +++
>  1 file changed, 11 insertions(+)

Already fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] ARM: imx_v6_v7_defconfig: Select CONFIG_W1_MASTER_MXC

[Greg KH]

On Mon, Mar 11, 2013 at 08:18:16PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Select CONFIG_W1_MASTER_MXC.

Why?  Don't tell me what you did, that's obvious, it's the story that is
needed.

dropped from my queue.

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 v2 1/5] W1: w1-gpio - fix incorrect __init/__exit markups

[Greg Kroah-Hartman]

On Sun, Feb 24, 2013 at 10:59:33PM -0800, Dmitry Torokhov wrote:
> We should not be using __init/__exit markups on probe() and remove()
> methods unless platform_device_probe() is used, because other methods
> allow unbinding device through sysfs and these methods should not be
> discarded.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> Paatch #4 was adjusted according to Ville's comments.
> 
>  drivers/w1/masters/w1-gpio.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Thanks, but this is already in the tree.

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/

[ 018/100] btrfs: Init io_lock after cloning btrfs device struct

[Greg Kroah-Hartman]

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

--

From: Thomas Gleixner 

commit 1cba0cdf5e4dbcd9e5fa5b54d7a028e55e2ca057 upstream.

__btrfs_close_devices() clones btrfs device structs with
memcpy(). Some of the fields in the clone are reinitialized, but it's
missing to init io_lock. In mainline this goes unnoticed, but on RT it
leaves the plist pointing to the original about to be freed lock
struct.

Initialize io_lock after cloning, so no references to the original
struct are left.

Reported-and-tested-by: Mike Galbraith 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/volumes.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -647,6 +647,7 @@ static int __btrfs_close_devices(struct
new_device->writeable = 0;
new_device->in_fs_metadata = 0;
new_device->can_discard = 0;
+   spin_lock_init(_device->io_lock);
list_replace_rcu(>dev_list, _device->dev_list);
 
call_rcu(>rcu, free_device);


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

[ 019/100] Btrfs: copy everything if weve created an inline extent

[Greg Kroah-Hartman]

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

--

From: Josef Bacik 

commit bdc20e67e82cfc4901d3a5a0d79104b0e2296d83 upstream.

I noticed while looking into a tree logging bug that we aren't logging inline
extents properly.  Since this requires copying and it shouldn't happen too often
just force us to copy everything for the inode into the tree log when we have an
inline extent.  With this patch we have valid data after a crash when we write
an inline extent.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/inode.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -265,6 +265,7 @@ static noinline int cow_file_range_inlin
return 1;
}
 
+   set_bit(BTRFS_INODE_NEEDS_FULL_SYNC, _I(inode)->runtime_flags);
btrfs_delalloc_release_metadata(inode, end + 1 - start);
btrfs_drop_extent_cache(inode, start, aligned_end - 1, 0);
return 0;


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

[ 020/100] Btrfs: delete inline extents when we find them during logging

[Greg Kroah-Hartman]

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

--

From: Josef Bacik 

commit 124fe663f93162d17b7e391705cac122101e93d8 upstream.

Apparently when we do inline extents we allow the data to overlap the last chunk
of the btrfs_file_extent_item, which means that we can possibly have a
btrfs_file_extent_item that isn't actually as large as a btrfs_file_extent_item.
This messes with us when we try to overwrite the extent when logging new extents
since we expect for it to be the right size.  To fix this just delete the item
and try to do the insert again which will give us the proper sized
btrfs_file_extent_item.  This fixes a panic where map_private_extent_buffer
would blow up because we're trying to write past the end of the leaf.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/btrfs/tree-log.c |   18 ++
 1 file changed, 18 insertions(+)

--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3281,6 +3281,7 @@ static int log_one_extent(struct btrfs_t
int ret;
bool skip_csum = BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM;
 
+insert:
INIT_LIST_HEAD(_sums);
btrfs_init_map_token();
key.objectid = btrfs_ino(inode);
@@ -3296,6 +3297,23 @@ static int log_one_extent(struct btrfs_t
leaf = path->nodes[0];
fi = btrfs_item_ptr(leaf, path->slots[0],
struct btrfs_file_extent_item);
+
+   /*
+* If we are overwriting an inline extent with a real one then we need
+* to just delete the inline extent as it may not be large enough to
+* have the entire file_extent_item.
+*/
+   if (ret && btrfs_token_file_extent_type(leaf, fi, ) ==
+   BTRFS_FILE_EXTENT_INLINE) {
+   ret = btrfs_del_item(trans, log, path);
+   btrfs_release_path(path);
+   if (ret) {
+   path->really_keep_locks = 0;
+   return ret;
+   }
+   goto insert;
+   }
+
btrfs_set_token_file_extent_generation(leaf, fi, em->generation,
   );
if (test_bit(EXTENT_FLAG_PREALLOC, >flags)) {


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

[ 017/100] ext4: convert number of blocks to clusters properly

[Greg Kroah-Hartman]

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

--

From: Lukas Czerner 

commit 810da240f221d64bf90020f25941b05b378186fe upstream.

We're using macro EXT4_B2C() to convert number of blocks to number of
clusters for bigalloc file systems.  However, we should be using
EXT4_NUM_B2C().

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/balloc.c  |2 +-
 fs/ext4/mballoc.c |8 
 fs/ext4/resize.c  |6 +++---
 fs/ext4/super.c   |2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -635,7 +635,7 @@ ext4_fsblk_t ext4_count_free_clusters(st
brelse(bitmap_bh);
printk(KERN_DEBUG "ext4_count_free_clusters: stored = %llu"
   ", computed = %llu, %llu\n",
-  EXT4_B2C(EXT4_SB(sb), ext4_free_blocks_count(es)),
+  EXT4_NUM_B2C(EXT4_SB(sb), ext4_free_blocks_count(es)),
   desc_count, bitmap_count);
return bitmap_count;
 #else
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -3444,7 +3444,7 @@ ext4_mb_new_inode_pa(struct ext4_allocat
win = offs;
 
ac->ac_b_ex.fe_logical = ac->ac_o_ex.fe_logical -
-   EXT4_B2C(sbi, win);
+   EXT4_NUM_B2C(sbi, win);
BUG_ON(ac->ac_o_ex.fe_logical < ac->ac_b_ex.fe_logical);
BUG_ON(ac->ac_o_ex.fe_len > ac->ac_b_ex.fe_len);
}
@@ -4590,7 +4590,7 @@ do_more:
EXT4_BLOCKS_PER_GROUP(sb);
count -= overflow;
}
-   count_clusters = EXT4_B2C(sbi, count);
+   count_clusters = EXT4_NUM_B2C(sbi, count);
bitmap_bh = ext4_read_block_bitmap(sb, block_group);
if (!bitmap_bh) {
err = -EIO;
@@ -4832,11 +4832,11 @@ int ext4_group_add_blocks(handle_t *hand
ext4_group_desc_csum_set(sb, block_group, desc);
ext4_unlock_group(sb, block_group);
percpu_counter_add(>s_freeclusters_counter,
-  EXT4_B2C(sbi, blocks_freed));
+  EXT4_NUM_B2C(sbi, blocks_freed));
 
if (sbi->s_log_groups_per_flex) {
ext4_group_t flex_group = ext4_flex_group(sbi, block_group);
-   atomic_add(EXT4_B2C(sbi, blocks_freed),
+   atomic_add(EXT4_NUM_B2C(sbi, blocks_freed),
   >s_flex_groups[flex_group].free_clusters);
}
 
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -1247,7 +1247,7 @@ static int ext4_setup_new_descs(handle_t
 
ext4_inode_table_set(sb, gdp, group_data->inode_table);
ext4_free_group_clusters_set(sb, gdp,
-EXT4_B2C(sbi, 
group_data->free_blocks_count));
+   EXT4_NUM_B2C(sbi, group_data->free_blocks_count));
ext4_free_inodes_set(sb, gdp, EXT4_INODES_PER_GROUP(sb));
if (ext4_has_group_desc_csum(sb))
ext4_itable_unused_set(sb, gdp,
@@ -1349,7 +1349,7 @@ static void ext4_update_super(struct sup
 
/* Update the free space counts */
percpu_counter_add(>s_freeclusters_counter,
-  EXT4_B2C(sbi, free_blocks));
+  EXT4_NUM_B2C(sbi, free_blocks));
percpu_counter_add(>s_freeinodes_counter,
   EXT4_INODES_PER_GROUP(sb) * flex_gd->count);
 
@@ -1360,7 +1360,7 @@ static void ext4_update_super(struct sup
sbi->s_log_groups_per_flex) {
ext4_group_t flex_group;
flex_group = ext4_flex_group(sbi, group_data[0].group);
-   atomic_add(EXT4_B2C(sbi, free_blocks),
+   atomic_add(EXT4_NUM_B2C(sbi, free_blocks),
   >s_flex_groups[flex_group].free_clusters);
atomic_add(EXT4_INODES_PER_GROUP(sb) * flex_gd->count,
   >s_flex_groups[flex_group].free_inodes);
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3235,7 +3235,7 @@ int ext4_calculate_overhead(struct super
}
/* Add the journal blocks as well */
if (sbi->s_journal)
-   overhead += EXT4_B2C(sbi, sbi->s_journal->j_maxlen);
+   overhead += EXT4_NUM_B2C(sbi, sbi->s_journal->j_maxlen);
 
sbi->s_overhead = overhead;
smp_wmb();


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

[ 013/100] SCSI: dc395x: uninitialized variable in device_alloc()

[Greg Kroah-Hartman]

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

--

From: Dan Carpenter 

commit 208afec4f3be8c51ad6eebe6611dd6d2ad2fa298 upstream.

This bug was introduced back in bitkeeper days in 2003.  We use
"dcb->dev_mode" before it has been initialized.

Signed-off-by: Dan Carpenter 
Acked-by: Oliver Neukum 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/dc395x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -3747,13 +3747,13 @@ static struct DeviceCtlBlk *device_alloc
dcb->max_command = 1;
dcb->target_id = target;
dcb->target_lun = lun;
+   dcb->dev_mode = eeprom->target[target].cfg0;
 #ifndef DC395x_NO_DISCONNECT
dcb->identify_msg =
IDENTIFY(dcb->dev_mode & NTC_DO_DISCONNECT, lun);
 #else
dcb->identify_msg = IDENTIFY(0, lun);
 #endif
-   dcb->dev_mode = eeprom->target[target].cfg0;
dcb->inquiry7 = 0;
dcb->sync_mode = 0;
dcb->min_nego_period = clock_period[period_index];


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

[ 023/100] dm: do not replace bioset for request based dm

[Greg Kroah-Hartman]

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

--

From: Jun'ichi Nomura 

commit 16245bdc9d3e22d1460341a655c8b5288953bc14 upstream.

This patch fixes a regression introduced in v3.8, which causes oops
like this when dm-multipath is used:

general protection fault:  [#1] SMP
RIP: 0010:[]  [] mempool_free+0x24/0xb0
Call Trace:
  
  [] bio_put+0x97/0xc0
  [] end_clone_bio+0x35/0x90 [dm_mod]
  [] bio_endio+0x1d/0x30
  [] req_bio_endio.isra.51+0xa3/0xe0
  [] blk_update_request+0x118/0x520
  [] blk_update_bidi_request+0x27/0xa0
  [] blk_end_bidi_request+0x2c/0x80
  [] blk_end_request+0x10/0x20
  [] scsi_io_completion+0xfb/0x6c0 [scsi_mod]
  [] scsi_finish_command+0xbd/0x120 [scsi_mod]
  [] scsi_softirq_done+0x13f/0x160 [scsi_mod]
  [] blk_done_softirq+0x80/0xa0
  [] __do_softirq+0xf1/0x250
  [] call_softirq+0x1c/0x30
  [] do_softirq+0x8d/0xc0
  [] irq_exit+0xd5/0xe0
  [] do_IRQ+0x63/0xe0
  [] common_interrupt+0x6f/0x6f
  
  [] srp_queuecommand+0x8c/0xcb0 [ib_srp]
  [] scsi_dispatch_cmd+0x148/0x310 [scsi_mod]
  [] scsi_request_fn+0x31e/0x520 [scsi_mod]
  [] __blk_run_queue+0x37/0x50
  [] blk_delay_work+0x29/0x40
  [] process_one_work+0x1c3/0x5c0
  [] worker_thread+0x15e/0x440
  [] kthread+0xdb/0xe0
  [] ret_from_fork+0x7c/0xb0

The regression was introduced by the change
c0820cf5 "dm: introduce per_bio_data", where dm started to replace
bioset during table replacement.
For bio-based dm, it is good because clone bios do not exist during the
table replacement.
For request-based dm, however, (not-yet-mapped) clone bios may stay in
request queue and survive during the table replacement.
So freeing the old bioset could cause the oops in bio_put().

Since the size of front_pad may change only with bio-based dm,
it is not necessary to replace bioset for request-based dm.

Reported-by: Bart Van Assche 
Tested-by: Bart Van Assche 
Signed-off-by: Jun'ichi Nomura 
Acked-by: Mikulas Patocka 
Acked-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm.c |   30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1973,15 +1973,27 @@ static void __bind_mempools(struct mappe
 {
struct dm_md_mempools *p = dm_table_get_md_mempools(t);
 
-   if (md->io_pool && (md->tio_pool || dm_table_get_type(t) == 
DM_TYPE_BIO_BASED) && md->bs) {
-   /*
-* The md already has necessary mempools. Reload just the
-* bioset because front_pad may have changed because
-* a different table was loaded.
-*/
-   bioset_free(md->bs);
-   md->bs = p->bs;
-   p->bs = NULL;
+   if (md->io_pool && md->bs) {
+   /* The md already has necessary mempools. */
+   if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+   /*
+* Reload bioset because front_pad may have changed
+* because a different table was loaded.
+*/
+   bioset_free(md->bs);
+   md->bs = p->bs;
+   p->bs = NULL;
+   } else if (dm_table_get_type(t) == DM_TYPE_REQUEST_BASED) {
+   BUG_ON(!md->tio_pool);
+   /*
+* There's no need to reload with request-based dm
+* because the size of front_pad doesn't change.
+* Note for future: If you are to reload bioset,
+* prep-ed requests in the queue may refer
+* to bio from the old bioset, so you must walk
+* through the queue to unprep.
+*/
+   }
goto out;
}
 


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