Re: [RFC -next] linux/linkage.h: fix symbol prefix handling

[Rusty Russell]

Sam Ravnborg  writes:
>> actually, y'know, proof-read it.
> Hmm..

>> +   $(KERNELRELEASE) "$(patsubst 
>> y,_,$(CONFIG_HAVE_SYMBOL_PREFIX_UNDERSCORE))"
>>  
>> +config HAVE_UNDERSCORE_SYMBOL_PREFIX
>
> HAVE_UNDERSCORE_... or HAVE_SYMBOL_... confusion.
> I prefer the HAVE_SYMBOL_... variant but no strong feelings..

Thanks, fixed.  (HAVE_UNDERSCORE_ won by grep majority vote, but I don't
really care either).

>> + *
>> + * If you think the above arrogance just encourages more people to add
>> + * random crap to this file, you're not alone.
> Kill this.

??  It went in without my Ack, and it's a particularly offensive turd.

I can replace it with a civilized comment, instead of being snarky
though...

>>  /* Some toolchains use a `_' prefix for all user symbols. */
>> -#ifdef CONFIG_SYMBOL_PREFIX
>> -#define MODULE_SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
>> +#ifdef CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
>> +#define __VMLINUX_SYMBOL(x) _##x
>> +#define __VMLINUX_SYMBOL_STR(x) "_" #x
>> +#define VMLINUX_SYMBOL_PREFIX_STR "_"
>>  #else
>> -#define MODULE_SYMBOL_PREFIX ""
>> +#define __VMLINUX_SYMBOL(x) x
>> +#define __VMLINUX_SYMBOL_STR(x) #x
>> +#define VMLINUX_SYMBOL_PREFIX_STR ""
>>  #endif
>
> We know the prefix is an underscore. No benefits from defining
> VMLINUX_SYMBOL_PREFIX_STR. The config name even syas so.
> Skipping the above give us only one way to check
> for the prefix - today we mix the two.

After testing, I think you're right.  The two users are both slightly
clearer after this (though mtd is a tiny bit less optimal).

Note: James, your patch hunk now looks like this:

  - buf_printf(b, "\t{ %#8x, \"%s\" },\n", s->crc, s->name);
  + buf_printf(b, "\t{ %#8x, VMLINUX_SYMBOL_STR(%s) },\n",
  +s->crc, s->name);

Here's version 3:

From: Rusty Russell 
Subject: 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() and VMLINUX_SYMBOL_STR().
4) Make everyone use them.

Signed-off-by: Rusty Russell 

diff --git a/Makefile b/Makefile
index a05ea42..0b09ba5 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_UNDERSCORE_SYMBOL_PREFIX))"
 
 # Create temporary dir for module support files
 # clean it up only when building all modules
diff --git a/arch/Kconfig b/arch/Kconfig
index 1455579..7b433a4 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -384,6 +384,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 c3f2e0b..453ebe4 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 VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_GENERIC_HARDIRQS
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 79250de..303e4f9 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -12,10 +12,7 @@ config H8300
  

Re: [PATCH 1/1] gpio/vt8500: Convert to devm_ioremap_resource()

[Sachin Kamat]

Hi Linus,

On 4 March 2013 22:38, Tony Prisk  wrote:
> On Mon, 2013-03-04 at 14:39 +0530, Sachin Kamat wrote:
>> Use the newly introduced devm_ioremap_resource() instead of
>> devm_request_and_ioremap() which provides more consistent error handling.
>>
>> devm_ioremap_resource() provides its own error messages; so all explicit
>> error messages can be removed from the failure code paths.
>>
>> Signed-off-by: Sachin Kamat 

> Acked-by: Tony Prisk 

Would you be picking this patch up or Grant is gonna handle it?


-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] module: fix symbol versioning with symbol prefixes

[Rusty Russell]

James Hogan  writes:
> Fix symbol versioning on architectures with symbol prefixes. Although
> the build was free from warnings the actual modules still wouldn't load
> as the versions table contained unprefixed symbol names, which were
> being compared against the prefixed symbol names when checking the
> symbol versions.
>
> This is fixed by modifying modpost to add the symbol prefix to the
> versions table it outputs (Modules.symvers still contains unprefixed
> symbol names). The check_modstruct_version() function is also fixed as
> it checks the version of the unprefixed "module_layout" symbol which
> would no longer work.

Hmm, this has always been broken, right?  And noone noticed?  Unless you
really want it now, I'll queue it for *next* merge window.

I've applied it (reworked) to my pending-rebases queue, and will put it
in modules-next once the cleanup goes in.

Thanks,
Rusty.

From: James Hogan 
Subject: module: fix symbol versioning with symbol prefixes

Fix symbol versioning on architectures with symbol prefixes. Although
the build was free from warnings the actual modules still wouldn't load
as the versions table contained unprefixed symbol names, which were
being compared against the prefixed symbol names when checking the
symbol versions.

This is fixed by modifying modpost to add the symbol prefix to the
versions table it outputs (Modules.symvers still contains unprefixed
symbol names). The check_modstruct_version() function is also fixed as
it checks the version of the unprefixed "module_layout" symbol which
would no longer work.

Signed-off-by: James Hogan 
Cc: Michal Marek 
Cc: Sam Ravnborg 
Cc: Greg Kroah-Hartman 
Cc: Jonathan Kliegman 
Signed-off-by: Rusty Russell  (updated for cleanup)

diff --git a/kernel/module.c b/kernel/module.c
index cfd4a3f..3c2c72d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1212,7 +1212,8 @@ static inline int check_modstruct_version(Elf_Shdr 
*sechdrs,
if (!find_symbol(VMLINUX_SYMBOL_STR(module_layout), NULL,
 &crc, true, false))
BUG();
-   return check_version(sechdrs, versindex, "module_layout", mod, crc,
+   return check_version(sechdrs, versindex,
+VMLINUX_SYMBOL_STR(module_layout), mod, crc,
 NULL);
 }
 
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 6985021..909b5e7 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1927,7 +1927,8 @@ static int add_versions(struct buffer *b, struct module 
*mod)
s->name, mod->name);
continue;
}
-   buf_printf(b, "\t{ %#8x, \"%s\" },\n", s->crc, s->name);
+   buf_printf(b, "\t{ %#8x, \"%s%s\" },\n", s->crc,
+  VMLINUX_SYMBOL_PREFIX_STR, s->name);
}
 
buf_printf(b, "};\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 12/40] hw_random: make buffer usable in scatterlist.

[Rusty Russell]

Satoru Takeuchi  writes:
> Hi Rusty,
>
> At Tue, 12 Mar 2013 15:43:33 -0700,
> Greg Kroah-Hartman wrote:
>> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>>  
>>  mutex_lock(&rng_mutex);
>>  
>> +/* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> +err = -ENOMEM;
>> +if (!rng_buffer) {
>> +rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
>
> rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
> at hwrng_unregister()? If my suspect is correct, the same problem is
> in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
> some hours.
>
> Corecct me if I'm wrong.

Yes, it would be nice to free it, but it really makes sense to free it
in module_cleanup() (which would have to be written, as the module
currently doesn't have one).

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

RE: [ 031/100] iwlwifi: always copy first 16 bytes of commands

[Berg, Johannes]

> > >   /* and copy the data that needs to be copied */
> > >   cmd_pos = offsetof(struct iwl_device_cmd, payload);
> > > + copy_size = sizeof(out_cmd->hdr);
> > >   for (i = 0; i < IWL_MAX_CMD_TFDS; i++) {
> > > - if (!cmd->len[i])
> > > + int copy = 0;
> > > +
> > > + if (!cmd->len)
> > >   continue;
> >
> > cmd->len is an array, so the new condition is always false.  Shouldn't
> > it be 'if (!cmdlen[i])'?
> 
> To answer myself: no, it should still be 'if (!cmd->len[i])' as this loop 
> needs to
> include input fragments that will be completely copied into the header
> fragment.

Ick, good catch. It luckily doesn't matter as if cmd->len[i] is 0 (in which 
case we'd continue) the "if (copy)" below saves us in all the different code 
paths inside the loop. This is still clearly a mistake in the patch though.

I will fix this upstream, I guess you'll want to wait for that for stable? I'll 
Cc:stable that patch as well.

johannes

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

linux-next: manual merge of the signal tree with the modules tree

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
include/asm-generic/unistd.h between commit 837718bfd28b
("CONFIG_SYMBOL_PREFIX: cleanup") from the modules tree and commit
e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
from the signal tree.

The latter moved the cond_syscall stuff to linkage.h, so I applied the
following patch as a merge fixup and can carry the fix as necessary (no
action is required).  I am not sure if this is completely correct or all
that is needed.

From: Stephen Rothwell 
Date: Thu, 14 Mar 2013 17:14:41 +1100
Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup

Signed-off-by: Stephen Rothwell 
---
 include/linux/linkage.h | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index 829d66c..bedcddf 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -2,7 +2,7 @@
 #define _LINUX_LINKAGE_H
 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -15,24 +15,16 @@
 #define asmlinkage CPP_ASMLINKAGE
 #endif
 
-#ifndef SYMBOL_NAME
-#ifdef CONFIG_SYMBOL_PREFIX
-#define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
-#else
-#define SYMBOL_NAME(x) x
-#endif
-#endif
-#define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
-
 #ifndef cond_syscall
-#define cond_syscall(x) asm(".weak\t" __SYMBOL_NAME(x) \
-   "\n\t.set\t" __SYMBOL_NAME(x) "," __SYMBOL_NAME(sys_ni_syscall));
+#define cond_syscall(x) asm(".weak\t" VMLINUX_SYMBOL_STR(x) "\n\t" \
+   ".set\t" VMLINUX_SYMBOL_STR(x) ","  \
+   VMLINUX_SYMBOL_STR(sys_ni_syscall))
 #endif
 
 #ifndef SYSCALL_ALIAS
 #define SYSCALL_ALIAS(alias, name) \
-   asm ("\t.globl " __SYMBOL_NAME(alias)   \
-   "\n\t.set\t" __SYMBOL_NAME(alias) "," __SYMBOL_NAME(name))
+   asm ("\t.globl " VMLINUX_SYMBOL_STR(alias)  \
+   "\n\t.set\t" VMLINUX_SYMBOL_STR(alias) "," VMLINUX_SYMBOL_STR(name))
 #endif
 
 #define __page_aligned_data__section(.data..page_aligned) 
__aligned(PAGE_SIZE)
-- 
1.8.1

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


pgptXnZh2GSGZ.pgp
Description: PGP signature

[PATCH v2 2/4] usb: otg: twl4030: use devres API for regulator get and request irq

[Kishon Vijay Abraham I]

Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/twl4030-usb.c |   28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 04b732e2..5b20bb4 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -470,7 +470,7 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 3.1V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
 
-   twl->usb3v1 = regulator_get(twl->dev, "usb3v1");
+   twl->usb3v1 = devm_regulator_get(twl->dev, "usb3v1");
if (IS_ERR(twl->usb3v1))
return -ENODEV;
 
@@ -479,18 +479,18 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 1.5V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
 
-   twl->usb1v5 = regulator_get(twl->dev, "usb1v5");
+   twl->usb1v5 = devm_regulator_get(twl->dev, "usb1v5");
if (IS_ERR(twl->usb1v5))
-   goto fail1;
+   return -ENODEV;
 
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
 
/* Initialize 1.8V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
 
-   twl->usb1v8 = regulator_get(twl->dev, "usb1v8");
+   twl->usb1v8 = devm_regulator_get(twl->dev, "usb1v8");
if (IS_ERR(twl->usb1v8))
-   goto fail2;
+   return -ENODEV;
 
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
 
@@ -499,14 +499,6 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 TWL4030_PM_MASTER_PROTECT_KEY);
 
return 0;
-
-fail2:
-   regulator_put(twl->usb1v5);
-   twl->usb1v5 = NULL;
-fail1:
-   regulator_put(twl->usb3v1);
-   twl->usb3v1 = NULL;
-   return -ENODEV;
 }
 
 static ssize_t twl4030_usb_vbus_show(struct device *dev,
@@ -695,9 +687,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 * need both handles, otherwise just one suffices.
 */
twl->irq_enabled = true;
-   status = request_threaded_irq(twl->irq, NULL, twl4030_usb_irq,
-   IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
-   IRQF_ONESHOT, "twl4030_usb", twl);
+   status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
+   twl4030_usb_irq, IRQF_TRIGGER_FALLING |
+   IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
if (status < 0) {
dev_dbg(&pdev->dev, "can't get IRQ %d, err %d\n",
twl->irq, status);
@@ -716,7 +708,6 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
int val;
 
cancel_delayed_work(&twl->id_workaround_work);
-   free_irq(twl->irq, twl);
device_remove_file(twl->dev, &dev_attr_vbus);
 
/* set transceiver mode to power on defaults */
@@ -738,9 +729,6 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
 
if (!twl->asleep)
twl4030_phy_power(twl, 0);
-   regulator_put(twl->usb1v5);
-   regulator_put(twl->usb1v8);
-   regulator_put(twl->usb3v1);
 
return 0;
 }
-- 
1.7.10.4

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

[PATCH v2 0/4] usb: musb/otg: cleanup and fixes

[Kishon Vijay Abraham I]

This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
fixes-for-v3.9-rc3 after applying 
http://www.spinics.net/lists/linux-usb/msg81563.html
(Grazvydas Ignotas patch series)

Tested for g_zero enumeration in pandaboard and beagleboard in both
cold plug and hot plug case. Any kind of testing for this series is welcome.

Changes from v1:
* removed *usb: musb: omap: remove the check before calling otg_set_vbus*
a similar patch is already merged.

Kishon Vijay Abraham I (4):
  usb: musb: omap: remove the check before calling otg_set_vbus
  usb: otg: twl4030: use devres API for regulator get and request irq
  usb: musb: omap: add usb_phy_init in omap2430_musb_init
  usb: otg: twl4030: fix cold plug on OMAP3

 drivers/usb/musb/omap2430.c   |   11 +--
 drivers/usb/otg/twl4030-usb.c |   35 ---
 2 files changed, 17 insertions(+), 29 deletions(-)

-- 
1.7.10.4

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

[PATCH v2 4/4] usb: otg: twl4030: fix cold plug on OMAP3

[Kishon Vijay Abraham I]

Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is ready.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/twl4030-usb.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 5b20bb4..4040124 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -565,8 +565,9 @@ static void twl4030_id_workaround_work(struct work_struct 
*work)
}
 }
 
-static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+static int twl4030_usb_phy_init(struct usb_phy *phy)
 {
+   struct twl4030_usb *twl = phy_to_twl(phy);
enum omap_musb_vbus_id_status status;
 
/*
@@ -581,6 +582,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
omap_musb_mailbox(twl->linkstat);
 
sysfs_notify(&twl->dev->kobj, NULL, "vbus");
+   return 0;
 }
 
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
@@ -657,6 +659,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->phy.otg= otg;
twl->phy.type   = USB_PHY_TYPE_USB2;
twl->phy.set_suspend= twl4030_set_suspend;
+   twl->phy.init   = twl4030_usb_phy_init;
 
otg->phy= &twl->phy;
otg->set_host   = twl4030_set_host;
@@ -696,8 +699,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
 
-   twl4030_usb_phy_init(twl);
-
dev_info(&pdev->dev, "Initialized TWL4030 USB module\n");
return 0;
 }
-- 
1.7.10.4

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

[PATCH v2 1/4] usb: musb: omap: remove the check before calling otg_set_vbus

[Kishon Vijay Abraham I]

No functional change. otg_set_vbus is already protected so removed the
check before calling otg_set_vbus.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/omap2430.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 29014c0..6071484 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -174,8 +174,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int 
is_on)
}
}
 
-   if (otg->set_vbus)
-   otg_set_vbus(otg, 1);
+   otg_set_vbus(otg, 1);
} else {
musb->is_active = 1;
otg->default_a = 1;
@@ -297,10 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
}
 
omap2430_musb_set_vbus(musb, 0);
-   if (data->interface_type == MUSB_INTERFACE_UTMI) {
-   if (musb->xceiv->otg->set_vbus)
-   otg_set_vbus(musb->xceiv->otg, 0);
-   }
+   if (data->interface_type == MUSB_INTERFACE_UTMI)
+   otg_set_vbus(musb->xceiv->otg, 0);
omap_control_usb_set_mode(glue->control_otghs,
USB_MODE_DISCONNECT);
break;
-- 
1.7.10.4

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

[PATCH v2 3/4] usb: musb: omap: add usb_phy_init in omap2430_musb_init

[Kishon Vijay Abraham I]

Some PHYs load too early (twl4030) making omap glue to miss cable connect events
if the board is booted with cable connected. So adding usb_phy_init in
omap2430_musb_init lets PHYs to report events once glue is ready.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/omap2430.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6071484..8876741 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb)
if (glue->status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
 
+   usb_phy_init(musb->xceiv);
+
pm_runtime_put_noidle(musb->controller);
return 0;
 
-- 
1.7.10.4

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

Re: [PATCH] ARM: dts: add usb 2.0 clock references to exynos5250 device tree

[Vivek Gautam]

Hi Doug,


On Wed, Mar 13, 2013 at 10:48 PM, Doug Anderson  wrote:
> This is a fixup to two device tree nodes that have already landed but
> without clock nodes since the transition to common clock happened at
> the same time.
>
> Signed-off-by: Doug Anderson 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 24c52e6..59be603 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -402,12 +402,18 @@
> compatible = "samsung,exynos4210-ehci";
> reg = <0x1211 0x100>;
> interrupts = <0 71 0>;
> +
> +   clocks = <&clock 285>;
> +   clock-names = "usbhost";
> };
>
> usb@1212 {
> compatible = "samsung,exynos4210-ohci";
> reg = <0x1212 0x100>;
> interrupts = <0 71 0>;
> +
> +   clocks = <&clock 285>;
> +   clock-names = "usbhost";

It will be nice if you can please update relevant information
alongwith this, in the bindings doc for "exynos-usb".

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



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

[PATCH]Perf: Fix Makefile to remove all "*.o" files while "make clean"

[chenggang]

From: chenggang 

While we run "make clean" in perf's directory, and run the command:
"fine ./ -name *.o"
we will get:

./arch/x86/util/unwind.o
./arch/x86/util/header.o
./arch/x86/util/dwarf-regs.o
./util/scripting-engines/trace-event-python.o
./util/scripting-engines/trace-event-perl.o
./util/probe-finder.o
./util/dwarf-aux.o
./util/unwind.o
./lib/rbtree.o
./ui/browser.o
./ui/browsers/map.o
./ui/browsers/annotate.o
./ui/browsers/scripts.o
./ui/browsers/hists.o
./ui/tui/setup.o
./ui/tui/util.o
./ui/tui/helpline.o
./ui/tui/progress.o
./ui/gtk/browser.o
./ui/gtk/setup.o
./ui/gtk/util.o
./ui/gtk/helpline.o
./ui/gtk/annotate.o
./ui/gtk/progress.o
./ui/gtk/hists.o
./scripts/perl/Perf-Trace-Util/Context.o
./scripts/python/Perf-Trace-Util/Context.o

These ".o" files are not cleaned.

This patch fixed this problem.

Cc: David Ahern 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Arjan van de Ven 
Cc: Namhyung Kim 
Cc: Yanmin Zhang 
Cc: Wu Fengguang 
Cc: Mike Galbraith 
Cc: Andrew Morton 
Signed-off-by: Chenggang Qin 

---
 tools/perf/Makefile |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index a2108ca..20ed83c 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -1173,6 +1173,16 @@ clean: $(LIBTRACEEVENT)-clean
$(RM) $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)PERF-CFLAGS
$(RM) $(OUTPUT)util/*-bison*
$(RM) $(OUTPUT)util/*-flex*
+   $(RM) $(OUTPUT)util/*.o
+   $(RM) $(OUTPUT)util/scripting-engines/*.o
+   $(RM) $(OUTPUT)scripts/perl/Perf-Trace-Util/*.o
+   $(RM) $(OUTPUT)scripts/python/Perf-Trace-Util/*.o
+   $(RM) $(OUTPUT)ui/*.o
+   $(RM) $(OUTPUT)ui/browsers/*.o
+   $(RM) $(OUTPUT)ui/tui/*.o
+   $(RM) $(OUTPUT)ui/gtk/*.o
+   $(RM) $(OUTPUT)lib/*.o
+   $(RM) $(OUTPUT)arch/$(ARCH)/util/*.o
$(python-clean)
 
 .PHONY: all install clean strip $(LIBTRACEEVENT)
-- 
1.7.9.5

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

[PATCH] checkpatch: Complain about more executable files

[Stephen Boyd]

We don't want executable permissions set on files such as
devicetree syntax files, text files, defconfig files, or binary
hex files.

Cc: Andy Whitcroft 
Cc: Joe Perches 
Signed-off-by: Stephen Boyd 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..591867e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1576,7 +1576,7 @@ sub process {
 # Check for incorrect file permissions
if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) {
my $permhere = $here . "FILE: $realfile\n";
-   if ($realfile =~ 
/(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl)$/) {
+   if ($realfile =~ 
/(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl|\.dts|\.dtsi|defconfig|\.txt|\.hex|\.HEX|\.ihex)$/)
 {
ERROR("EXECUTE_PERMISSIONS",
  "do not set execute permissions for 
source files\n" . $permhere);
}
-- 
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 V4 1/3] mtd: add new fields to nand_flash_dev{}

[Brian Norris]

On Wed, Mar 13, 2013 at 6:04 AM, Huang Shijie  wrote:
> On Wed, Mar 13, 2013 at 6:54 PM, Artem Bityutskiy
>  wrote:
>> On Thu, 2013-03-07 at 18:49 +0800, Huang Shijie wrote:
>>> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
>>> index 591eeeb..f0a9d93 100644
>>> --- a/include/linux/mtd/nand.h
>>> +++ b/include/linux/mtd/nand.h
>>> @@ -578,6 +578,8 @@ struct nand_chip {
>>>   * @erasesize: eraseblock size in bytes (determined from the extended ID 
>>> if 0)
>>>   * @chipsize: total chip size in MiB
>>>   * @options: stores various chip bit options
>>> + * @id_len: The valid length of the @id.
>>> + * @oobsize: OOB size
>>>   */
>>>  struct nand_flash_dev {
>>>   char *name;
>>> @@ -592,6 +594,8 @@ struct nand_flash_dev {
>>>   unsigned long chipsize;
>>>   unsigned long erasesize;
>>>   unsigned long options;
>>> + unsigned long id_len;
>>> + unsigned long oobsize;
>>>  };
>>
>> Why are these of type 'long', which is 64 bits in 64-bit architectures,
>> which seems to be unnecessarily big. Wouldn't 'unsigned int' be enough?
>>
> Frankly speaking, "uint16_t" is enough.
> "unsigned int" is too long for both the fields.
>
>> Also, can we avoid having the 'id_len' field? Can the end of the
>
> For these 4 toshiba nand, we do not need the id_len field.
>
>> sequence of ID's be marked with a '0' or '0xFF' marker instead?
>
> Are you sure that 0 or 0xff are not the valid data during the 8byte id data?
> I am not sure.

I am sure that 0x00 is valid data. But I do not see any with 0xFF. Check:

http://www.linux-mtd.infradead.org/nand-data/nanddata.html

Anyway, this sort of magic ID byte is no good, IMO.

> Maybe in future, we may meet a nand which use the 0xff as a valid id-data.
>
> But we can remove this id_len field now. It's ok to me.

As I noted elsewhere, I would prefer an id_len field. But I can also
add one if/when it comes up, if we really must.

BTW, I was just thinking; if you really want to save data space, we
should have just made two totally separate tables: one with full IDs
and one dev-id patterns. The first table should (hopefully) have fewer
entries but can have a few extra columns, for a good purpose.

But I'm not sure that space is worth it. We waste more (?) space with
our static nand_ecclayout structs which aren't even going to be used
by many drivers. Even those that are "used" aren't very useful, as no
one really uses OOB for FS data much. (And to go off on more
tangents...those structs could by shrunk easily with a few 'uint16_t',
as they are no longer directly exported as the user ABI.)

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

Re: [PATCH 2/5] usb: musb: omap: always glue have the correct vbus/id status

[kishon]

On Thursday 14 March 2013 03:29 AM, Grazvydas Ignotas wrote:

On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I  wrote:

In the case where omap glue is loaded and musb core is not, glue->status
wont have a valid status if the phy drivers call omap_musb_mailbox. So
fixed the conditions here.


There already seems to be another patch named "usb: musb: omap2430:
fix omap_musb_mailbox glue check again" on it's way to mainline that
does mostly the same as first part of this patch.


Oh yeah. Missed that.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 2/3] mtd: add the support to parse out the full-id nand type

[Brian Norris]

Hi Huang,

A few nitpicks, and a few real comments.

On Wed, Mar 13, 2013 at 7:59 PM, Huang Shijie  wrote:
> When we meet a full-id nand type which @mfr_id is true, we can use
> the find_full_id_nand() to parse out the neccessary information for a

s/neccessary/necessary

> nand chip.
>
> If we meet a non full-id nand type, we can handle it in the lagacy way.

s/lagacy/legacy

> Signed-off-by: Huang Shijie 
> ---
>  drivers/mtd/nand/nand_base.c |   36 +---
>  1 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 72eada2..b7ad9fd 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3123,6 +3123,30 @@ static void nand_decode_bbm_options(struct mtd_info 
> *mtd,
> chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
>  }
>
> +static inline bool is_full_id_nand(struct nand_flash_dev *type)
> +{
> +   return type->mfr_id;
> +}

If we restore the id_len field (as I recommended in reply to the cover
letter), then I think this check would be better performed as:

return !type->id_len;

That would really be a more specific and accurate test and can
compensate for some wildly unlikely case in which a manufacturer uses
manufacturer ID = 0.

> +static bool find_full_id_nand(struct mtd_info *mtd, struct nand_chip *chip,
> +  struct nand_flash_dev *type, u8 *id_data, int *busw)
> +{
> +   if (!strncmp(type->id, id_data, 8)) {
> +   mtd->writesize = type->pagesize;
> +   mtd->erasesize = type->erasesize;
> +   mtd->oobsize = type->oobsize;
> +
> +   chip->cellinfo = id_data[2];
> +   chip->chipsize = (uint64_t)type->chipsize << 20;
> +   chip->options |= type->options;
> +
> +   *busw = type->options & NAND_BUSWIDTH_16;
> +
> +   return true;
> +   }
> +   return false;
> +}
> +
>  /*
>   * Get the flash and manufacturer id and lookup if the type is supported.
>   */
> @@ -3174,9 +3198,15 @@ static struct nand_flash_dev 
> *nand_get_flash_type(struct mtd_info *mtd,
> if (!type)
> type = nand_flash_ids;
>
> -   for (; type->name != NULL; type++)
> -   if (*dev_id == type->dev_id)
> -   break;
> +   for (; type->name != NULL; type++) {
> +   if (is_full_id_nand(type)) {
> +   if (find_full_id_nand(mtd, chip, type, id_data, 
> &busw))
> +   goto ident_done;
> +   } else {
> +   if (*dev_id == type->dev_id)

Combine the previous two lines to:

} else if (*dev_id == type->dev_id) {

> +   break;
> +   }
> +   }
>
> chip->onfi_version = 0;
> if (!type->name || !type->pagesize) {

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 3/3] mtd: add 4 Toshiba nand chips for the full-id case

[Brian Norris]

On Wed, Mar 13, 2013 at 7:59 PM, Huang Shijie  wrote:
> I have 4 Toshiba nand chips which can not be parsed out by the
> id data. We can not get the oob size from the id data. So add them
> as the full-id nand chips in the first of nand_flash_ids.
>
> The nand_get_flash_type() scans the full id nands firstly.
> If a full-id nand matchs, it will not continue to parse other
> non-full-id nand types, else it will continue to parse the non-full-id nands.
>
> Signed-off-by: Huang Shijie 
> ---
>  drivers/mtd/nand/nand_ids.c |   22 ++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index 625bc89..38b8cee 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>
>  #define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
>  #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
> @@ -22,6 +23,27 @@
>   * extended chip ID.
>   */
>  struct nand_flash_dev nand_flash_ids[] = {
> +   /*
> +* The full-id nands may share the same Device ID with the non-full-id
> +* nands. In order to distinguish the two type nands, we put the
> +* full-id nands in the first of the table. So the 
> nand_get_flash_type()
> +* scans the full id nands firstly. If a full-id nand matchs, it will
> +* not continue to parse other non-full-id nand types, else it will
> +* continue to parse the non-full-id nands.
> +*/

There are a few grammar/language issues (nands -> NAND chips, id ->
ID, firstly -> first). Also, I don't think you need to explain the
full search here. I would rewrite this whole paragraph as:

"Some incompatible NAND chips share device ID's and so must be listed
by full ID. We list them first so that we can easily identify the most
specific match."

> +   {"TC58NVG2S0F 4G 3.3V 8-bit",
> +   { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
> +   SZ_4K, SZ_512, SZ_256K, 0, 224},
> +   {"TC58NVG3S0F 8G 3.3V 8-bit",
> +   { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
> +   SZ_4K, SZ_1K, SZ_256K, 0, 232},
> +   {"TC58NVG5D2 32G 3.3V 8-bit",
> +   { .id = {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00} },
> +   SZ_8K, SZ_4K, SZ_1M, 0, 640},
> +   {"TC58NVG6D2 64G 3.3V 8-bit",
> +   { .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
> +   SZ_8K, SZ_8K, SZ_2M, 0, 640},
> +
> LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 512, 4, 0x2000, 0),
> LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 512, 4, 0x2000, 0),
> LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE5, 512, 4, 0x2000, 0),

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

[PATCH v3] arm: fix a wrong value returned from CALLER_ADDRn

[kpark3469]

From: Sahara 

This makes return_address() return a correct value for CALLER_ADDRn.
To have a correct value from CALLER_ADDRn, we need to fix three points.

* The unwind_frame() does not update frame->lr but frame->pc for backtrace.
So frame->pc is meaningful for backtrace.

* data.level should be adjusted by adding 2 additional iteration levels.
With the current +1 level adjustment, the result of CALLER_ADDR1 will
be the same return address with CALLER_ADDR0.

* The initialization of data.addr to NULL is needed.
When unwind_fame() fails right after data.level reaches zero,
the routine returns data.addr which has uninitialized garbage value.

Signed-off-by: Sahara 
Reviewed-by: Dave Martin 
---
 arch/arm/kernel/return_address.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..fafedd8 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
struct return_address_data *data = d;
 
if (!data->level) {
-   data->addr = (void *)frame->lr;
+   data->addr = (void *)frame->pc;
 
return 1;
} else {
@@ -41,7 +41,8 @@ void *return_address(unsigned int level)
struct stackframe frame;
register unsigned long current_sp asm ("sp");
 
-   data.level = level + 1;
+   data.level = level + 2;
+   data.addr = NULL;
 
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_sp;
-- 
1.7.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/

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

[Stephen Rothwell]

Hi Jörn,

Today's linux-next merge of the bcon tree got a conflict in
drivers/block/Kconfig between commit 8722ff8cdbfa ("block: IBM RamSan
70/80 device driver") from Linus' tree and commit a2ff9d05bbb4 ("add
blockconsole version 1.1") from the bcon 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 drivers/block/Kconfig
index 5dc0dae,06eb42f..000
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@@ -531,14 -544,10 +531,20 @@@ config BLK_DEV_RB
  
  If unsure, say N.
  
 +config BLK_DEV_RSXX
 +  tristate "RamSam PCIe Flash SSD Device Driver"
 +  depends on PCI
 +  help
 +Device driver for IBM's high speed PCIe SSD
 +storage devices: RamSan-70 and RamSan-80.
 +
 +To compile this driver as a module, choose M here: the
 +module will be called rsxx.
 +
+ config BLOCKCONSOLE
+   bool "Block device console logging support"
+   help
+ This enables logging to block devices.
+ See  for details.
+ 
  endif # BLK_DEV


pgpb00m20Ncfw.pgp
Description: PGP signature

Re: [PATCH v5 0/3] mtd: use the full-id as the keyword for some nand chips

[Brian Norris]

On Wed, Mar 13, 2013 at 7:59 PM, Huang Shijie  wrote:
> As time goes on, we begin to meet the situation that we can not
> get enough information from some nand chips's id data.
> Take some Toshiba's nand chips for example.
> I have 4 Toshiba's nand chips in my hand:
> TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2
>
> When we read these chips' datasheets, we will get the geometry of these chips:
> TC58NVG2S0F : 4096 + 224
> TC58NVG3S0F : 4096 + 232
> TC58NVG5D2  : 8192 + 640
> TC58NVG6D2  : 8192 + 640
>
> But we can not parse out the correct oob size for these chips from the id 
> data.
> So it is time to add some new fields to the nand_flash_dev{},
> and update the detection mechanisms.
>
> v4 --> v4:
> [1] remove the id_len field.
> [2] based on Artem "mtd: nand: use more reasonable integer types"
> [3] add more comments.

Sorry for not posting this earlier, but why don't we want an id_len
field? NAND chips often only have a 5-byte or 6-byte ID "defined" in
their datasheet, and so the next few bytes aren't guaranteed to be any
particular value. Wouldn't we want to accommodate for any potential
variation in the "undefined" bytes? (These bytes do typically have a
pattern, and in fact, we currently rely on that fact.) Also, I can
easily foresee a situation in which someone might want to support NAND
based solely on the datasheet, not waiting till they get a sample of
that chip in their hands. In that case, they cannot specify a full 8
bytes in the table; they can (and should) only specify the few
substring found in their datasheet.

Really, the only argument I see for dropping id_len is to save space.
I think this is a bad choice.

...  ...

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] KVM: MMU: fast zap all shadow pages

[Xiao Guangrong]

On 03/14/2013 09:35 AM, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 10:07:06PM -0300, Marcelo Tosatti wrote:
>> On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
>>> 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 = &kvm->arch.mmu_cache;
>>> +   struct kvm_mmu_page *sp, *node;
>>> +   struct pte_list_desc *desc, *ndesc;
>>> +   int root_sp = 0;
>>>
>>> spin_lock(&kvm->mmu_lock);
>>> +
>>>  restart:
>>> -   list_for_each_entry_safe(sp, node,
>>> - &kvm->arch.mmu_cache.active_mmu_pages, link)
>>> -   if (kvm_mmu_prepare_zap_page(kvm, sp, &invalid_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, &cache->active_mmu_pages, link)
>>> +   if (sp->root_count) {
>>> +   int ret;
>>> +
>>> +   root_sp++;
>>> +   ret = kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list);
>>> +   list_move(&sp->link, &root_mmu_pages);
>>> +   if (ret)
>>> +   goto restart;
>>> +   }
>>
>> Why is it safe to skip flushing of root pages, for all
>> kvm_flush_shadow() callers?
> 
> You are not skipping the flush, only moving to the new mmu cache.
> 
>> Should revisit KVM_REQ_MMU_RELOAD... not clear it is necessary for NPT
>> (unrelated).
> 
> Actually, what i meant is: you can batch KVM_REQ_MMU_RELOAD requests to
> the end of kvm_mmu_zap_all. Waking up vcpus is not optimal since they're
> going to contend for mmu_lock anyway.

Yes, I agree. Will move KVM_REQ_MMU_RELOAD to the end of kvm_mmu_zap_all in
the V2.

BTW, the TLB flushed is not needed if no root shadow page zapped since all
vcpus are not using shadow pages. The code may be simplified to (after batch
KVM_REQ_MMU_RELOAD):

if (root_sp)
kvm_reload_remote_mmus()
> 
> Need more time to have more useful comments to this patchset, sorry.

No problem. ;) The current comments is really useful for me.


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

[RFC] epoll: avoid spinlock contention with wfcqueue

[Eric Wong]

I'm posting this lightly tested version since I may not be able to do
more testing/benchmarking until the weekend.

Davide's totalmess is still running, so that's probably a good sign :)
http://www.xmailserver.org/totalmess.c
I will look for more ways to break this (and benchmark when I stop
finding ways to break it).  No real applications tested, yet, and
I think I can improve upon this, too.

This depends on a couple of patches sitting in -mm and a few
more I've posted on LKML, for convenience everything is here:

http://yhbt.net/epoll-wfcqueue-v3.8.2-20130314.mbox
(should apply cleanly to 3.9-rc* since there's no epoll changes in that)

--8<---
>From 139f0d4528c3fabc6a54e47be73ba9990b42cdd8 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Thu, 14 Mar 2013 02:37:12 +
Subject: [PATCH] epoll: avoid spinlock contention with wfcqueue

This is not a proper commit, I've barely tested this.

Replace the spinlock-protected linked list ready list with wfcqueue.

There is still a per-epitem atomic variable which may still spin.  The
likelyhood of contention is very low since it's not shared by the entire
structure, the state is private to each epitem.

Things changed/removed:

* ep->ovflist - the atomic, per-epitem state field prevents
  event loss during ep_send_events.

* ep_scan_ready_list - not enough generic code between users
  anymore to warrant this.  ep_poll_readyevents_proc (used for
  poll) is read-only, ep_send_events (used for epoll_wait)
  dequeues.

* ep->lock renamed to ep->wqlock; this only protects waitqueues now.
  (will experiment with making it trylock in some places, next)

* EPOLL_CTL_DEL/close() on a ready file will not immediately release
  epitem memory, epoll_wait() must be called since there's no way to
  delete a ready item from wfcqueue in O(1) time.  In practice this
  should not be a problem, any valid app using epoll must call
  epoll_wait occasionally.  Unfreed epitems still count against
  max_user_watches to protect against local DoS.  This should be the
  only possibly-noticeable change (in case there's an app that blindly
  adds/deletes things from the rbtree but never calls epoll_wait)

Barely-tested-by: Eric Wong 
Cc: Davide Libenzi 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Mathieu Desnoyers 
---
 fs/eventpoll.c | 631 ++---
 1 file changed, 292 insertions(+), 339 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index a4e4ad7..6159b85 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * LOCKING:
@@ -47,15 +48,13 @@
  *
  * 1) epmutex (mutex)
  * 2) ep->mtx (mutex)
- * 3) ep->lock (spinlock)
+ * 3) ep->wqlock (spinlock)
  *
- * The acquire order is the one listed above, from 1 to 3.
- * We need a spinlock (ep->lock) because we manipulate objects
- * from inside the poll callback, that might be triggered from
- * a wake_up() that in turn might be called from IRQ context.
- * So we can't sleep inside the poll callback and hence we need
- * a spinlock. During the event transfer loop (from kernel to
- * user space) we could end up sleeping due a copy_to_user(), so
+ * The acquire order is the one listed above, from 1 to 2.
+ *
+ * We only have a spinlock (ep->wqlock) to manipulate the waitqueues.
+ * During the event transfer loop (from kernel to user space)
+ * we could end up sleeping due a copy_to_user(), so
  * we need a lock that will allow us to sleep. This lock is a
  * mutex (ep->mtx). It is acquired during the event transfer loop,
  * during epoll_ctl(EPOLL_CTL_DEL) and during eventpoll_release_file().
@@ -82,8 +81,8 @@
  * of epoll file descriptors, we use the current recursion depth as
  * the lockdep subkey.
  * It is possible to drop the "ep->mtx" and to use the global
- * mutex "epmutex" (together with "ep->lock") to have it working,
- * but having "ep->mtx" will make the interface more scalable.
+ * mutex "epmutex" to have it working,  but having "ep->mtx" will
+ * make the interface more scalable.
  * Events that require holding "epmutex" are very rare, while for
  * normal operations the epoll private "ep->mtx" will guarantee
  * a better scalability.
@@ -126,6 +125,23 @@ struct nested_calls {
 };
 
 /*
+ * epitem state transitions   callers
+ * ---
+ * EP_STATE_IDLE-> EP_STATE_READY ep_poll_callback, ep_enqueue_process
+ * EP_STATE_READY   -> EP_STATE_DEQUEUE   ep_send_events
+ * EP_STATE_DEQUEUE -> EP_STATE_IDLE  ep_send_events
+ * EP_STATE_IDLE-> kmem_cache_freeep_remove
+ * EP_STATE_READY   -> EP_STATE_ZOMBIEep_remove
+ * EP_STATE_ZOMBIE  -> kmem_cache_freeep_send_events
+ */
+enum epoll_item_state {
+   EP_STATE_ZOMBIE = -1,
+   EP_STATE_IDLE = 0,
+   EP_STATE_READY = 1,
+   EP_STATE_DEQUEUE = 2
+};
+
+/*
  * Each file descriptor added to the eventp

[Suggestion] Latest randconfig build errors for Head.S

[Chen Gang]

Hello Maintainers:

  are these warnings for head.S OK ?


make:
  make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
(this time, CONFIG_MMU=y)

warning information:
  arch/arm/boot/compressed/head.S: Assembler messages:
  arch/arm/boot/compressed/head.S:565: Warning: (null)
  arch/arm/boot/compressed/head.S:676: Warning: (null)
  arch/arm/boot/compressed/head.S:698: Warning: (null)
  arch/arm/boot/compressed/head.S:722: Warning: (null)
  arch/arm/boot/compressed/head.S:726: Warning: (null)
  arch/arm/boot/compressed/head.S:735: Warning: (null)
  arch/arm/boot/compressed/head.S:978: Warning: (null)
  arch/arm/boot/compressed/head.S:1017: Warning: (null)
  arch/arm/boot/compressed/head.S:1018: Warning: (null)
  arch/arm/boot/compressed/head.S:1048: Warning: (null)
  arch/arm/boot/compressed/head.S:1055: Warning: (null)
  arch/arm/boot/compressed/head.S:1063: Warning: (null)
  arch/arm/boot/compressed/head.S:1074: Warning: (null)
  arch/arm/boot/compressed/head.S:1088: Warning: (null)
  arch/arm/boot/compressed/head.S:1120: Warning: (null)
  arch/arm/boot/compressed/head.S:1122: Warning: (null)
  arch/arm/boot/compressed/head.S:1123: Warning: (null)
  arch/arm/boot/compressed/head.S:1130: Warning: (null)
  arch/arm/boot/compressed/head.S:1162: Warning: (null)



-- 
Chen Gang

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

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

[Stephen Rothwell]

Hi Tejun,

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

I fixed it up (as suggested - 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 55fac5b,2ebd182..000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -456,40 -456,31 +456,32 @@@ static int worker_pool_assign_id(struc
  {
int ret;
  
-   mutex_lock(&worker_pool_idr_mutex);
-   ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
-   if (ret >= 0)
-   pool->id = ret;
-   mutex_unlock(&worker_pool_idr_mutex);
+   do {
 -  if (!idr_pre_get(&worker_pool_idr, GFP_KERNEL))
 -  return -ENOMEM;
 -
++  idr_preload(GFP_KERNEL);
+   spin_lock_irq(&workqueue_lock);
 -  ret = idr_get_new(&worker_pool_idr, pool, &pool->id);
++  ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_NOWAIT);
++  if (ret >= 0)
++  pool->id = ret;
+   spin_unlock_irq(&workqueue_lock);
++  idr_preload_end();
+   } 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(&worker_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 &pools[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(&wq->pwqs, struct pool_workqueue,
+ pwqs_node);
  }
  
  static unsigned int work_color_to_flags(int color)


pgp4mq6dple80.pgp
Description: PGP signature

Re: [PATCH 00/03] gpio: Renesas R-Car GPIO driver update

[Magnus Damm]

Hi Laurent, Simon,

On Wed, Mar 13, 2013 at 9:58 PM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thanks for the patches.

Thanks for your review!

> On Wednesday 13 March 2013 20:32:03 Magnus Damm wrote:
>> gpio: Renesas R-Car GPIO driver update
>>
>> [PATCH 01/03] gpio: Renesas R-Car GPIO driver V2
>> [PATCH 02/03] gpio: rcar: Use IRQCHIP_SET_TYPE_MASKED
>> [PATCH 03/03] gpio: rcar: Make use of devm functions
>>
>> This series updates the R-Car GPIO driver with various
>> changes kindly suggested by Laurent Pinchart.
>>
>> Patch [01/03] is a drop in replacement for V1 of the R-Car
>> GPIO driver. The flag in patch [02/03] is kept out of [01/03]
>> to avoid changing the behaviour of the driver between V1 and V2.
>> Also, devm support in [03/03] is kept out of [01/03] to make
>> sure back porting goes as smooth as possible.
>
> As I mentioned in a previous e-mail, all the devm_* functions used in 03/03
> have been available since 2.6.30. Do you really need to port that driver to
> older kernels ?

Well, it was earlier suggested to me that not using devm to begin with
is a safe way forward for back porting. Also, as the individual patch
shows, we save about 10 lines of code but add many more complex
dependencies.

Simon, do you have any recommendation how for us regarding devm and
back porting?

> Regarding 02/03, do you plan to squash it with 01/03 for the mainline
> submission ?

Not unless someone puts a gun to my head. =) Of course, if a single
patch is really required then I will follow that, but I can't really
see why when we have a nice versioning control system that can help
our development in various ways.

What is the reason behind you wanting to merge these patches?

>From my point of view, if any incremental patch was a bug fix then i
would of course request to fold it in, but in this case these are
feature patches that would be beneficial to keep as individual
commits. Keeping them separate allows us to bisect and also makes
partial back porting easier if needed.

Thanks,

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

Re: [RFC PATCH] Linux kernel Wait-Free Concurrent Queue Implementation

[Eric Wong]

Mathieu Desnoyers  wrote:
> Ported to the Linux kernel from Userspace RCU library, at commit
> 108a92e5b97ee91b2b902dba2dd2e78aab42f420.
> 
> Ref: http://git.lttng.org/userspace-rcu.git
> 
> It is provided as a starting point only. Test cases should be ported
> from Userspace RCU to kernel space and thoroughly ran on a wide range of
> architectures before considering this port production-ready.

Thanks, this seems to work.  Will post an early epoll patch in a minute.

Minor comments below.

> +/*
> + * Load a data from shared memory.
> + */
> +#define CMM_LOAD_SHARED(p)   ACCESS_ONCE(p)

When iterating through the queue by dequeueing, I needed a way
to get the tail at the start of the iteration and use that as
a sentinel while iterating, so I access the tail like this:

struct wfcq_node *p = CMM_LOAD_SHARED(ep->rdltail.p);

I hope this is supported... it seems to work :)

Unlike most queue users, I need to stop iteration to prevent the same
item from appearing in the events returned by epoll_wait; since a
dequeued item may appear back in the wfcqueue immediately.

> +struct wfcq_head {
> + struct wfcq_node node;
> + struct mutex lock;
> +};

I'm not using this lock at all since I already have ep->mtx (which also
protects the ep->rbr).  Perhaps it should not be included; normal linked
list and most data structures I see in the kernel do not provide their
own locks, either

> +static inline void wfcq_init(struct wfcq_head *head,
> + struct wfcq_tail *tail)
> +{
> + /* Set queue head and tail */
> + wfcq_node_init(&head->node);
> + tail->p = &head->node;
> + mutex_init(&head->lock);
> +}

There's no corresponding mutex_destroy, so I'm just destroying it
myself...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] USB: ehci-s5p: Fix phy reset

[Thomas Abraham]

On 14 March 2013 05:29, Alexander Graf  wrote:
> 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.
>
> We also only need to reset the line after the phy node has been found.
> This way we don't accidently reserve the vbus GPIO pin, but later on
> defer the creation of our controller, because the phy device tree node
> hasn't been probed yet.
>
> 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 
> CC: Doug Anderson 
>
> ---
>
> v1 -> v2:
>
>   - remove gpio_free call
>   - move reset logic after phy node search
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 20ebf6a..b29b2b8 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -103,9 +103,14 @@ 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(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
> +   return;
> +   }
> +   mdelay(1);
> +   __gpio_set_value(gpio, 1);
>  }
>
>  static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
> @@ -131,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> if (!pdev->dev.coherent_dma_mask)
> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>
> -   s5p_setup_vbus_gpio(pdev);
> -
> s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
> GFP_KERNEL);
> if (!s5p_ehci)
> @@ -152,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> s5p_ehci->otg = phy->otg;
> }
>
> +   s5p_setup_vbus_gpio(pdev);
> +
> s5p_ehci->dev = &pdev->dev;
>
> hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,

Hi Alexander,

This change, though it works for Exynos5250 based Arndale board, does
not actually seem correct. On Arndale board, the on-board 4-port usb
hub is self powered and hence the vbus 'enable' gpio line from
Exynos5250 SoC is instead used as a "reset" signal for the on-board
usb hub (and not as the vbus enable signal).

Whereas, the driver uses the gpio used in 's5p_setup_vbus_gpio'
function as just a mechanism to enable vbus for downstream devices. So
the driver should not be modified as above to handle the board
specific behavior.

Instead, what needs to be done is, remove the "samsung,vbus-gpio"
property from the usb2.0 node in dts files (this property is optional)
for Arndale board. Then, during the machine_init, perform the reset
sequencing as required.

Ideally, the reset sequencing for the on-board AX88760 usb hub should
have been handled in the driver for this device. I have not checked if
there is a driver for this in the kernel.

Thanks,
Thomas.

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

Re: [PATCH 2/2] PCI: fix system hang issue of Marvell SATA host controller

[Robert Hancock]

On 03/08/2013 09:18 PM, Myron Stowe wrote:

On Thu, Mar 7, 2013 at 11:51 PM, Xiangliang Yu  wrote:

Hi, Bjorn


Fix system hang issue: if first accessed resource file of BAR0 ~
BAR4, system will hang after executing lspci command


This needs more explanation.  We've already read the BARs by the time
header quirks are run, so apparently it's not just the mere act of
accessing a BAR that causes a hang.

We need to know exactly what's going on here.  For example, do BARs
0-4 exist?  Does the device decode accesses to the regions described
by the BARs?  The PCI core has to know what resources the device uses,
so if the device decodes accesses, we can't just throw away the
start/end information.

The BARs 0-4 is exist and the PCI device is enable IO space, but user access

the regions file by udevadm command with info parameter, the system will hang.

Like this: udevadmin info --attribut-walk

--path=/sys/device/pci-device/000:*.

Because the device is just AHCI host controller, don't need the BAR0 ~ 4 region

file.

Is my explanation ok for the patch?


No, I still don't know what causes the hang; I only know that udevadm
can trigger it.  I don't want to just paper over the problem until we
know what the root cause is.

Does "lspci -H1 -vv" also cause a hang?  What about "setpci -s
BASE_ADDRESS_0"?  "setpci -H1 -s BASE_ADDRESS_0"?

The commands are ok because the commands can't find the device after accessing 
IO port.


Xiangliang:

Sorry but I didn't understand your response above, could you elaborate
a little more?


Are the first five BARs of the suspect device all mapping to I/O port
space - i.e. similar to something like this (a capture and inclusion
of an 'lspci' of the suspect device would be nice to see):
   00:1f.2 SATA controller:
 Region 0: I/O ports at 1860 [size=8]
 Region 1: I/O ports at 1814 [size=4]
 Region 2: I/O ports at 1818 [size=8]
 Region 3: I/O ports at 1810 [size=4]
 Region 4: I/O ports at 1840 [size=32]
 Region 5: Memory at f2827000 (32-bit, non-prefetchable) [size=2K]

You have done a good job isolating the issue so far.  As Bjorn noted;
it's looking as if the problem is with accessing the I/O port space
mapped by the suspect device's BAR(s), not with accessing the BAR(s)
in the device's configuration space.


It would seem so. My question is what is accessing the IO port space in 
the first place. BAR5 is the MMIO region used by the AHCI driver. BARs 
0-4 are the legacy SFF-compatible ATA ports. Nothing should be messing 
with those IO ports while AHCI is enabled. It's expected that doing that 
will break things.


If something in udev is randomly groveling around inside the resource 
files for those BARs in sysfs, that seems like a really bad thing.




As you responded positively to earlier, as proposed the suspect device
will still actively be decoding accesses to the regions described by
the BARs.  Because the device is actively decoding the PCI core can't
just throw away the BAR's corresponding resource regions, as the patch
is currently doing, due to the possibility of another device being
added at a later time.

If a subsequent device were added later, the core may need to try and
allocate resources for it and, in the worst case scenario, the core
could end up allocating resources that conflict with this suspect
device as a consequence of the suspect device's original resource
allocations having been silently thrown away.  The result would be
both devices believing they each exclusively own the same set (or
subset) of I/O port mappings and thus both actively decoding accesses
to such which.  A situation that would obviously be disastrous.

There is still something going on here that we still do not
understand.  Could you please capture the following information to
help further isolate the issue:
   A 'dmesg' log from the system which was booted using both the
"debug" and "ignore_loglevel" boot parameters, a 'lspci -xxx -s'
capture, and a 'lspci -vv' capture.

Thanks,
  Myron


The root cause is that accessing of IO port will make the chip go bad. So, the 
point of the patch is don't export capability of the IO accessing.






---
  drivers/pci/quirks.c |   15 +++
  1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 0369fb6..d49f8dc 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -44,6 +44,21 @@ static void quirk_mmio_always_on(struct pci_dev *dev)
  DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
 PCI_CLASS_BRIDGE_HOST, 8,

quirk_mmio_always_on);


+/* The BAR0 ~ BAR4 of Marvell 9125 device can't be accessed
+*  by IO resource file, and need to skip the files
+*/
+static void quirk_marvell_mask_bar(struct pci_dev *dev)
+{
+   int i;
+
+   for (i = 0; i < 5; i++)
+   if (dev->resource[i].start)
+   dev->resource[i].start =
+   dev->resource[i].end = 0;
+}
+

Re: [PATCH 01/03] gpio: Renesas R-Car GPIO driver V2

[Magnus Damm]

On Wed, Mar 13, 2013 at 10:14 PM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thanks for the patch.
>
> I've reviewed the result of squashing the 3 patches together, I just have one
> comment.
>
> On Wednesday 13 March 2013 20:32:13 Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> This patch is V2 of a GPIO driver for the R-Car series of
>> SoCs from Renesas. This driver is designed to be reusable
>> between multiple SoCs that share the same basic building block,
>> but so far it has only been used on R-Car H1 (r8a7779).
>>
>> Each driver instance handles 32 GPIOs with individually
>> maskable IRQs. The driver operates on a single I/O memory
>> range and the 32 GPIOs are hooked up a single interrupt.
>>
>> In the case of R-Car H1 either external IRQ pins or GPIOs
>> with interrupts can be used for on-board interupts. For
>> external IRQs 4 pins are supported, and in the case of GPIO
>> there are 202 GPIOS as 202 interrupts hooked up via 6 driver
>> instances and to the GIC and the Cortex-A9 Quad.
>>
>> At this point this driver is interfacing as a regular
>> platform device driver. In the future DT support will be
>> submitted as an incremental feature patch.
>>
>> Signed-off-by: Magnus Damm 
>> ---
>>
>>  Changes since V1:
>>  - Update based on most suggestions from review by Laurent, thanks!
>>
>>  Please note that in V2 the driver is reworked to reduce the number of
>>  lines and includes minor changes related to headers, printouts and
>>  data types. In V2 the register access order is kept the same as in V1,
>>  and to make that happen IRQCHIP_SET_TYPE_MASKED is omitted. The interface
>>  to the Linux kernel is unchanged except the use of dev_dbg() instead of
>>  pr_debug(). So from a hardware point of view V2 is a drop in replacement
>>  for V1 and there should be no additional dependencies since devm is
>>  kept as a separate patch as well. All this to make back porting easier.
>>
>>  drivers/gpio/Kconfig|6
>>  drivers/gpio/Makefile   |1
>>  drivers/gpio/gpio-rcar.c|  383 
>>  include/linux/platform_data/gpio-rcar.h |   25 ++
>>  4 files changed, 415 insertions(+)
>
> [snip]
>
>> --- /dev/null
>> +++ work/drivers/gpio/gpio-rcar.c 2013-03-13 19:41:35.0 +0900
>> @@ -0,0 +1,383 @@
>> +/*
>> + * Renesas R-Car GPIO Support
>> + *
>> + *  Copyright (C) 2013 Magnus Damm
>> + *
>> + * 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
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>
> [snip]
>
>> +static int gpio_rcar_irq_domain_map(struct irq_domain *h, unsigned int
>> virq,
>> +  irq_hw_number_t hw)
>> +{
>> + struct gpio_rcar_priv *p = h->host_data;
>> +
>> + dev_dbg(&p->pdev->dev, "map hw irq = %d, virq = %d\n", (int)hw, virq);
>> +
>> + irq_set_chip_data(virq, h->host_data);
>> + irq_set_chip_and_handler(virq, &p->irq_chip, handle_level_irq);
>> + set_irq_flags(virq, IRQF_VALID); /* kill me now */
>
> What is that comment about ?

I seem to have a habit of putting that comment in all IRQ code that I
write for ARM. See these threads for more info:

https://lkml.org/lkml/2013/2/19/246
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-January/008795.html

Cheers,

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

Re: NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem

[Theodore Ts'o]

Huh.  This is very, very weird.  Is this a repeatable crash?

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

Re: [PATCH v2] wait while adding MMC host to ensure root mounts

[Namjae Jeon]

2013/3/14, Sergey Yanovich :
> MMC hosts are added asynchronously. We need to wait until detect returns to
> avoid failed root filesystem mounts.
> ---8<---
> VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
> Please append a correct "root=" boot option; here are the available
> partitions:
> mmc0: host does not support reading read-only switch. assuming
> write-enable.
> 1f00 256 mtdblock0  (driver?)
> 1f01 256 mtdblock1  (driver?)
> 1f022560 mtdblock2 mmc0: new SDHC card at address b368
>  (driver?)
> 1f03   29696 mtdblock3  (driver?)
> 1f04   16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
>  (driver?)
>  mmcblk0: p1
> b300 3910656 mmcblk0  driver: mmcblk
>   b301 3906560 mmcblk0p1 -01
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> ---8<---
>
> Signed-off-by: Sergey Yanovich 
> ---
Hi.
Have you ever tried to use rootwait or rootdelay on command line ?
If no, You can use them.

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] gpio: Renesas R-Car GPIO driver

[Magnus Damm]

Hi Linus,

On Thu, Mar 14, 2013 at 2:20 AM, Linus Walleij  wrote:
> On Tue, Mar 5, 2013 at 1:32 AM, Magnus Damm  wrote:
>
>> +static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
>> +{
>> +   struct gpio_rcar_priv *p = irq_data_get_irq_chip_data(d);
>> +   unsigned int hwirq = irqd_to_hwirq(d);
>> +
>> +   pr_debug("gpio: sense irq = %d, type = %d\n", hwirq, type);
>> +
>> +   switch (type & IRQ_TYPE_SENSE_MASK) {
>> +   case IRQ_TYPE_LEVEL_HIGH:
>> +   gpio_rcar_config_interrupt_input_mode(p, hwirq, true, true);
>> +   break;
>> +   case IRQ_TYPE_LEVEL_LOW:
>> +   gpio_rcar_config_interrupt_input_mode(p, hwirq, false, true);
>> +   break;
>> +   case IRQ_TYPE_EDGE_RISING:
>> +   gpio_rcar_config_interrupt_input_mode(p, hwirq, true, false);
>> +   break;
>> +   case IRQ_TYPE_EDGE_FALLING:
>> +   gpio_rcar_config_interrupt_input_mode(p, hwirq, false, 
>> false);
>> +   break;
>
> It is quite common to request IRQ on *both* rising and falling edges,
> what happens then?
>
> See 
> IRQ_TYPE_EDGE_RISING= 0x0001,
> IRQ_TYPE_EDGE_FALLING   = 0x0002,
> IRQ_TYPE_EDGE_BOTH  = (IRQ_TYPE_EDGE_FALLING |
> IRQ_TYPE_EDGE_RISING),
>
> I guess then you get just rising edge...

I may be wrong, but the switch above does AND with IRQ_TYPE_SENSE_MASK
which makes me believe that the BOTH case will result in -EINVAL.

The -EINVAL is IMO correct here since the most basic version of this
GPIO block (used in r8a7779) does not suport BOTH edges. I've noticed
that newer versions of that GPIO hardware block has additional
registers where this can be selected. My plan is to submit an
incremental patch for such feature in the not so distant future.

> The rest I think is already covered by Laurent's comments.

Ok, thanks for your help!

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] epoll: cleanup: hoist out f_op->poll calls

[Eric Wong]

This reduces the amount of code inside the ready list iteration loops
for better readability IMHO.

Signed-off-by: Eric Wong 
Cc: Davide Libenzi 
Cc: Al Viro 
Cc: Andrew Morton 
---
 (I think this depends on my RCU wakeup source patch sitting in -mm)

 fs/eventpoll.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index d71b754..a4e4ad7 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -772,6 +772,13 @@ static int ep_eventpoll_release(struct inode *inode, 
struct file *file)
return 0;
 }
 
+static inline unsigned int ep_item_poll(struct epitem *epi, poll_table *pt)
+{
+   pt->_key = epi->event.events;
+
+   return epi->ffd.file->f_op->poll(epi->ffd.file, pt) & epi->event.events;
+}
+
 static int ep_read_events_proc(struct eventpoll *ep, struct list_head *head,
   void *priv)
 {
@@ -779,10 +786,9 @@ static int ep_read_events_proc(struct eventpoll *ep, 
struct list_head *head,
poll_table pt;
 
init_poll_funcptr(&pt, NULL);
+
list_for_each_entry_safe(epi, tmp, head, rdllink) {
-   pt._key = epi->event.events;
-   if (epi->ffd.file->f_op->poll(epi->ffd.file, &pt) &
-   epi->event.events)
+   if (ep_item_poll(epi, &pt))
return POLLIN | POLLRDNORM;
else {
/*
@@ -1256,7 +1262,6 @@ static int ep_insert(struct eventpoll *ep, struct 
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);
-   epq.pt._key = event->events;
 
/*
 * Attach the item to the poll hooks and get current event bits.
@@ -1265,7 +1270,7 @@ static int ep_insert(struct eventpoll *ep, struct 
epoll_event *event,
 * this operation completes, the poll callback can start hitting
 * the new item.
 */
-   revents = tfile->f_op->poll(tfile, &epq.pt);
+   revents = ep_item_poll(epi, &epq.pt);
 
/*
 * We have to check if something went wrong during the poll wait queue
@@ -1365,7 +1370,6 @@ static int ep_modify(struct eventpoll *ep, struct epitem 
*epi, struct epoll_even
 * f_op->poll() call and the new event set registering.
 */
epi->event.events = event->events; /* need barrier below */
-   pt._key = event->events;
epi->event.data = event->data; /* protected by mtx */
if (epi->event.events & EPOLLWAKEUP) {
if (!ep_has_wakeup_source(epi))
@@ -1398,7 +1402,7 @@ static int ep_modify(struct eventpoll *ep, struct epitem 
*epi, struct epoll_even
 * Get current event bits. We can safely use the file* here because
 * its usage count has been increased by the caller of this function.
 */
-   revents = epi->ffd.file->f_op->poll(epi->ffd.file, &pt);
+   revents = ep_item_poll(epi, &pt);
 
/*
 * If the item is "hot" and it is not registered inside the ready
@@ -1466,9 +1470,7 @@ static int ep_send_events_proc(struct eventpoll *ep, 
struct list_head *head,
 
list_del_init(&epi->rdllink);
 
-   pt._key = epi->event.events;
-   revents = epi->ffd.file->f_op->poll(epi->ffd.file, &pt) &
-   epi->event.events;
+   revents = ep_item_poll(epi, &pt);
 
/*
 * If the event mask intersect the caller-requested one,
-- 
Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers: dma: Use devm_ioremap_resource

[Sachin Kamat]

On 14 March 2013 04:47, Alexandru Gheorghiu  wrote:
> Replaced call to devm_request_and_ioremap with devm_ioremap_resource which
> provides better error handling.
>
> Signed-off-by: Alexandru Gheorghiu 
> ---

Already sent a similar patch to do this:
https://patchwork.kernel.org/patch/2211801/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Suggestion] Latest randconfig build errors for CONFIG_MMU=no

[Chen Gang]

also has additional information (maybe useful):

  arch/arm/kernel/entry-armv.S:404:2: 警告：#warning "NPTL on non MMU needs 
fixing" [-Wcpp]
  arch/arm/kernel/entry-armv.S:867:2: 警告：#warning "NPTL on non MMU needs 
fixing" [-Wcpp]
  arch/arm/kernel/entry-armv.S:940:2: 警告：#warning "NPTL on non MMU needs 
fixing" [-Wcpp]


于 2013年03月14日 11:44, Chen Gang 写道:
> Hello Maintainers:
> 
>   when use randconfig:
> make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
>   (and "grep CONFIG_MMU .config" outputs "# CONFIG_MMU is not set")
> 
>   the error information:
> arch/arm/kernel/suspend.c: 在函数‘cpu_suspend’中:
> arch/arm/kernel/suspend.c:56:32: 错误：提领指向不完全类型的指针
> arch/arm/kernel/suspend.c:70:3: 错误：隐式声明函数‘cpu_switch_mm’ 
> [-Werror=implicit-function-declaration]
> arch/arm/kernel/suspend.c:71:3: 错误：隐式声明函数‘local_flush_bp_all’ 
> [-Werror=implicit-function-declaration]
> arch/arm/kernel/suspend.c:72:3: 错误：隐式声明函数‘local_flush_tlb_all’ 
> [-Werror=implicit-function-declaration]
> 
>   I want to be sure whether we can bear it ?
> 
>   thanks.
> 


-- 
Chen Gang

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

[Suggestion] Latest randconfig build errors for CONFIG_MMU=no

[Chen Gang]

Hello Maintainers:

  when use randconfig:
make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
  (and "grep CONFIG_MMU .config" outputs "# CONFIG_MMU is not set")

  the error information:
arch/arm/kernel/suspend.c: 在函数‘cpu_suspend’中:
arch/arm/kernel/suspend.c:56:32: 错误：提领指向不完全类型的指针
arch/arm/kernel/suspend.c:70:3: 错误：隐式声明函数‘cpu_switch_mm’ 
[-Werror=implicit-function-declaration]
arch/arm/kernel/suspend.c:71:3: 错误：隐式声明函数‘local_flush_bp_all’ 
[-Werror=implicit-function-declaration]
arch/arm/kernel/suspend.c:72:3: 错误：隐式声明函数‘local_flush_tlb_all’ 
[-Werror=implicit-function-declaration]

  I want to be sure whether we can bear it ?

  thanks.

-- 
Chen Gang

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

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

[Doug Anderson]

Alexander,

On Wed, Mar 13, 2013 at 4:59 PM, Alexander Graf  wrote:
> 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.
>
> We also only need to reset the line after the phy node has been found.
> This way we don't accidently reserve the vbus GPIO pin, but later on
> defer the creation of our controller, because the phy device tree node
> hasn't been probed yet.
>
> 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 
> CC: Doug Anderson 
>
> ---
>
> v1 -> v2:
>
>   - remove gpio_free call
>   - move reset logic after phy node search

Seems fine to me.  I guess the earlier problem you wrote about was the
probe failure, then?  I think that the reason I don't tend to get the
probe failure is that I've got my device tree ordered differently so
that the phy gets initted in a different order.

I'll send up the devm_ patch atop this.

Reviewed-by: Doug Anderson 

Thanks!  :)

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

Re: [PATCH V3 4/4] cpufreq: Add Kconfig option to enable/disable have_multiple_policies

[Viresh Kumar]

On 14 March 2013 03:11, Rafael J. Wysocki  wrote:
> On Tuesday, March 12, 2013 08:55:12 AM Viresh Kumar wrote:
>> On 12 March 2013 07:38, Rafael J. Wysocki  wrote:
>> > One more question before I apply it.
>> >
>> > Is there any architecture/platform that will set
>> > CONFIG_CPU_FREQ_HAVE_MULTIPLE_POLICIES and keep have_multiple_policies 
>> > unset
>> > at the same time?
>>
>> No, they are redundant. That's why i have been forcing to drop this patch.
>
> I see.
>
> What about having the Kconfig option alone, however?

Even that is not enough. We build multiplatform kernels and so need a
variable to be set by platform.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 mm] epoll: lock ep->mtx in ep_free to silence lockdep

[Eric Wong]

Technically we do not need to hold ep->mtx during ep_free since we are
certain there are no other users of ep at that point.  However, lockdep
complains with a "suspicious rcu_dereference_check() usage!" message;
so lock the mutex before ep_remove to silence the warning.

Signed-off-by: Eric Wong 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Arve Hjønnevåg 
Cc: Davide Libenzi 
Cc: Eric Dumazet 
Cc: NeilBrown ,
Cc: Rafael J. Wysocki 
---
  I considered using lockdep_off()/lockdep_on(), but I figure that may
  hide other bugs...

 fs/eventpoll.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 633e69f..d71b754 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -745,11 +745,15 @@ static void ep_free(struct eventpoll *ep)
 * point we are sure no poll callbacks will be lingering around, and 
also by
 * holding "epmutex" we can be sure that no file cleanup code will hit
 * us during this operation. So we can avoid the lock on "ep->lock".
+* We do not need to lock ep->mtx, either, we only do it to prevent
+* a lockdep warning.
 */
+   mutex_lock(&ep->mtx);
while ((rbp = rb_first(&ep->rbr)) != NULL) {
epi = rb_entry(rbp, struct epitem, rbn);
ep_remove(ep, epi);
}
+   mutex_unlock(&ep->mtx);
 
mutex_unlock(&epmutex);
mutex_destroy(&ep->mtx);
-- 
Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/3] mtd: add the support to parse out the full-id nand type

[Huang Shijie]

When we meet a full-id nand type which @mfr_id is true, we can use
the find_full_id_nand() to parse out the neccessary information for a
nand chip.

If we meet a non full-id nand type, we can handle it in the lagacy way.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_base.c |   36 +---
 1 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 72eada2..b7ad9fd 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3123,6 +3123,30 @@ static void nand_decode_bbm_options(struct mtd_info *mtd,
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
 }
 
+static inline bool is_full_id_nand(struct nand_flash_dev *type)
+{
+   return type->mfr_id;
+}
+
+static bool find_full_id_nand(struct mtd_info *mtd, struct nand_chip *chip,
+  struct nand_flash_dev *type, u8 *id_data, int *busw)
+{
+   if (!strncmp(type->id, id_data, 8)) {
+   mtd->writesize = type->pagesize;
+   mtd->erasesize = type->erasesize;
+   mtd->oobsize = type->oobsize;
+
+   chip->cellinfo = id_data[2];
+   chip->chipsize = (uint64_t)type->chipsize << 20;
+   chip->options |= type->options;
+
+   *busw = type->options & NAND_BUSWIDTH_16;
+
+   return true;
+   }
+   return false;
+}
+
 /*
  * Get the flash and manufacturer id and lookup if the type is supported.
  */
@@ -3174,9 +3198,15 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (!type)
type = nand_flash_ids;
 
-   for (; type->name != NULL; type++)
-   if (*dev_id == type->dev_id)
-   break;
+   for (; type->name != NULL; type++) {
+   if (is_full_id_nand(type)) {
+   if (find_full_id_nand(mtd, chip, type, id_data, &busw))
+   goto ident_done;
+   } else {
+   if (*dev_id == type->dev_id)
+   break;
+   }
+   }
 
chip->onfi_version = 0;
if (!type->name || !type->pagesize) {
-- 
1.7.1


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

[PATCH v5 3/3] mtd: add 4 Toshiba nand chips for the full-id case

[Huang Shijie]

I have 4 Toshiba nand chips which can not be parsed out by the
id data. We can not get the oob size from the id data. So add them
as the full-id nand chips in the first of nand_flash_ids.

The nand_get_flash_type() scans the full id nands firstly.
If a full-id nand matchs, it will not continue to parse other
non-full-id nand types, else it will continue to parse the non-full-id nands.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_ids.c |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 625bc89..38b8cee 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 
 
 #define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
 #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
@@ -22,6 +23,27 @@
  * extended chip ID.
  */
 struct nand_flash_dev nand_flash_ids[] = {
+   /*
+* The full-id nands may share the same Device ID with the non-full-id
+* nands. In order to distinguish the two type nands, we put the
+* full-id nands in the first of the table. So the nand_get_flash_type()
+* scans the full id nands firstly. If a full-id nand matchs, it will
+* not continue to parse other non-full-id nand types, else it will
+* continue to parse the non-full-id nands.
+*/
+   {"TC58NVG2S0F 4G 3.3V 8-bit",
+   { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
+   SZ_4K, SZ_512, SZ_256K, 0, 224},
+   {"TC58NVG3S0F 8G 3.3V 8-bit",
+   { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
+   SZ_4K, SZ_1K, SZ_256K, 0, 232},
+   {"TC58NVG5D2 32G 3.3V 8-bit",
+   { .id = {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00} },
+   SZ_8K, SZ_4K, SZ_1M, 0, 640},
+   {"TC58NVG6D2 64G 3.3V 8-bit",
+   { .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
+   SZ_8K, SZ_8K, SZ_2M, 0, 640},
+
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 512, 4, 0x2000, 0),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 512, 4, 0x2000, 0),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE5, 512, 4, 0x2000, 0),
-- 
1.7.1


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

[PATCH v5 0/3] mtd: use the full-id as the keyword for some nand chips

[Huang Shijie]

As time goes on, we begin to meet the situation that we can not
get enough information from some nand chips's id data.
Take some Toshiba's nand chips for example.
I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2

When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2  : 8192 + 640
TC58NVG6D2  : 8192 + 640

But we can not parse out the correct oob size for these chips from the id data.
So it is time to add some new fields to the nand_flash_dev{},
and update the detection mechanisms.

v4 --> v4:
[1] remove the id_len field.
[2] based on Artem "mtd: nand: use more reasonable integer types"
[3] add more comments.

v3 --> v4:
[1] rewrite the code based on the latest l2-mtd.
[2] add the full-id nand in the nand_flash_lds.

v2 --> v3:
[1] remove the duplicated header.
[2] remove the field "ecc_len" in nand_flash_dev{}.
[3] fix some coding style warnings.
[4] add more comments

Huang Shijie (3):
  mtd: add a new field for nand_flash_dev{}
  mtd: add the support to parse out the full-id nand type
  mtd: add 4 Toshiba nand chips for the full-id case

 drivers/mtd/nand/nand_base.c |   36 +---
 drivers/mtd/nand/nand_ids.c  |   22 ++
 include/linux/mtd/nand.h |2 ++
 3 files changed, 57 insertions(+), 3 deletions(-)


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

[PATCH v5 1/3] mtd: add a new field for nand_flash_dev{}

[Huang Shijie]

As time goes on, we begin to meet the situation that we can not get enough
information from some nand chips's id data. Take some Toshiba's nand chips
for example. I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2

When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2  : 8192 + 640
TC58NVG6D2  : 8192 + 640

But we can not parse out the correct oob size for these chips from the id data.

This patch adds @oobsize for the nand_flash_dev{} to store the oob size for
these nands.

Signed-off-by: Huang Shijie 
---
 include/linux/mtd/nand.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index e2c7173..42862e9 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -581,6 +581,7 @@ struct nand_chip {
  * @chipsize: total chip size in MiB
  * @erasesize: eraseblock size in bytes (determined from the extended ID if 0)
  * @options: stores various chip bit options
+ * @oobsize: OOB size
  */
 struct nand_flash_dev {
char *name;
@@ -595,6 +596,7 @@ struct nand_flash_dev {
unsigned int chipsize;
unsigned int erasesize;
unsigned int options;
+   unsigned int oobsize;
 };
 
 /**
-- 
1.7.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/7] workqueue: factor out initial worker creation into create_and_start_worker()

[Tejun Heo]

get_unbound_pool(), workqueue_cpu_up_callback() and init_workqueues()
have similar code pieces to create and start the initial worker factor
those out into create_and_start_worker().

This patch doesn't introduce any functional changes.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 47 +++
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index bc25bdf..cac7106 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1793,6 +1793,26 @@ static void start_worker(struct worker *worker)
 }
 
 /**
+ * create_and_start_worker - create and start a worker for a pool
+ * @pool: the target pool
+ *
+ * Create and start a new worker for @pool.
+ */
+static int create_and_start_worker(struct worker_pool *pool)
+{
+   struct worker *worker;
+
+   worker = create_worker(pool);
+   if (worker) {
+   spin_lock_irq(&pool->lock);
+   start_worker(worker);
+   spin_unlock_irq(&pool->lock);
+   }
+
+   return worker ? 0 : -ENOMEM;
+}
+
+/**
  * destroy_worker - destroy a workqueue worker
  * @worker: worker to be destroyed
  *
@@ -3542,7 +3562,6 @@ static struct worker_pool *get_unbound_pool(const struct 
workqueue_attrs *attrs)
static DEFINE_MUTEX(create_mutex);
u32 hash = wqattrs_hash(attrs);
struct worker_pool *pool;
-   struct worker *worker;
 
mutex_lock(&create_mutex);
 
@@ -3568,14 +3587,9 @@ static struct worker_pool *get_unbound_pool(const struct 
workqueue_attrs *attrs)
goto fail;
 
/* create and start the initial worker */
-   worker = create_worker(pool);
-   if (!worker)
+   if (create_and_start_worker(pool) < 0)
goto fail;
 
-   spin_lock_irq(&pool->lock);
-   start_worker(worker);
-   spin_unlock_irq(&pool->lock);
-
/* install */
spin_lock_irq(&workqueue_lock);
hash_add(unbound_pool_hash, &pool->hash_node, hash);
@@ -4148,18 +4162,10 @@ static int __cpuinit workqueue_cpu_up_callback(struct 
notifier_block *nfb,
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
for_each_cpu_worker_pool(pool, cpu) {
-   struct worker *worker;
-
if (pool->nr_workers)
continue;
-
-   worker = create_worker(pool);
-   if (!worker)
+   if (create_and_start_worker(pool) < 0)
return NOTIFY_BAD;
-
-   spin_lock_irq(&pool->lock);
-   start_worker(worker);
-   spin_unlock_irq(&pool->lock);
}
break;
 
@@ -4409,15 +4415,8 @@ static int __init init_workqueues(void)
struct worker_pool *pool;
 
for_each_cpu_worker_pool(pool, cpu) {
-   struct worker *worker;
-
pool->flags &= ~POOL_DISASSOCIATED;
-
-   worker = create_worker(pool);
-   BUG_ON(!worker);
-   spin_lock_irq(&pool->lock);
-   start_worker(worker);
-   spin_unlock_irq(&pool->lock);
+   BUG_ON(create_and_start_worker(pool) < 0);
}
}
 
-- 
1.8.1.4

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

[PATCHSET wq/for-3.10] workqueue: break up workqueue_lock into multiple locks

[Tejun Heo]

Hello,

Currently, workqueue_lock protects most shared workqueue resources -
the pools, workqueues, pool_workqueues, draining, ID assignments,
mayday handling and so on.  The coverage has grown organically and
there is no identified bottleneck coming from workqueue_lock, but it
has grown a bit too much and scheduled rebinding changes need the
pools and workqueues to be protected by a mutex instead of a spinlock.

The following seven patches break out workqueue_lock into three locks
- wq_mutex, pwq_lock and wq_mayday_lock - so that we get to have a
mutex for pools and workqueues, and the overall locking scheme is
easier to follow.

 0001-workqueue-rename-worker_pool-assoc_mutex-to-manager_.patch
 0002-workqueue-factor-out-initial-worker-creation-into-cr.patch
 0003-workqueue-better-define-locking-rules-around-worker-.patch
 0004-workqueue-relocate-global-variable-defs-and-function.patch
 0005-workqueue-separate-out-pool-and-workqueue-locking-in.patch
 0006-workqueue-separate-out-pool_workqueue-locking-into-p.patch
 0007-workqueue-rename-workqueue_lock-to-wq_mayday_lock.patch

0001-0004 are prep / cleanup patches.

0005 separates out pool and workqueue locking into wq_mutex.

0006 separates out pool_workqueue locking into pwq_lock.

0007 renames workqueue_lock to wq_mayday_lock as that's the only left
user of the lock.

This patchset is on top of

  wq/for-3.10 e626761691 ("workqueue: implement current_is_workqueue_rescuer()")
+ "workqueue: misc cleanups" patchset [1]

and available in the following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-finer-locking

diffstat follows.  Thanks.

 kernel/workqueue.c |  355 +
 1 file changed, 195 insertions(+), 160 deletions(-)

--
tejun

[1] http://thread.gmane.org/gmane.linux.kernel/1456511
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] workqueue: better define locking rules around worker creation / destruction

[Tejun Heo]

When a manager creates or destroys workers, the operations are always
done with the manager_mutex held; however, initial worker creation or
worker destruction during pool release don't grab the mutex.  They are
still correct as initial worker creation doesn't require
synchronization and grabbing manager_arb provides enough exclusion for
pool release path.

Still, let's make everyone follow the same rules for consistency and
such that lockdep annotations can be added.

Update create_and_start_worker() and put_unbound_pool() to grab
manager_mutex around thread creation and destruction respectively and
add lockdep assertions to create_worker() and destroy_worker().

This patch doesn't introduce any visible behavior changes.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index cac7106..ce1ab06 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1715,6 +1715,8 @@ static struct worker *create_worker(struct worker_pool 
*pool)
struct worker *worker = NULL;
int id = -1;
 
+   lockdep_assert_held(&pool->manager_mutex);
+
spin_lock_irq(&pool->lock);
while (ida_get_new(&pool->worker_ida, &id)) {
spin_unlock_irq(&pool->lock);
@@ -1796,12 +1798,14 @@ static void start_worker(struct worker *worker)
  * create_and_start_worker - create and start a worker for a pool
  * @pool: the target pool
  *
- * Create and start a new worker for @pool.
+ * Grab the managership of @pool and create and start a new worker for it.
  */
 static int create_and_start_worker(struct worker_pool *pool)
 {
struct worker *worker;
 
+   mutex_lock(&pool->manager_mutex);
+
worker = create_worker(pool);
if (worker) {
spin_lock_irq(&pool->lock);
@@ -1809,6 +1813,8 @@ static int create_and_start_worker(struct worker_pool 
*pool)
spin_unlock_irq(&pool->lock);
}
 
+   mutex_unlock(&pool->manager_mutex);
+
return worker ? 0 : -ENOMEM;
 }
 
@@ -1826,6 +1832,9 @@ static void destroy_worker(struct worker *worker)
struct worker_pool *pool = worker->pool;
int id = worker->id;
 
+   lockdep_assert_held(&pool->manager_mutex);
+   lockdep_assert_held(&pool->lock);
+
/* sanity check frenzy */
if (WARN_ON(worker->current_work) ||
WARN_ON(!list_empty(&worker->scheduled)))
@@ -3531,6 +3540,7 @@ static void put_unbound_pool(struct worker_pool *pool)
 * manager_mutex.
 */
mutex_lock(&pool->manager_arb);
+   mutex_lock(&pool->manager_mutex);
spin_lock_irq(&pool->lock);
 
while ((worker = first_worker(pool)))
@@ -3538,6 +3548,7 @@ static void put_unbound_pool(struct worker_pool *pool)
WARN_ON(pool->nr_workers || pool->nr_idle);
 
spin_unlock_irq(&pool->lock);
+   mutex_unlock(&pool->manager_mutex);
mutex_unlock(&pool->manager_arb);
 
/* shut down the timers */
-- 
1.8.1.4

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

[PATCH 5/7] workqueue: separate out pool and workqueue locking into wq_mutex

[Tejun Heo]

Currently, workqueue_lock protects most shared workqueue resources -
the pools, workqueues, pool_workqueues, draining, ID assignments,
mayday handling and so on.  The coverage has grown organically and
there is no identified bottleneck coming from workqueue_lock, but it
has grown a bit too much and scheduled rebinding changes need the
pools and workqueues to be protected by a mutex instead of a spinlock.

This patch breaks out pool and workqueue synchronization from
workqueue_lock into a new mutex - wq_mutex.  The followings are
protected by wq_mutex.

* worker_pool_idr and unbound_pool_hash
* pool->refcnt
* workqueues list
* workqueue->flags, ->nr_drainers

Most changes are mostly straight-forward.  workqueue_lock is replaced
with wq_mutex where applicable and workqueue_lock lock/unlocks are
added where wq_mutex conversion leaves data structures not protected
by wq_mutex without locking.  irq / preemption flippings were added
where the conversion affects them.  Things worth noting are

* New WQ and WR locking lables added along with
  assert_rcu_or_wq_mutex().

* worker_pool_assign_id() now expects to be called under wq_mutex.

* create_mutex is removed from get_unbound_pool().  It now just holds
  wq_mutex.

This patch shouldn't introduce any visible behavior changes.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 146 -
 1 file changed, 77 insertions(+), 69 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9a0cbb2..c3b59ff 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -119,9 +119,11 @@ enum {
  *
  * F: wq->flush_mutex protected.
  *
- * W: workqueue_lock protected.
+ * WQ: wq_mutex protected.
+ *
+ * WR: wq_mutex protected for writes.  Sched-RCU protected for reads.
  *
- * R: workqueue_lock protected for writes.  Sched-RCU protected for reads.
+ * W: workqueue_lock protected.
  *
  * FR: wq->flush_mutex and workqueue_lock protected for writes.  Sched-RCU
  * protected for reads.
@@ -155,8 +157,8 @@ struct worker_pool {
struct ida  worker_ida; /* L: for worker IDs */
 
struct workqueue_attrs  *attrs; /* I: worker attributes */
-   struct hlist_node   hash_node;  /* W: unbound_pool_hash node */
-   int refcnt; /* W: refcnt for unbound pools 
*/
+   struct hlist_node   hash_node;  /* WQ: unbound_pool_hash node */
+   int refcnt; /* WQ: refcnt for unbound pools 
*/
 
/*
 * The current concurrency level.  As it's likely to be accessed
@@ -218,10 +220,10 @@ struct wq_device;
  * the appropriate worker_pool through its pool_workqueues.
  */
 struct workqueue_struct {
-   unsigned intflags;  /* W: WQ_* flags */
+   unsigned intflags;  /* WQ: WQ_* flags */
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwq's */
struct list_headpwqs;   /* FR: all pwqs of this wq */
-   struct list_headlist;   /* W: list of all workqueues */
+   struct list_headlist;   /* WQ: list of all workqueues */
 
struct mutexflush_mutex;/* protects wq flushing */
int work_color; /* F: current work color */
@@ -234,7 +236,7 @@ struct workqueue_struct {
struct list_headmaydays;/* W: pwqs requesting rescue */
struct worker   *rescuer;   /* I: rescue worker */
 
-   int nr_drainers;/* W: drain in progress */
+   int nr_drainers;/* WQ: drain in progress */
int saved_max_active; /* W: saved pwq max_active */
 
 #ifdef CONFIG_SYSFS
@@ -248,22 +250,19 @@ struct workqueue_struct {
 
 static struct kmem_cache *pwq_cache;
 
-/* Serializes the accesses to the list of workqueues. */
+static DEFINE_MUTEX(wq_mutex); /* protects workqueues and pools */
 static DEFINE_SPINLOCK(workqueue_lock);
-static LIST_HEAD(workqueues);
-static bool workqueue_freezing;/* W: have wqs started 
freezing? */
+
+static LIST_HEAD(workqueues);  /* WQ: list of all workqueues */
+static bool workqueue_freezing;/* WQ: have wqs started 
freezing? */
 
 /* the per-cpu worker pools */
 static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
 cpu_worker_pools);
 
-/*
- * R: idr of all pools.  Modifications are protected by workqueue_lock.
- * Read accesses are protected by sched-RCU protected.
- */
-static DEFINE_IDR(worker_pool_idr);
+static DEFINE_IDR(worker_pool_idr);/* WR: idr of all pools */
 
-/* W: hash of all unbound pools keyed by pool->attrs */
+/* WQ: hash of all unbound pools keyed by pool->attrs */
 static DEFINE_HASHTABLE(unbound_pool_hash, UNBOUND_POOL_HASH_ORDER);
 
 /* I: attributes used when instantiating stand

Re: Question about a patch for stable

[Steven Rostedt]

On Wed, 2013-03-13 at 19:48 -0700, Greg Kroah-Hartman wrote:

> I always defer to the maintainer of the subsystem, so it's up to you.

Great! I'll add them all :-)   It just irritates me when I do a stack
trace and see some strange results. Even when I know they are minor and
understand why they happen. But if they can be fixed, they should be!

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] workqueue: separate out pool_workqueue locking into pwq_lock

[Tejun Heo]

This patch continues locking cleanup from the previous patch.  It
breaks out pool_workqueue synchronization from workqueue_lock into a
new spinlock - pwq_lock.  The followings are protected by pwq_lock.

* workqueue->pwqs
* workqueue->saved_max_active

The conversion is straight-forward.  workqueue_lock usages which cover
the above two are converted to pwq_lock.  New locking label PW added
for things protected by pwq_lock and FR is updated to mean flush_mutex
+ pwq_lock + sched-RCU.

This patch shouldn't introduce any visible behavior changes.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 69 --
 1 file changed, 36 insertions(+), 33 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c3b59ff..63856df 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -123,9 +123,11 @@ enum {
  *
  * WR: wq_mutex protected for writes.  Sched-RCU protected for reads.
  *
+ * PW: pwq_lock protected.
+ *
  * W: workqueue_lock protected.
  *
- * FR: wq->flush_mutex and workqueue_lock protected for writes.  Sched-RCU
+ * FR: wq->flush_mutex and pwq_lock protected for writes.  Sched-RCU
  * protected for reads.
  */
 
@@ -198,7 +200,7 @@ struct pool_workqueue {
 * Release of unbound pwq is punted to system_wq.  See put_pwq()
 * and pwq_unbound_release_workfn() for details.  pool_workqueue
 * itself is also sched-RCU protected so that the first pwq can be
-* determined without grabbing workqueue_lock.
+* determined without grabbing pwq_lock.
 */
struct work_struct  unbound_release_work;
struct rcu_head rcu;
@@ -237,7 +239,7 @@ struct workqueue_struct {
struct worker   *rescuer;   /* I: rescue worker */
 
int nr_drainers;/* WQ: drain in progress */
-   int saved_max_active; /* W: saved pwq max_active */
+   int saved_max_active; /* PW: saved pwq max_active */
 
 #ifdef CONFIG_SYSFS
struct wq_device*wq_dev;/* I: for sysfs interface */
@@ -251,6 +253,7 @@ struct workqueue_struct {
 static struct kmem_cache *pwq_cache;
 
 static DEFINE_MUTEX(wq_mutex); /* protects workqueues and pools */
+static DEFINE_SPINLOCK(pwq_lock);  /* protects pool_workqueues */
 static DEFINE_SPINLOCK(workqueue_lock);
 
 static LIST_HEAD(workqueues);  /* WQ: list of all workqueues */
@@ -291,10 +294,10 @@ static void copy_workqueue_attrs(struct workqueue_attrs 
*to,
   lockdep_is_held(&wq_mutex),  \
   "sched RCU or wq_mutex should be held")
 
-#define assert_rcu_or_wq_lock()
\
+#define assert_rcu_or_pwq_lock()   \
rcu_lockdep_assert(rcu_read_lock_sched_held() ||\
-  lockdep_is_held(&workqueue_lock),\
-  "sched RCU or workqueue lock should be held")
+  lockdep_is_held(&pwq_lock),  \
+  "sched RCU or pwq_lock should be held")
 
 #define for_each_cpu_worker_pool(pool, cpu)\
for ((pool) = &per_cpu(cpu_worker_pools, cpu)[0];   \
@@ -326,16 +329,16 @@ static void copy_workqueue_attrs(struct workqueue_attrs 
*to,
  * @pwq: iteration cursor
  * @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.
+ * This must be called either with pwq_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.
  *
  * The if/else clause exists only for the lockdep assertion and can be
  * ignored.
  */
 #define for_each_pwq(pwq, wq)  \
list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node)  \
-   if (({ assert_rcu_or_wq_lock(); false; })) { }  \
+   if (({ assert_rcu_or_pwq_lock(); false; })) { } \
else
 
 #ifdef CONFIG_DEBUG_OBJECTS_WORK
@@ -474,13 +477,13 @@ static int worker_pool_assign_id(struct worker_pool *pool)
  * 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.
+ * This must be called either with pwq_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 

[PATCH 7/7] workqueue: rename workqueue_lock to wq_mayday_lock

[Tejun Heo]

With the recent locking updates, the only thing protected by
workqueue_lock is workqueue->maydays list.  Rename workqueue_lock to
wq_mayday_lock.

This patch is pure rename.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 63856df..969be0b 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -125,10 +125,10 @@ enum {
  *
  * PW: pwq_lock protected.
  *
- * W: workqueue_lock protected.
- *
  * FR: wq->flush_mutex and pwq_lock protected for writes.  Sched-RCU
  * protected for reads.
+ *
+ * MD: wq_mayday_lock protected.
  */
 
 /* struct worker is defined in workqueue_internal.h */
@@ -194,7 +194,7 @@ struct pool_workqueue {
int max_active; /* L: max active works */
struct list_headdelayed_works;  /* L: delayed works */
struct list_headpwqs_node;  /* FR: node on wq->pwqs */
-   struct list_headmayday_node;/* W: node on wq->maydays */
+   struct list_headmayday_node;/* MD: node on wq->maydays */
 
/*
 * Release of unbound pwq is punted to system_wq.  See put_pwq()
@@ -235,7 +235,7 @@ struct workqueue_struct {
struct list_headflusher_queue;  /* F: flush waiters */
struct list_headflusher_overflow; /* F: flush overflow list */
 
-   struct list_headmaydays;/* W: pwqs requesting rescue */
+   struct list_headmaydays;/* MD: pwqs requesting rescue */
struct worker   *rescuer;   /* I: rescue worker */
 
int nr_drainers;/* WQ: drain in progress */
@@ -254,7 +254,7 @@ static struct kmem_cache *pwq_cache;
 
 static DEFINE_MUTEX(wq_mutex); /* protects workqueues and pools */
 static DEFINE_SPINLOCK(pwq_lock);  /* protects pool_workqueues */
-static DEFINE_SPINLOCK(workqueue_lock);
+static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
 
 static LIST_HEAD(workqueues);  /* WQ: list of all workqueues */
 static bool workqueue_freezing;/* WQ: have wqs started 
freezing? */
@@ -1894,7 +1894,7 @@ static void send_mayday(struct work_struct *work)
struct pool_workqueue *pwq = get_work_pwq(work);
struct workqueue_struct *wq = pwq->wq;
 
-   lockdep_assert_held(&workqueue_lock);
+   lockdep_assert_held(&wq_mayday_lock);
 
if (!wq->rescuer)
return;
@@ -1911,7 +1911,7 @@ static void pool_mayday_timeout(unsigned long __pool)
struct worker_pool *pool = (void *)__pool;
struct work_struct *work;
 
-   spin_lock_irq(&workqueue_lock); /* for wq->maydays */
+   spin_lock_irq(&wq_mayday_lock); /* for wq->maydays */
spin_lock(&pool->lock);
 
if (need_to_create_worker(pool)) {
@@ -1926,7 +1926,7 @@ static void pool_mayday_timeout(unsigned long __pool)
}
 
spin_unlock(&pool->lock);
-   spin_unlock_irq(&workqueue_lock);
+   spin_unlock_irq(&wq_mayday_lock);
 
mod_timer(&pool->mayday_timer, jiffies + MAYDAY_INTERVAL);
 }
@@ -2404,7 +2404,7 @@ repeat:
}
 
/* see whether any pwq is asking for help */
-   spin_lock_irq(&workqueue_lock);
+   spin_lock_irq(&wq_mayday_lock);
 
while (!list_empty(&wq->maydays)) {
struct pool_workqueue *pwq = list_first_entry(&wq->maydays,
@@ -2415,7 +2415,7 @@ repeat:
__set_current_state(TASK_RUNNING);
list_del_init(&pwq->mayday_node);
 
-   spin_unlock_irq(&workqueue_lock);
+   spin_unlock_irq(&wq_mayday_lock);
 
/* migrate to the target cpu if possible */
worker_maybe_bind_and_lock(pool);
@@ -2442,10 +2442,10 @@ repeat:
 
rescuer->pool = NULL;
spin_unlock(&pool->lock);
-   spin_lock(&workqueue_lock);
+   spin_lock(&wq_mayday_lock);
}
 
-   spin_unlock_irq(&workqueue_lock);
+   spin_unlock_irq(&wq_mayday_lock);
 
/* rescuers should never participate in concurrency management */
WARN_ON_ONCE(!(rescuer->flags & WORKER_NOT_RUNNING));
-- 
1.8.1.4

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

[PATCH 4/7] workqueue: relocate global variable defs and function decls in workqueue.c

[Tejun Heo]

They're split across debugobj code for some reason.  Collect them.

This patch is pure relocation.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index ce1ab06..9a0cbb2 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -248,6 +248,21 @@ struct workqueue_struct {
 
 static struct kmem_cache *pwq_cache;
 
+/* Serializes the accesses to the list of workqueues. */
+static DEFINE_SPINLOCK(workqueue_lock);
+static LIST_HEAD(workqueues);
+static bool workqueue_freezing;/* W: have wqs started 
freezing? */
+
+/* the per-cpu worker pools */
+static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
+cpu_worker_pools);
+
+/*
+ * R: idr of all pools.  Modifications are protected by workqueue_lock.
+ * Read accesses are protected by sched-RCU protected.
+ */
+static DEFINE_IDR(worker_pool_idr);
+
 /* W: hash of all unbound pools keyed by pool->attrs */
 static DEFINE_HASHTABLE(unbound_pool_hash, UNBOUND_POOL_HASH_ORDER);
 
@@ -265,6 +280,10 @@ EXPORT_SYMBOL_GPL(system_unbound_wq);
 struct workqueue_struct *system_freezable_wq __read_mostly;
 EXPORT_SYMBOL_GPL(system_freezable_wq);
 
+static int worker_thread(void *__worker);
+static void copy_workqueue_attrs(struct workqueue_attrs *to,
+const struct workqueue_attrs *from);
+
 #define CREATE_TRACE_POINTS
 #include 
 
@@ -431,25 +450,6 @@ static inline void debug_work_activate(struct work_struct 
*work) { }
 static inline void debug_work_deactivate(struct work_struct *work) { }
 #endif
 
-/* Serializes the accesses to the list of workqueues. */
-static DEFINE_SPINLOCK(workqueue_lock);
-static LIST_HEAD(workqueues);
-static bool workqueue_freezing;/* W: have wqs started 
freezing? */
-
-/* the per-cpu worker pools */
-static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
-cpu_worker_pools);
-
-/*
- * R: idr of all pools.  Modifications are protected by workqueue_lock.
- * Read accesses are protected by sched-RCU protected.
- */
-static DEFINE_IDR(worker_pool_idr);
-
-static int worker_thread(void *__worker);
-static void copy_workqueue_attrs(struct workqueue_attrs *to,
-const struct workqueue_attrs *from);
-
 /* allocate ID and assign it to @pool */
 static int worker_pool_assign_id(struct worker_pool *pool)
 {
-- 
1.8.1.4

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

[PATCH 1/7] workqueue: rename worker_pool->assoc_mutex to ->manager_mutex

[Tejun Heo]

Manager operations are currently governed by two mutexes -
pool->manager_arb and ->assoc_mutex.  The former is used to decide who
gets to be the manager and the latter to exclude the actual manager
operations including creation and destruction of workers.  Anyone who
grabs ->manager_arb must perform manager role; otherwise, the pool
might stall.

Grabbing ->assoc_mutex blocks everyone else from performing manager
operations but doesn't require the holder to perform manager duties as
it's merely blocking manager operations without becoming the manager.

Because the blocking was necessary when [dis]associating per-cpu
workqueues during CPU hotplug events, the latter was named
assoc_mutex.  The mutex is scheduled to be used for other purposes, so
this patch gives it a more fitting generic name - manager_mutex - and
updates / adds comments to explain synchronization around the manager
role and operations.

This patch is pure rename / doc update.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 62 +-
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f37421f..bc25bdf 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -60,8 +60,8 @@ enum {
 * %WORKER_UNBOUND set and concurrency management disabled, and may
 * be executing on any CPU.  The pool behaves as an unbound one.
 *
-* Note that DISASSOCIATED can be flipped only while holding
-* assoc_mutex to avoid changing binding state while
+* Note that DISASSOCIATED should be flipped only while holding
+* manager_mutex to avoid changing binding state while
 * create_worker() is in progress.
 */
POOL_MANAGE_WORKERS = 1 << 0,   /* need to manage workers */
@@ -149,8 +149,9 @@ struct worker_pool {
DECLARE_HASHTABLE(busy_hash, BUSY_WORKER_HASH_ORDER);
/* L: hash of busy workers */
 
+   /* see manage_workers() for details on the two manager mutexes */
struct mutexmanager_arb;/* manager arbitration */
-   struct mutexassoc_mutex;/* protect POOL_DISASSOCIATED */
+   struct mutexmanager_mutex;  /* manager exclusion */
struct ida  worker_ida; /* L: for worker IDs */
 
struct workqueue_attrs  *attrs; /* I: worker attributes */
@@ -1635,7 +1636,7 @@ static void rebind_workers(struct worker_pool *pool)
struct worker *worker, *n;
int i;
 
-   lockdep_assert_held(&pool->assoc_mutex);
+   lockdep_assert_held(&pool->manager_mutex);
lockdep_assert_held(&pool->lock);
 
/* dequeue and kick idle ones */
@@ -2022,31 +2023,44 @@ static bool manage_workers(struct worker *worker)
struct worker_pool *pool = worker->pool;
bool ret = false;
 
+   /*
+* Managership is governed by two mutexes - manager_arb and
+* manager_mutex.  manager_arb handles arbitration of manager role.
+* Anyone who successfully grabs manager_arb wins the arbitration
+* and becomes the manager.  mutex_trylock() on pool->manager_arb
+* failure while holding pool->lock reliably indicates that someone
+* else is managing the pool and the worker which failed trylock
+* can proceed to executing work items.  This means that anyone
+* grabbing manager_arb is responsible for actually performing
+* manager duties.  If manager_arb is grabbed and released without
+* actual management, the pool may stall indefinitely.
+*
+* manager_mutex is used for exclusion of actual management
+* operations.  The holder of manager_mutex can be sure that none
+* of management operations, including creation and destruction of
+* workers, won't take place until the mutex is released.  Because
+* manager_mutex doesn't interfere with manager role arbitration,
+* it is guaranteed that the pool's management, while may be
+* delayed, won't be disturbed by someone else grabbing
+* manager_mutex.
+*/
if (!mutex_trylock(&pool->manager_arb))
return ret;
 
/*
-* To simplify both worker management and CPU hotplug, hold off
-* management while hotplug is in progress.  CPU hotplug path can't
-* grab @pool->manager_arb to achieve this because that can lead to
-* idle worker depletion (all become busy thinking someone else is
-* managing) which in turn can result in deadlock under extreme
-* circumstances.  Use @pool->assoc_mutex to synchronize manager
-* against CPU hotplug.
-*
-* assoc_mutex would always be free unless CPU hotplug is in
-* progress.  trylock first without dropping @pool->lock.
+* With manager arbitration won, manager_mutex would be free in
+

Re: [PATCHSET wq/for-3.10] workqueue: misc cleanups

[Tejun Heo]

On Wed, Mar 13, 2013 at 04:58:12PM -0700, Tejun Heo wrote:
> This patch is on top of wq/for-3.10 e626761691 ("workqueue: implement
> current_is_workqueue_rescuer()").

Oops, forgot the git branch.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-misc-cleanups

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 v7 2/2] mfd: syscon: Add non-DT support

[Dong Aisheng]

On 14 March 2013 01:34, Alexander Shiyan  wrote:
> This patch allow using syscon driver from the platform data, i.e.
> possibility using driver on systems without oftree support.
> For search syscon device from the client drivers,
> "syscon_regmap_lookup_by_pdevname" function was added.
>
> Signed-off-by: Alexander Shiyan 

Actually i've acked this series before, usually you can send out the
updated series
with my tag if no other big changes except the minor comments fix i pointed out.
Here again, for this series:
Acked-by: Dong Aisheng 

Regards
Dong Aisheng

> ---
>  drivers/mfd/Kconfig|  1 -
>  drivers/mfd/syscon.c   | 75 
> +++---
>  include/linux/mfd/syscon.h |  1 +
>  3 files changed, 46 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 671f5b1..8fdd87e 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1070,7 +1070,6 @@ config MFD_STA2X11
>
>  config MFD_SYSCON
> bool "System Controller Register R/W Based on Regmap"
> -   depends on OF
> select REGMAP_MMIO
> help
>   Select this option to enable accessing system control registers
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 674af14..d1e5eb9 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -29,7 +29,7 @@ struct syscon {
> struct regmap *regmap;
>  };
>
> -static int syscon_match(struct device *dev, void *data)
> +static int syscon_match_node(struct device *dev, void *data)
>  {
> struct device_node *dn = data;
>
> @@ -42,7 +42,7 @@ struct regmap *syscon_node_to_regmap(struct device_node *np)
> struct device *dev;
>
> dev = driver_find_device(&syscon_driver.driver, NULL, np,
> -syscon_match);
> +syscon_match_node);
> if (!dev)
> return ERR_PTR(-EPROBE_DEFER);
>
> @@ -68,6 +68,34 @@ struct regmap *syscon_regmap_lookup_by_compatible(const 
> char *s)
>  }
>  EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
>
> +static int syscon_match_pdevname(struct device *dev, void *data)
> +{
> +   struct platform_device *pdev = to_platform_device(dev);
> +   const struct platform_device_id *id = platform_get_device_id(pdev);
> +
> +   if (id)
> +   if (!strcmp(id->name, (const char *)data))
> +   return 1;
> +
> +   return !strcmp(dev_name(dev), (const char *)data);
> +}
> +
> +struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
> +{
> +   struct device *dev;
> +   struct syscon *syscon;
> +
> +   dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> +syscon_match_pdevname);
> +   if (!dev)
> +   return ERR_PTR(-EPROBE_DEFER);
> +
> +   syscon = dev_get_drvdata(dev);
> +
> +   return syscon->regmap;
> +}
> +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
> +
>  struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
> const char *property)
>  {
> @@ -99,28 +127,22 @@ static struct regmap_config syscon_regmap_config = {
>  static int syscon_probe(struct platform_device *pdev)
>  {
> struct device *dev = &pdev->dev;
> -   struct device_node *np = dev->of_node;
> struct syscon *syscon;
> -   struct resource res;
> -   int ret;
> -
> -   if (!np)
> -   return -ENOENT;
> +   struct resource *res;
>
> -   syscon = devm_kzalloc(dev, sizeof(struct syscon),
> -   GFP_KERNEL);
> +   syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
> if (!syscon)
> return -ENOMEM;
>
> -   syscon->base = of_iomap(np, 0);
> -   if (!syscon->base)
> -   return -EADDRNOTAVAIL;
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   if (!res)
> +   return -ENOENT;
>
> -   ret = of_address_to_resource(np, 0, &res);
> -   if (ret)
> -   return ret;
> +   syscon->base = devm_ioremap(dev, res->start, resource_size(res));
> +   if (!syscon->base)
> +   return -ENOMEM;
>
> -   syscon_regmap_config.max_register = res.end - res.start - 3;
> +   syscon_regmap_config.max_register = res->end - res->start - 3;
> syscon->regmap = devm_regmap_init_mmio(dev, syscon->base,
> &syscon_regmap_config);
> if (IS_ERR(syscon->regmap)) {
> @@ -130,22 +152,15 @@ static int syscon_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, syscon);
>
> -   dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
> -   res.start, res.end);
> +   dev_info(dev, "regmap 0x%x-0x%x registered\n", res->start, res->end);
>
> return 0;
>  }
>
> -static int syscon_remove(struct platform_device *pdev)
> -{
> - 

Re: Question about a patch for stable

[Greg Kroah-Hartman]

On Wed, Mar 13, 2013 at 10:09:05PM -0400, Steven Rostedt wrote:
> Hi Greg,
> 
> I was bringing Documentation/trace/ftrace.txt up to date, and obviously
> I found some minor bugs in the code while doing so :-)  One of the
> things I've discovered, is that the new -mfentry option for gcc used for
> function tracing (for only x86 and gcc >= 4.6.0), the stack tracer gives
> some bogus results:
> 
>  # cat stack_trace
> DepthSize   Location(48 entries)
> -   
>   0) 4824 216   ftrace_call+0x5/0x2f
>   1) 4608 112   cache_alloc+0xb7/0x22d
>   2) 4496  80   kmem_cache_alloc+0x63/0x12f
> [...]
> 
> One thing is that it shows the ftrace_call label of the function tracer
> instead of the top function and its stack. This is due to fentry being
> called as the first operation of a function instead of the way mcount is
> called, which is after the stack frame is set up. Because the function
> is traced before the stack frame was set up, we lose what function
> called the current function. Not only that, the stack frame size (216)
> is a combination of that function we missed as well as the ftrace_call
> stack size used to save registers.
> 
> I have a couple of small fixes that make this more correct:
> 
>  # cat stack_trace
> DepthSize   Location(14 entries)
> -   
>   0) 2640  48   update_group_power+0x26/0x187
>   1) 2592 224   update_sd_lb_stats+0x2a5/0x4ac
>   2) 2368 160   find_busiest_group+0x31/0x1f1
>   3) 2208 256   load_balance+0xd9/0x662
> 
> The bug only affects that first entry. Do you think its worth adding to
> stable. The changes are solely contained in kernel/trace/trace_stack.c
> and do not affect anything else.
> 
> I'm not sure I'm going to even submit this for 3.9, and just let it go
> into 3.9.1.
> 
> I also noticed that the contents of the file stack_max_size doesn't
> match the depth (2640 from above), because it also includes the stack
> size of the overhead of the stack tracer itself. I have a fix for that
> too, but I believe this has always been broken (with and without
> -mfentry) and I'm not sure that deserves to be back ported. I'm going to
> queue the fix for 3.10. I'm not sure people care about this one or not.
> 
> What's your thoughts?

I always defer to the maintainer of the subsystem, so it's up to you.

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] wait while adding MMC host to ensure root mounts

[Greg Kroah-Hartman]

On Thu, Mar 14, 2013 at 05:06:23AM +0400, Sergey Yanovich wrote:
> MMC hosts are added asynchronously. We need to wait until detect returns to
> avoid failed root filesystem mounts.
> ---8<---
> VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
> Please append a correct "root=" boot option; here are the available 
> partitions:
> mmc0: host does not support reading read-only switch. assuming write-enable.
> 1f00 256 mtdblock0  (driver?)
> 1f01 256 mtdblock1  (driver?)
> 1f022560 mtdblock2 mmc0: new SDHC card at address b368
>  (driver?)
> 1f03   29696 mtdblock3  (driver?)
> 1f04   16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
>  (driver?)
>  mmcblk0: p1
> b300 3910656 mmcblk0  driver: mmcblk
>   b301 3906560 mmcblk0p1 -01
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> ---8<---
> 
> Signed-off-by: Sergey Yanovich 
> ---
>  drivers/base/dd.c   |1 -
>  drivers/mmc/core/core.c |4 +++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 218f1e6..61d3e1b 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -345,7 +345,6 @@ int driver_probe_done(void)
>  void wait_for_device_probe(void)
>  {
>   /* wait for the known devices to complete their probing */
> -
>   wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
>   async_synchronize_full();
>  }

You didn't need to change this file, please don't.


> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index aaed768..9790323 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -91,10 +91,11 @@ static int mmc_schedule_delayed_work(struct delayed_work 
> *work,
>  /*
>   * Internal function. Flush all scheduled work from the MMC work queue.
>   */
> -static void mmc_flush_scheduled_work(void)
> +void mmc_flush_scheduled_work(void)
>  {
>   flush_workqueue(workqueue);
>  }
> +EXPORT_SYMBOL(mmc_flush_scheduled_work);

EXPORT_SYMBOL_GPL()?

Wait, why are you exporting it at all?

>  #ifdef CONFIG_FAIL_MMC_REQUEST
>  
> @@ -2225,6 +2226,7 @@ void mmc_start_host(struct mmc_host *host)
>   host->rescan_disable = 0;
>   mmc_power_up(host);
>   mmc_detect_change(host, 0);
> + mmc_flush_scheduled_work();

If this is the only fix, then you don't need to change it from being
static or need to export it.

Please be more careful when making kernel patches.

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] epoll: fix sparse error on RCU assignment

[Eric Wong]

Oleg Nesterov  wrote:
> On 03/10, Eric Wong wrote:
> >
> > This fixes the following sparse error when using
> > CONFIG_SPARSE_RCU_POINTER=y and "make C=2 fs/eventpoll.o"
> >
> >   fs/eventpoll.c:514:17: error: incompatible types in comparison expression 
> > (different address spaces)
> 
> ep_remove_wait_queue() does rcu_dereference(pwq->whead) and
> rcu_dereference_sparse(__rcu) complains, I guess.
> 
> > --- a/fs/eventpoll.c
> > +++ b/fs/eventpoll.c
> > @@ -228,7 +228,7 @@ struct eppoll_entry {
> > wait_queue_t wait;
> >
> > /* The wait queue head that linked the "wait" wait queue item */
> > -   wait_queue_head_t *whead;
> > +   wait_queue_head_t __rcu *whead;
> 
> Well, perhaps this change is fine... but otoh this this a bit misleading.
> It is not actually __rcu. The special case is sighand->signalfd_wqh, and
> the commemt in ep_remove_wait_queue() means: if ->whead is not stable then
> we can only race with signalfd_cleanup(), and rcu_read_lock() ensures this
> memory can't go away.
> 
> We do not even need smp_read_barrier_depends() here, ACCESS_ONCE() should
> be enough.
> 
> Perhaps it would be better to simply shut up this warning somehow...

Hi, I've been hoping others would give a reply and offer a better
solution than min.

Without my proposed patch, sparse _errors_ out on me, so it prevent sparse
from reporting the many other warnings I create in my patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 cgroup tree with Linus' tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in
include/linux/res_counter.h between commit ebf47beb660e
("include/linux/res_counter.h needs errno.h") from Linus' tree and commit
9259826ccb81 ("res_counter: remove include of cgroup.h from
res_counter.h") from the cgroup 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 include/linux/res_counter.h
index c230994,a83a849..000
--- a/include/linux/res_counter.h
+++ b/include/linux/res_counter.h
@@@ -13,8 -13,7 +13,8 @@@
   * info about what this counter is.
   */
  
- #include 
 +#include 
+ #include 
  
  /*
   * The core object. the cgroup that wishes to account for some


pgpc2NyeeKts6.pgp
Description: PGP signature

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

[Bill Huang]

On Thu, 2013-03-14 at 02:10 +0800, Stephen Warren wrote:
> On 03/12/2013 11:40 PM, Bill Huang wrote:
> > 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
> ...
> >>> 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?
> 
> I don't know the correct answer.
> 
> But I have a question: Why can't we run notifications from the real
> clk_enable? Does the notification mechanism itself inherently block, or
> are we worried that implementations/receivers of these notifications
> might block. Perhaps we can simply define that these notification types
I think both.
> may be triggered in atomic context and hence implementations have to
> support executing in atomic context. Is possible to make that a
> requirement? Is it possible to implement the code that receives these
> notifications in atomic context?
Making it executing in atomic context won't work since for DVFS we
generally having to set voltage (while receiving the notify) through I2C
interface which can sleep.
> 
> Is it possible to defer triggering of notifications to some non-atomic
> context, even if they happen in an atomic context?
I don't think deferring will work either, considering the usage of DVFS,
device voltage is tightly coupled with frequency, when clock rate is
about to increase, we have to boost voltage first and we can lower the
voltage after the clock rate has decreased. All the above sequence have
to be guaranteed or you might crash, so deferring not only make thing
complicated in controlling the order but also hurt performance.
> 
> I also wonder if this is the right conceptual level to be hooking into
> the system. Perhaps DVFS is not something that should be triggered by
> noticing that clocks have changed rates, but rather it should be some
> form of higher layer that controls (calls into) both the regulator and
> clock APIs?
I wonder will there be a feasible API can do that since most of SoC is
characterizing DVFS on frequency vs. voltage, it makes sense that
reviewing voltage when the clock rate change happen, and the only
mechanism seem to be hooking notifier in not only clock rate change but
also clock enable/disable. 


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

Question about a patch for stable

[Steven Rostedt]

Hi Greg,

I was bringing Documentation/trace/ftrace.txt up to date, and obviously
I found some minor bugs in the code while doing so :-)  One of the
things I've discovered, is that the new -mfentry option for gcc used for
function tracing (for only x86 and gcc >= 4.6.0), the stack tracer gives
some bogus results:

 # cat stack_trace
DepthSize   Location(48 entries)
-   
  0) 4824 216   ftrace_call+0x5/0x2f
  1) 4608 112   cache_alloc+0xb7/0x22d
  2) 4496  80   kmem_cache_alloc+0x63/0x12f
[...]

One thing is that it shows the ftrace_call label of the function tracer
instead of the top function and its stack. This is due to fentry being
called as the first operation of a function instead of the way mcount is
called, which is after the stack frame is set up. Because the function
is traced before the stack frame was set up, we lose what function
called the current function. Not only that, the stack frame size (216)
is a combination of that function we missed as well as the ftrace_call
stack size used to save registers.

I have a couple of small fixes that make this more correct:

 # cat stack_trace
DepthSize   Location(14 entries)
-   
  0) 2640  48   update_group_power+0x26/0x187
  1) 2592 224   update_sd_lb_stats+0x2a5/0x4ac
  2) 2368 160   find_busiest_group+0x31/0x1f1
  3) 2208 256   load_balance+0xd9/0x662

The bug only affects that first entry. Do you think its worth adding to
stable. The changes are solely contained in kernel/trace/trace_stack.c
and do not affect anything else.

I'm not sure I'm going to even submit this for 3.9, and just let it go
into 3.9.1.

I also noticed that the contents of the file stack_max_size doesn't
match the depth (2640 from above), because it also includes the stack
size of the overhead of the stack tracer itself. I have a fix for that
too, but I believe this has always been broken (with and without
-mfentry) and I'm not sure that deserves to be back ported. I'm going to
queue the fix for 3.10. I'm not sure people care about this one or not.

What's your thoughts?

Thanks,

-- Steve




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 031/100] iwlwifi: always copy first 16 bytes of commands

[Ben Hutchings]

On Thu, 2013-03-14 at 01:50 +, Ben Hutchings wrote:
> On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Hartman wrote:
> > 3.8-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Johannes Berg 
> > 
> > commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream.
> [...]
> > --- a/drivers/net/wireless/iwlwifi/pcie/tx.c
> > +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
> [...]
> > @@ -1221,14 +1238,31 @@ static int iwl_pcie_enqueue_hcmd(struct
> >  
> > /* and copy the data that needs to be copied */
> > cmd_pos = offsetof(struct iwl_device_cmd, payload);
> > +   copy_size = sizeof(out_cmd->hdr);
> > for (i = 0; i < IWL_MAX_CMD_TFDS; i++) {
> > -   if (!cmd->len[i])
> > +   int copy = 0;
> > +
> > +   if (!cmd->len)
> > continue;
> 
> cmd->len is an array, so the new condition is always false.  Shouldn't
> it be 'if (!cmdlen[i])'?

To answer myself: no, it should still be 'if (!cmd->len[i])' as this
loop needs to include input fragments that will be completely copied
into the header fragment.

Ben.

> Ben.
> 
> > -   if (cmd->dataflags[i] & (IWL_HCMD_DFL_NOCOPY |
> > -IWL_HCMD_DFL_DUP))
> > -   break;
> > -   memcpy((u8 *)out_cmd + cmd_pos, cmd->data[i], cmd->len[i]);
> > -   cmd_pos += cmd->len[i];
> > +
> > +   /* need at least IWL_HCMD_MIN_COPY_SIZE copied */
> > +   if (copy_size < IWL_HCMD_MIN_COPY_SIZE) {
> > +   copy = IWL_HCMD_MIN_COPY_SIZE - copy_size;
> > +
> > +   if (copy > cmd->len[i])
> > +   copy = cmd->len[i];
> > +   }
> > +
> > +   /* copy everything if not nocopy/dup */
> > +   if (!(cmd->dataflags[i] & (IWL_HCMD_DFL_NOCOPY |
> > +  IWL_HCMD_DFL_DUP)))
> > +   copy = cmd->len[i];
> > +
> > +   if (copy) {
> > +   memcpy((u8 *)out_cmd + cmd_pos, cmd->data[i], copy);
> > +   cmd_pos += copy;
> > +   copy_size += copy;
> > +   }
> > }
> >  
> > WARN_ON_ONCE(txq->entries[idx].copy_cmd);
> [...]
> 

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: [PATCH 11/12] rwsem: wake all readers when first waiter is a reader

[Peter Hurley]

On Wed, 2013-03-13 at 14:23 +1100, Dave Chinner wrote:
> 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

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

[Marcelo Tosatti]

On Wed, Mar 13, 2013 at 10:07:06PM -0300, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> > 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 = &kvm->arch.mmu_cache;
> > +   struct kvm_mmu_page *sp, *node;
> > +   struct pte_list_desc *desc, *ndesc;
> > +   int root_sp = 0;
> > 
> > spin_lock(&kvm->mmu_lock);
> > +
> >  restart:
> > -   list_for_each_entry_safe(sp, node,
> > - &kvm->arch.mmu_cache.active_mmu_pages, link)
> > -   if (kvm_mmu_prepare_zap_page(kvm, sp, &invalid_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, &cache->active_mmu_pages, link)
> > +   if (sp->root_count) {
> > +   int ret;
> > +
> > +   root_sp++;
> > +   ret = kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list);
> > +   list_move(&sp->link, &root_mmu_pages);
> > +   if (ret)
> > +   goto restart;
> > +   }
> 
> Why is it safe to skip flushing of root pages, for all
> kvm_flush_shadow() callers?

You are not skipping the flush, only moving to the new mmu cache.

> Should revisit KVM_REQ_MMU_RELOAD... not clear it is necessary for NPT
> (unrelated).

Actually, what i meant is: you can batch KVM_REQ_MMU_RELOAD requests to
the end of kvm_mmu_zap_all. Waking up vcpus is not optimal since they're
going to contend for mmu_lock anyway.

Need more time to have more useful comments to this patchset, sorry.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] KVM: MMU: fast zap all shadow pages

[Marcelo Tosatti]

On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> 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 = &kvm->arch.mmu_cache;
> + struct kvm_mmu_page *sp, *node;
> + struct pte_list_desc *desc, *ndesc;
> + int root_sp = 0;
> 
>   spin_lock(&kvm->mmu_lock);
> +
>  restart:
> - list_for_each_entry_safe(sp, node,
> -   &kvm->arch.mmu_cache.active_mmu_pages, link)
> - if (kvm_mmu_prepare_zap_page(kvm, sp, &invalid_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, &cache->active_mmu_pages, link)
> + if (sp->root_count) {
> + int ret;
> +
> + root_sp++;
> + ret = kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list);
> + list_move(&sp->link, &root_mmu_pages);
> + if (ret)
> + goto restart;
> + }

Why is it safe to skip flushing of root pages, for all
kvm_flush_shadow() callers?

Should revisit KVM_REQ_MMU_RELOAD... not clear it is necessary for NPT
(unrelated).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ata: Fix DVD not dectected at some Haswell platforms

[Youquan Song]

Hi Maintainer,

Can you look at the patch which required by some Haswell platforms?

Thanks
-Youquan

On Wed, Mar 06, 2013 at 10:49:05AM -0500, Youquan Song wrote:
> There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d 
> "ata_piix: make DVD Drive recognisable on systems with Intel Sandybridge
>  chipsets(v2)" fixing the 4 ports IDE controller 32bit PIO mode. 
> 
> We've hit a problem with DVD not recognized on Haswell Desktop platform which
> includes Lynx Point 2-port SATA controller.
> 
> This quirk patch disables 32bit PIO on this controller in IDE mode.
> 
> v2: Change spelling error in statememnt pointed by Sergei Shtylyov.
> v3: Change comment statememnt and spliting line over 80 characters pointed by
> Libor Pechacek and also rebase the patch against 3.8-rc7 kernel.
> 
> Tested-by: Lee, Chun-Yi 
> Signed-off-by: Youquan Song 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/ata/ata_piix.c |   14 +-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
> index 174eca6..4aab550 100644
> --- a/drivers/ata/ata_piix.c
> +++ b/drivers/ata/ata_piix.c
> @@ -150,6 +150,7 @@ enum piix_controller_ids {
>   tolapai_sata,
>   piix_pata_vmw,  /* PIIX4 for VMware, spurious DMA_ERR */
>   ich8_sata_snb,
> + ich8_2port_sata_snb,
>  };
>  
>  struct piix_map_db {
> @@ -304,7 +305,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
>   /* SATA Controller IDE (Lynx Point) */
>   { 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
>   /* SATA Controller IDE (Lynx Point) */
> - { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
> + { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
>   /* SATA Controller IDE (Lynx Point) */
>   { 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
>   /* SATA Controller IDE (Lynx Point-LP) */
> @@ -422,6 +423,7 @@ static const struct piix_map_db *piix_map_db_table[] = {
>   [ich8m_apple_sata]  = &ich8m_apple_map_db,
>   [tolapai_sata]  = &tolapai_map_db,
>   [ich8_sata_snb] = &ich8_map_db,
> + [ich8_2port_sata_snb]   = &ich8_2port_map_db,
>  };
>  
>  static struct pci_bits piix_enable_bits[] = {
> @@ -1225,6 +1227,16 @@ static struct ata_port_info piix_port_info[] = {
>   .udma_mask  = ATA_UDMA6,
>   .port_ops   = &piix_sata_ops,
>   },
> +
> + [ich8_2port_sata_snb] =
> + {
> + .flags  = PIIX_SATA_FLAGS | PIIX_FLAG_SIDPR
> + | PIIX_FLAG_PIO16,
> + .pio_mask   = ATA_PIO4,
> + .mwdma_mask = ATA_MWDMA2,
> + .udma_mask  = ATA_UDMA6,
> + .port_ops   = &piix_sata_ops,
> + },
>  };
>  
>  #define AHCI_PCI_BAR 5
> -- 
> 1.7.7.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: [ 031/100] iwlwifi: always copy first 16 bytes of commands

[Ben Hutchings]

On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Hartman wrote:
> 3.8-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Johannes Berg 
> 
> commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream.
[...]
> --- a/drivers/net/wireless/iwlwifi/pcie/tx.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
[...]
> @@ -1221,14 +1238,31 @@ static int iwl_pcie_enqueue_hcmd(struct
>  
>   /* and copy the data that needs to be copied */
>   cmd_pos = offsetof(struct iwl_device_cmd, payload);
> + copy_size = sizeof(out_cmd->hdr);
>   for (i = 0; i < IWL_MAX_CMD_TFDS; i++) {
> - if (!cmd->len[i])
> + int copy = 0;
> +
> + if (!cmd->len)
>   continue;

cmd->len is an array, so the new condition is always false.  Shouldn't
it be 'if (!cmdlen[i])'?

Ben.

> - if (cmd->dataflags[i] & (IWL_HCMD_DFL_NOCOPY |
> -  IWL_HCMD_DFL_DUP))
> - break;
> - memcpy((u8 *)out_cmd + cmd_pos, cmd->data[i], cmd->len[i]);
> - cmd_pos += cmd->len[i];
> +
> + /* need at least IWL_HCMD_MIN_COPY_SIZE copied */
> + if (copy_size < IWL_HCMD_MIN_COPY_SIZE) {
> + copy = IWL_HCMD_MIN_COPY_SIZE - copy_size;
> +
> + if (copy > cmd->len[i])
> + copy = cmd->len[i];
> + }
> +
> + /* copy everything if not nocopy/dup */
> + if (!(cmd->dataflags[i] & (IWL_HCMD_DFL_NOCOPY |
> +IWL_HCMD_DFL_DUP)))
> + copy = cmd->len[i];
> +
> + if (copy) {
> + memcpy((u8 *)out_cmd + cmd_pos, cmd->data[i], copy);
> + cmd_pos += copy;
> + copy_size += copy;
> + }
>   }
>  
>   WARN_ON_ONCE(txq->entries[idx].copy_cmd);
[...]

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: CLONE_NEWUSER|CLONE_FS root exploit

[Andy Lutomirski]

On 03/13/2013 11:35 AM, Eric W. Biederman wrote:
> Kees Cook  writes:
> 
>> Hi,
>>
>> It seem like we should block (at least) this combination. On 3.9, this
>> exploit works once uidmapping is added.
>>
>> http://www.openwall.com/lists/oss-security/2013/03/13/10
> 
> Yes.  That is a bad combination.  It let's chroot confuse privileged
> processes.
> 
> Now to figure out if this is easier to squash by adding a user_namespace
> to fs_struct or by just forbidding this combination.

It's worth making sure that setns(2) doesn't have similar issues.

Looking through other shared-but-not-a-namespace things, there are:

fs_struct: Buggy as noted.

files_struct: Probably harmless -- SCM_RIGHTS can emulate it

signal_struct: This interacts with the tty code.  Is it okay?

sighand_struct: Looks safe.  Famous last words.

FWIW, I've been alarmed in the past that struct path (e.g. the root
directory) implies an mnt_namespace (hidden in struct mount), and it's
entirely possible for the root directory's mnt_namespace not to match
nsproxy->mnt_namespace.  I'm not sure what the implications are, but
this doesn't seem healthy.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Kernel oops on mmap ?

[Hillf Danton]

[cc Russell]
On Wed, Mar 13, 2013 at 11:04 PM, Mark Jackson  wrote:
> Can any help diagnose what my userspace task is doing to get the followings 
> oops ?
>
> [   42.587772] Unable to handle kernel paging request at virtual address 
> bfac6004
> [   42.595431] pgd = cf748000
> [   42.598291] [bfac6004] *pgd=

None pgd, why is pgd_none_or_clear_bad() not triggered?

> [   42.602079] Internal error: Oops: 5 [#1] ARM
> [   42.606592] CPU: 0Not tainted  
> (3.8.0-next-20130225-1-g2d0ce24-dirty #38)
> [   42.614509] PC is at unmap_single_vma+0x2d8/0x5bc
> [   42.619476] LR is at unmap_single_vma+0x29c/0x5bc
> [   42.624447] pc : []lr : []psr: 6013
> [   42.624447] sp : cf685d88  ip : 8f9523cd  fp : cf680004
> [   42.636567] r10:   r9 : bfac6000  r8 : 0020
> [   42.642079] r7 : cf685e00  r6 : cf5e93a8  r5 : cf5e93ac  r4 : 000ea000
> [   42.648969] r3 : 0001  r2 :   r1 : 0040  r0 : 
> [   42.655864] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [   42.663400] Control: 10c5387d  Table: 8f748019  DAC: 0015
> [   42.669467] Process rdserver (pid: 673, stack limit = 0xcf684238)
> [   42.675902] Stack: (0xcf685d88 to 0xcf686000)
> [   42.680507] 5d80:   cf2ff06c cf5a28b8 cf2ff040  
> 8f9523cd cf68
> [   42.689145] 5da0: 0021d000 0021cfff c0c8ea80  ff35  
> f451edbe cf5a28b8
> [   42.697786] 5dc0:  cf685e00   cf6716e8 cf2ff040 
> cf5956c0 c00af730
> [   42.706421] 5de0:  cf5a58c0 cf5a2548 cf2ff040 cf685e00 cf301c80 
> cf5a58c0 c00b5884
> [   42.715061] 5e00: cf2ff040 0001  0080  00d2 
> 0400 cf796000
> [   42.723698] 5e20: cf301c80 cf5a58c0 cf6716e8 cf2ff040 cf5956c0 c0402400 
> 6013 cf2ff090
> [   42.732338] 5e40: cf2ff060 cf2ff040  cf684000 cf301c80 c00364d4 
> cf2ff040 cf671340
> [   42.740975] 5e60: cf684000 c00ccb90 cf60ae40 cf301c80 cf60aea4 cf685e88 
> cf60ae74 cf684000
> [   42.749616] 5e80: 0001 c010a29c cf301c80 0080  cf301d80 
> 000d 
> [   42.758252] 5ea0: cf684000 cf55cd80 0001 c057dd34 cf684000 c0109774 
> 02a1 c0075390
> [   42.766892] 5ec0: 0002   c00cd260   
> cf671340 c057dd18
> [   42.775529] 5ee0: 0002  c057dd18 cf301c80 fff8  
> c057e674 c057dd34
> [   42.784164] 5f00: cf684000 c010a05c 02a1 c00cd24c 0001  
> c00cd19c befff000
> [   42.792800] 5f20: cf684000 0001 0001 cf684000 0001 cf6c4128 
> 0001 cf301c80
> [   42.801439] 5f40: becefdbc becef378  c00cd790 0001  
> c00cd40c 0ff0
> [   42.810074] 5f60: cf5a590c cf5a58c0 cf671560   cf343000 
> becefdbc becef378
> [   42.818710] 5f80: 000b c0013968 cf684000  becef3a0 c00cda98 
> becef3b4 
> [   42.827346] 5fa0: becefbec c00137c0 becef3b4  0021c8f0 becef378 
> becefdbc b6ead190
> [   42.835981] 5fc0: becef3b4  becefbec 000b  0001f300 
>  becef3a0
> [   42.844616] 5fe0: becef384 becef370 b6e97c7c b6e6ae88 6010 0021c8f0 
>  
> [   42.853266] [] (unmap_single_vma+0x2d8/0x5bc) from [] 
> (unmap_vmas+0x54/0x68)
> [   42.862552] [] (unmap_vmas+0x54/0x68) from [] 
> (exit_mmap+0xd0/0x1f4)
> [   42.871106] [] (exit_mmap+0xd0/0x1f4) from [] 
> (mmput+0x34/0xb8)
> [   42.879202] [] (mmput+0x34/0xb8) from [] 
> (flush_old_exec+0x240/0x4c8)
> [   42.887849] [] (flush_old_exec+0x240/0x4c8) from [] 
> (load_elf_binary+0x240/0x1204)
> [   42.897687] [] (load_elf_binary+0x240/0x1204) from [] 
> (search_binary_handler+0xe4/0x1f4)
> [   42.908075] [] (search_binary_handler+0xe4/0x1f4) from 
> [] (do_execve+0x434/0x4ec)
> [   42.917816] [] (do_execve+0x434/0x4ec) from [] 
> (sys_execve+0x30/0x44)
> [   42.926465] [] (sys_execve+0x30/0x44) from [] 
> (ret_fast_syscall+0x0/0x3c)
> [   42.935472] Code: 0aa4 e59d000c e350 1aa2 (e5993004)
> [   42.941912] ---[ end trace 8e32e7f68f5ea19a ]---
>
> Cheers
> Mark J.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] scripts/package/Makefile: compare objtree with srctree instead of test KBUILD_OUTPUT

[Bin Wang]

Hi, Michal

Is there any comments on this?

2013/2/25 Bin Wang :
> KBUILD_OUTPUT is always empty here, so it is useless to test it. But
> while use O=.., objtree and srctree will be different. I compare them
> instead.
>
> Signed-off-by: Bin Wang 
> ---
>  scripts/package/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/package/Makefile b/scripts/package/Makefile
> index 87bf080..d7b3285 100644
> --- a/scripts/package/Makefile
> +++ b/scripts/package/Makefile
> @@ -36,7 +36,7 @@ $(objtree)/kernel.spec: $(MKSPEC) $(srctree)/Makefile
> $(CONFIG_SHELL) $(MKSPEC) > $@
>
>  rpm-pkg rpm: $(objtree)/kernel.spec FORCE
> -   @if test -n "$(KBUILD_OUTPUT)"; then \
> +   @if test "$(objtree)" != "$(srctree)"; then \
> echo "Building source + binary RPM is not possible outside 
> the"; \
> echo "kernel source tree. Don't set KBUILD_OUTPUT, or use 
> the"; \
> echo "binrpm-pkg target instead."; \
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.
---8<---
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not support reading read-only switch. assuming write-enable.
1f00 256 mtdblock0  (driver?)
1f01 256 mtdblock1  (driver?)
1f022560 mtdblock2 mmc0: new SDHC card at address b368
 (driver?)
1f03   29696 mtdblock3  (driver?)
1f04   16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
 (driver?)
 mmcblk0: p1
b300 3910656 mmcblk0  driver: mmcblk
  b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8<---

Signed-off-by: Sergey Yanovich 
---
changes for v2:
- removed exporting as symbol is in the same file

 drivers/mmc/core/core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aaed768..7196888 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2225,6 +2225,7 @@ void mmc_start_host(struct mmc_host *host)
host->rescan_disable = 0;
mmc_power_up(host);
mmc_detect_change(host, 0);
+   mmc_flush_scheduled_work();
 }
 
 void mmc_stop_host(struct mmc_host *host)
-- 
1.7.10.4

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

Re: [ 029/100] NFSv4.1: Hold reference to layout hdr in layoutget

[Ben Hutchings]

On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Hartman wrote:
> 3.8-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Weston Andros Adamson 
> 
> commit a47970ff7814718fec31b7d966747c6aa1a3545f upstream.
[]
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -6087,11 +6087,13 @@ static struct page **nfs4_alloc_pages(si
>  static void nfs4_layoutget_release(void *calldata)
>  {
>   struct nfs4_layoutget *lgp = calldata;
> - struct nfs_server *server = NFS_SERVER(lgp->args.inode);
> + struct inode *inode = lgp->args.inode;
> + struct nfs_server *server = NFS_SERVER(inode);
>   size_t max_pages = max_response_pages(server);
>  
>   dprintk("--> %s\n", __func__);
>   nfs4_free_pages(lgp->args.layout.pages, max_pages);
> + pnfs_put_layout_hdr(NFS_I(inode)->layout);
>   put_nfs_open_context(lgp->args.ctx);
>   kfree(calldata);
>   dprintk("<-- %s\n", __func__);
> @@ -6106,7 +6108,8 @@ static const struct rpc_call_ops nfs4_la
>  struct pnfs_layout_segment *
>  nfs4_proc_layoutget(struct nfs4_layoutget *lgp, gfp_t gfp_flags)
>  {
> - struct nfs_server *server = NFS_SERVER(lgp->args.inode);
> + struct inode *inode = lgp->args.inode;
> + struct nfs_server *server = NFS_SERVER(inode);
>   size_t max_pages = max_response_pages(server);
>   struct rpc_task *task;
>   struct rpc_message msg = {
> @@ -6136,6 +6139,10 @@ nfs4_proc_layoutget(struct nfs4_layoutge
>   lgp->res.layoutp = &lgp->args.layout;
>   lgp->res.seq_res.sr_slot = NULL;
>   nfs41_init_sequence(&lgp->args.seq_args, &lgp->res.seq_res, 0);
> +
> + /* nfs4_layoutget_release calls pnfs_put_layout_hdr */
> + pnfs_get_layout_hdr(NFS_I(inode)->layout);
> +

But this function also calls nfs4_layoutget_release() if
nfs4_alloc_pages() fails, i.e. before it calls pnfs_get_layout_hdr().
This will lead to a reference imbalance.

Ben.

>   task = rpc_run_task(&task_setup_data);
>   if (IS_ERR(task))
>   return ERR_CAST(task);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: [PATCH] pinctrl: remove pxa pinctrl driver

[Haojian Zhuang]

On 14 March 2013 03:03, Linus Walleij  wrote:
> On Wed, Mar 13, 2013 at 9:23 AM, Haojian Zhuang
>  wrote:
>
>> pinctrl-pxa driver doesn't support well on DT mode. Now pinctrl-single
>> could support DT mode & pin configuration. Use pinctrl-single driver to
>> support MMP/PXA silicons instead.
>>
>> Signed-off-by: Haojian Zhuang 
>
> Is the switch to pinctrl-single already done for these platforms,
> i.e. the device trees are updated to contain pinctrl-single data?
>
> And is ATAG code path removed, so noone needs the old driver?
>
> And is the defconfig or Kconfig for PXA/MMP altered to select
> the single driver instead?
>
> Else I cannot merge it...
>
> Yours,
> Linus Walleij

pinctrl-pxa driver is used for PXA/MMP silicons. But the old MFP driver
also exists and be using. PXA/MMP didn't really switch to pinctrl-pxa
driver. So it doesn't matter to remove pinctrl-pxa.

In the Kconfig, PXA/MMP already selected to pinctrl-single driver instead.

Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 00/44] ldisc patchset

[Peter Hurley]

On Wed, 2013-03-13 at 04:36 -0700, Michel Lespinasse wrote:
> Have you considered building your ldlock based on lib/rwsem-spinlock.c
> instead ? i.e. having an internal spinlock to protect the ldisc
> reference count and the reader and writer queues. This would seem much
> simpler get right. The downside would be that a spinlock would be
> taken for a short time whenever an ldisc reference is taken or
> released. I don't expect that the internal spinlock would get
> significant contention ?

That would have been too easy :)

TBH, I hadn't considered it until I was most the way through a working
atomic version. I had already split the reader/writer wait lists. And
figured out how to always use the wait bias for every waiting reader and
writer -- rather than the rwsem way of testing for an empty list --
which made the timeout handling easier.

At the time, the only thing that I was still struggling with was
recursion, and the spinlock flavor wasn't going to fix that. So I just
kept with the atomic flavor.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.
---8<---
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not support reading read-only switch. assuming write-enable.
1f00 256 mtdblock0  (driver?)
1f01 256 mtdblock1  (driver?)
1f022560 mtdblock2 mmc0: new SDHC card at address b368
 (driver?)
1f03   29696 mtdblock3  (driver?)
1f04   16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
 (driver?)
 mmcblk0: p1
b300 3910656 mmcblk0  driver: mmcblk
  b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8<---

Signed-off-by: Sergey Yanovich 
---
 drivers/base/dd.c   |1 -
 drivers/mmc/core/core.c |4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 218f1e6..61d3e1b 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -345,7 +345,6 @@ int driver_probe_done(void)
 void wait_for_device_probe(void)
 {
/* wait for the known devices to complete their probing */
-
wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
async_synchronize_full();
 }
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aaed768..9790323 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -91,10 +91,11 @@ static int mmc_schedule_delayed_work(struct delayed_work 
*work,
 /*
  * Internal function. Flush all scheduled work from the MMC work queue.
  */
-static void mmc_flush_scheduled_work(void)
+void mmc_flush_scheduled_work(void)
 {
flush_workqueue(workqueue);
 }
+EXPORT_SYMBOL(mmc_flush_scheduled_work);
 
 #ifdef CONFIG_FAIL_MMC_REQUEST
 
@@ -2225,6 +2226,7 @@ void mmc_start_host(struct mmc_host *host)
host->rescan_disable = 0;
mmc_power_up(host);
mmc_detect_change(host, 0);
+   mmc_flush_scheduled_work();
 }
 
 void mmc_stop_host(struct mmc_host *host)
-- 
1.7.10.4

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

Re: OOPS with 3.9.0rc2+

[Hillf Danton]

On Wed, Mar 13, 2013 at 11:44 PM, Borislav Petkov  wrote:
> + dri-devel.
>
> On Wed, Mar 13, 2013 at 02:34:31PM +0100, Rolf Offermanns wrote:
>> Hi,
>>
>> I get a kernel oops / panic with a 3.9.0rc2+ kernel (git from 2h ago) on my 
>> Sony
>> Vaio laptop. It happened with rc1, too.
>>
>> Unfortunately I only have a screen photo as nothing gets written to the 
>> system
>> log.
>>
>> Here is a transcript:
>> -[cut here]
>> WARNING: at linux-2.6/drivers/gpu/drm/drm.crtc.c:84 
>> drm_warn_on_modeset_not_all_locked+0x80/0x90 [drm]()
>> Hardware name: VPCF23A9E
>> Modules linked in: [...]
>> Pid: 1894, comm: plasma-desktop Tainted: G   D W  3.9.0-rc2+ #1
>> Call Trace:
>> warn_slowpath_common+0x7f/0xc0
>>  warn_slowpath_null+0x1a/020
>>  drm_warn_on_modeset_not_all_locked+0x80/0x90 [drm]
>>  drm_fb_helper_restore_fbdev_mode+0x1c/0x80 [drm_kms_helper]
>>  drm_fb_helper_force_kernel_mode+0x4d/0xa0 [drm_kms_helper]
>>  drm_fb_helper_panic+0x2b/0x30 [drm_kms_helper]
>>  notifier_call_chain+0x4d/0x70
>>  __atomic_notifier_call_chain+0x12/0x20
>>  atomic_notifier_call_chain+0x16/0x20
>>  panic+0xef/0x1d0
>>  oops_end+0xe2/0xf0
>>  die+0x58/0x90
>>  do_trap+0x6b/0170
>>  ? __atomic_notifier_call_chain+0x12/0x20
>>  do_divide_error+0x96/0xa0
>>  ? intel_pstate_timer_func+0x15d/0x380
>>  ? check_preempt_curr+0x75/0xa0
>>  ? ttwu_do_wakeup+0x2c/0xf0
>>  divide_error+0x1e/0x30

Hmm, registered timer results in divide err,
what is it?

>>  ? intel_pstate_timer_func+0x15d/0x380
>>  ? intel_pstate_timer_func+0xbc/0x380
>>  ? pid_param_set+0x120/0x120
>>  call_timer_fn+0x3a/0x120
>>  ? pid_param_set+0x120/0x120
>>  run_timer_softirq+0x1fe/0x2b0
>>  __do_softirq+0xe0/0x230
>>  irq_exit+0xa5/0xb0
>>  smp_apic_timer_interrupt+0x6e/0x99
>>  apic_timer_interrupt+0x6d/0x80
>>   ? sysret_audit+0x17/0x21
>>  -[ end trace  ]--
>>  NOHZ: local_softirq_pending 282
>>
>>
>>  Is this of any use at all? How can I help track this down? Shall I attach a
>>  serial console (USB only)?
>>
>> lspci:
>>
>> 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family 
>> DRAM Controller (rev 09)
>> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core 
>> Processor Family PCI Express Root Port (rev 09)
>> 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series 
>> Chipset Family MEI Controller #1 (rev 04)
>> 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset 
>> Family USB Enhanced Host Controller #2 (rev 04)
>> 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family 
>> High Definition Audio Controller (rev 04)
>> 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family 
>> PCI Express Root Port 1 (rev b4)
>> 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family 
>> PCI Express Root Port 2 (rev b4)
>> 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family 
>> PCI Express Root Port 3 (rev b4)
>> 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family 
>> PCI Express Root Port 4 (rev b4)
>> 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset 
>> Family USB Enhanced Host Controller #1 (rev 04)
>> 00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC 
>> Controller (rev 04)
>> 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset 
>> Family 6 port SATA AHCI Controller (rev 04)
>> 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus 
>> Controller (rev 04)
>> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 
>> 540M] (rev a1)
>> 01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio 
>> Controller (rev a1)
>> 02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless 
>> Network Adapter (rev 01)
>> 03:00.0 SD Host controller: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 
>> 09) 03:00.1 System peripheral: Ricoh Co Ltd Device e232 (rev 06)
>> 03:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller 
>> (rev 05)
>> 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller 
>> (rev 04)
>> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 
>> PCI Express Gigabit Ethernet controller (rev 06)
>>
>>
>> cpuinfo:
>> processor   : 0-7
>> vendor_id   : GenuineIntel
>> cpu family  : 6
>> model   : 42
>> model name  : Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz
>> stepping: 7
>> microcode   : 0x28
>> cpu MHz : 800.000
>> cache size  : 6144 KB
>> physical id : 0
>> siblings: 8
>> core id : 0
>> cpu cores   : 4
>> apicid  : 0
>> initial apicid  : 0
>> fpu : yes
>> fpu_exception   : yes
>> cpuid level : 13
>> wp  : yes
>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
>> cmov
>> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx r

Re: linux-next: Tree for Mar 7

[Jörn Engel]

On Thu, 14 March 2013 11:20:40 +1100, Stephen Rothwell wrote:
> 
> Added from today.

Excellent, thanks!

> One thing, the last few commits from Takashi do not have your
> Signed-off-by even though you committed them.

I think this is not bad enough to destroy history for, but I should
really figure out what I messed up and how to avoid it in the future.
Thanks for noticing.

Jörn

--
No art, however minor, demands less than total dedication if you want
to excel in it.
-- Leon Battista Alberti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] 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.

We also only need to reset the line after the phy node has been found.
This way we don't accidently reserve the vbus GPIO pin, but later on
defer the creation of our controller, because the phy device tree node
hasn't been probed yet.

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 
CC: Doug Anderson 

---

v1 -> v2:

  - remove gpio_free call
  - move reset logic after phy node search

diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..b29b2b8 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -103,9 +103,14 @@ 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(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
+   return;
+   }
+   mdelay(1);
+   __gpio_set_value(gpio, 1);
 }
 
 static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
@@ -131,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
 
-   s5p_setup_vbus_gpio(pdev);
-
s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
@@ -152,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
s5p_ehci->otg = phy->otg;
}
 
+   s5p_setup_vbus_gpio(pdev);
+
s5p_ehci->dev = &pdev->dev;
 
hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] ARM: tegra: expose chip ID and revision

[Danny Huang]

Expose Tegra chip ID and revision in /sys/devices/soc for user mode
usage

Signed-off-by: Danny Huang 
---
 arch/arm/Kconfig|  1 +
 arch/arm/mach-tegra/tegra.c | 29 -
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2363926..12fa4e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -675,6 +675,7 @@ config ARCH_TEGRA
select HAVE_CLK
select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
+   select SOC_BUS
select SPARSE_IRQ
select USE_OF
help
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 27232c9..84deeab 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -42,6 +44,7 @@
 
 #include "board.h"
 #include "common.h"
+#include "fuse.h"
 #include "iomap.h"
 
 static struct tegra_ehci_platform_data tegra_ehci1_pdata = {
@@ -80,12 +83,36 @@ static struct of_dev_auxdata tegra20_auxdata_lookup[] 
__initdata = {
 
 static void __init tegra_dt_init(void)
 {
+   struct soc_device_attribute *soc_dev_attr;
+   struct soc_device *soc_dev;
+   struct device *parent = NULL;
+
+   soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+   if (!soc_dev_attr)
+   goto out;
+
+   soc_dev_attr->family = kasprintf(GFP_KERNEL, "Tegra");
+   soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%d", tegra_revision);
+   soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%d", tegra_chip_id);
+
+   soc_dev = soc_device_register(soc_dev_attr);
+   if (IS_ERR(soc_dev)) {
+   kfree(soc_dev_attr->family);
+   kfree(soc_dev_attr->revision);
+   kfree(soc_dev_attr->soc_id);
+   kfree(soc_dev_attr);
+   goto out;
+   }
+
+   parent = soc_device_to_device(soc_dev);
+
/*
 * Finished with the static registrations now; fill in the missing
 * devices
 */
+out:
of_platform_populate(NULL, of_default_bus_match_table,
-   tegra20_auxdata_lookup, NULL);
+   tegra20_auxdata_lookup, parent);
 }
 
 static void __init trimslice_init(void)
-- 
1.8.1.5

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

Re: [PATCH] dma: ipu: ipu_idmac: Fix section mismatch

[Maxin B. John]

On Wed, Mar 13, 2013 at 1:53 AM, Fabio Estevam  wrote:
> 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.

Good catch...
Acked-by:  Maxin B. John 

> 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(&idmac->dma);
>  }
>
> -static void __exit ipu_idmac_exit(struct ipu *ipu)
> +static void ipu_idmac_exit(struct ipu *ipu)
>  {
> int i;
> struct idmac *idmac = &ipu->idmac;
> --
> 1.7.9.5
>
> --

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

Re: [PATCH 2/4] Input: cyapa - Firmware update via request firmware

[Dmitry Torokhov]

On Wed, Mar 13, 2013 at 04:50:49PM -0700, Benson Leung wrote:
> +
> +#define BYTE_PER_LINE  8
> +void cyapa_dump_data(struct cyapa *cyapa, size_t length, const u8 *data)
> +{
> +#ifdef DEBUG
> + struct device *dev = &cyapa->client->dev;
> + int i;
> + char buf[BYTE_PER_LINE * 3 + 1];
> + char *s = buf;
> +
> + for (i = 0; i < length; i++) {
> + s += sprintf(s, " %02x", data[i]);
> + if ((i + 1) == length || ((i + 1) % BYTE_PER_LINE) == 0) {
> + dev_dbg(dev, "%s\n", buf);
> + s = buf;
> + }
> + }
> +#endif
> +}
> +#undef BYTE_PER_LINE

We have dev_dbg("%*ph\n", BYTES_PER_LINE, data[...]); for this.

Thanks.

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

Re: [PATCH] dmi_scan: proper buf type in dmi_present()

[Ben Hutchings]

On Wed, 2013-03-13 at 00:17 +0400, Artem Savkov wrote:
> buf needs to be unsigned in dmi_present(), otherwise dmi_base calculation
> doesn't work properly leading to a wraparound during dmi_ioremap:
> 
> [0.00] [ cut here ]
> [0.00] WARNING: at arch/x86/mm/ioremap.c:524 
> __early_ioremap+0x85/0x18a()
> [0.00] Modules linked in:
> [0.00] Pid: 0, comm: swapper Not tainted 3.9.0-rc2-next-20130312 #283
> [0.00] Call Trace:
> [0.00]  [] warn_slowpath_common+0x72/0xa0
> [0.00]  [] ? __early_ioremap+0x85/0x18a
> [0.00]  [] ? __early_ioremap+0x85/0x18a
> [0.00]  [] warn_slowpath_null+0x22/0x30
> [0.00]  [] __early_ioremap+0x85/0x18a
> [0.00]  [] ? __early_ioremap+0xfc/0x18a
> [0.00]  [] early_ioremap+0xd/0xf
> [0.00]  [] dmi_present+0xf5/0x22a
> [0.00]  [] dmi_scan_machine+0xbf/0x11c
> [0.00]  [] setup_arch+0x4db/0xca0
> [0.00]  [] ? printk+0x3d/0x3f
> [0.00]  [] start_kernel+0x7b/0x329
> [0.00]  [] i386_start_kernel+0x137/0x13a
> [0.00] ---[ end trace 4eaa2a86a8e2da22 ]---
> [0.00] DMI not present or invalid.
> 
> Introduced in "dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()"
> 
> Signed-off-by: Artem Savkov 
Acked-by: Ben Hutchings 

Wow, this is a pretty obvious fix.  Somehow this code did work for at
least two of us, so I suppose we were (un)lucky to have bit 7 clear on
all the critical bytes!

Ben.

> ---
>  drivers/firmware/dmi_scan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 3439f59..40e940d 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -410,7 +410,7 @@ static void __init dmi_dump_ids(void)
>   printk(KERN_CONT "\n");
>  }
>  
> -static int __init dmi_present(const char *buf)
> +static int __init dmi_present(const u8 *buf)
>  {
>   int smbios_ver;
>  

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

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

[Alexander Graf]

On 13.03.2013, at 18:59, Doug Anderson wrote:

> Alexander,
> 
> On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf  wrote:
>> 
 +   gpio_free(gpio);
>>> 
>>> Freeing the gpio is a little on the iffy side since you actually care
>>> about keeping the value.  Perhaps you can change this to
>>> devm_gpio_request_one() and avoid the free?  I was about to submit a
>>> patch to do just that (since otherwise you run into trouble if you
>>> ever defer the probe) but then ran across your patch.
>> 
>> I could also just return it when the function exits and only free it when we 
>> exit the probe function with a negative value. The reason I put it in here 
>> was that on probe deferral, the pin simply gets blocked.
>> 
>> However, I could probably also just completely take the gpio_free() out of 
>> this patch and resubmit, as it should be pretty much unrelated. Then you can 
>> patch it properly.
> 
> Sure, if you want to resubmit without the gpio_free() I'll submit a
> new patch atop yours with the change to devm and people can see if
> they like it...

Hrm. So when I remove the gpio_free() again, I can't find the USB hub anymore. 
If I however postpone the whole reset procedure until after the potential 
deferral, it works (see patch below).

Any idea what is going on here?


Alex


diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index f692f70..b29b2b8 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -136,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
 
-   s5p_setup_vbus_gpio(pdev);
-
s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
@@ -157,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
s5p_ehci->otg = phy->otg;
}
 
+   s5p_setup_vbus_gpio(pdev);
+
s5p_ehci->dev = &pdev->dev;
 
hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/3] genirq: Do not consider the irqs with IRQF_NO_SUSPEND in check_wakeup_irqs()

[Liu, Chuansheng]

Hello Thomas,

Sorry to miss the V2 in the subject.
I have updated the comments in this new patch, could you consider to take it 
into upstream?

Thanks.

Best Regards
Liu chuansheng

> -Original Message-
> From: Liu, Chuansheng
> Sent: Tuesday, March 12, 2013 5:58 PM
> To: t...@linutronix.de
> Cc: mi...@redhat.com; linux-kernel@vger.kernel.org; Liu, Chuansheng
> Subject: [PATCH 2/3] genirq: Do not consider the irqs with IRQF_NO_SUSPEND
> in check_wakeup_irqs()
> 
> 
> According to commit 9c6079aa1bf(genirq: Do not consider disabled
> wakeup irqs), we should not break the suspend when one interrupt has
> been disabled before suspending and is pending there.
> 
> But there is another case missed:
> If an interrupt which is marked IRQF_NO_SUSPEND has been disabled
> before suspend invocation then desc->depth is 1 and therefor it should
> not be checked for IRQS_PENDING in check_wakeup_irqs().
> 
> Here also checking if the desc->istate & IRQS_SUSPENDED is true to avoid
> this case.
> 
> Signed-off-by: liu chuansheng 
> ---
>  kernel/irq/pm.c |9 -
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> index cb228bf..f02a03d 100644
> --- a/kernel/irq/pm.c
> +++ b/kernel/irq/pm.c
> @@ -107,9 +107,16 @@ int check_wakeup_irqs(void)
>* Only interrupts which are marked as wakeup source
>* and have not been disabled before the suspend check
>* can abort suspend.
> +  *
> +  * Meanwhile, if an interrupt which is marked IRQF_NO_SUSPEND
> +  * has been disabled before suspend invocation then
> +  * desc->depth is 1 and therefor it should not be checked
> +  * for IRQS_PENDING, so also adding the checking of
> +  * desc->istate & IRQS_SUSPENDED for this case.
>*/
>   if (irqd_is_wakeup_set(&desc->irq_data)) {
> - if (desc->depth == 1 && desc->istate & IRQS_PENDING)
> + if (desc->depth == 1 && (desc->istate & IRQS_PENDING)
> + && (desc->istate & IRQS_SUSPENDED))
>   return -EBUSY;
>   continue;
>   }
> --
> 1.7.0.4
> 
> 

Re: [ 008/153] powerpc/eeh: Fix crash when adding a device in a slot with DDW

[Ben Hutchings]

On Wed, 2013-03-13 at 10:17 +1100, Michael Neuling wrote:
> Thadeu Lima de Souza Cascardo  wrote:
> 
> > On Fri, Mar 08, 2013 at 03:29:55AM +, Ben Hutchings wrote:
> > > On Fri, 2013-03-08 at 13:51 +1100, Michael Neuling wrote:
> > > > This patch is breaking the celleb_defconfig on powerpc with:
> > > > 
> > > > arch/powerpc/kernel/of_platform.c: In function 'of_pci_phb_probe':
> > > > arch/powerpc/kernel/of_platform.c:95:2: error: implicit declaration of
> > > > function 'eeh_add_sysfs_files' [-Werror=implicit-function-declaration]
> > > 
> > > In 3.2 this file doesn't (directly) include  which is where
> > > the definition was added.  In mainline it does.
> > > 
> > > Assuming that this change is actually required for 3.2 (which I'm not
> > > sure about), I suppose we just need to add the #include.
> > > 
> > > Ben.
> > > 
> > 
> > This is not required for 3.2. The patch that *may* have broken DLPAR
> > (39baadbf36cee3ede5fdb8a34006d9109e5e2570) was introduced between 3.3
> > and 3.4.
> 
> Reverting 066f289835f09a3f744d6bac96f25e25d20b3ded (from 3.2.40) fixes
> the problem for me so I'm ok if we do that instead.

Thanks all; I've queued up the revert.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: linux-next: Tree for Mar 7

[Stephen Rothwell]

Hi "Jörn",

On Tue, 12 Mar 2013 19:33:11 -0400 Jörn Engel  wrote:
>
> On Wed, 13 March 2013 11:11:44 +1100, Stephen Rothwell wrote:
> > On Tue, 12 Mar 2013 14:44:22 -0400 Jörn Engel  wrote:
> > >
> > > Any chance to get the bcon tree included?
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/joern/bcon2.git
> > 
> > Well, maybe you could tell me something about that tree i.e. what is in
> > it, why I should merge it, how it will be sent to Linus ... also what
> > branch to fetch and who should be contacted about conflicts, build
> > problems etc.
> 
> What is in it:
> - Mainly blockconsole, a console driver that will write printk
>   messages to block devices.  Very useful when netconsole, for
>   whatever reasons, is not available.  Code is originally from April
>   last year and by now we have upwards of 100 machines running it.
>   A number of bugs were identified because of it.
> - Also a patchset to disable the loglevel filtering for
>   non-interactive consoles like blockconsole and netconsole.  Again,
>   we run it across the board and real bugs were fixed because of it.
> 
> Why should you merge it:
> I plan to send this to Linus in the next merge window.
> 
> How will it be sent to Linus:
> Merge request, unless someone finds a good reason against it.
> 
> What branch:
> master.  I personally don't use branches at all, at least not
> consciously.
> 
> Who should be contacted about conflicts, etc:
> Me.
> 
> > Also consider: is this stuff ready for inclusion in Linus' tree (maybe
> > apart from integration conflicts), is it well reviewed/tested?
> 
> Two people from SuSE seem to find the code useful and have provided
> testing and patches.  To the best of my knowledge this code is ready
> to go and useful for more people that just me or $EMPLOYER.
> 
> I will be giving a talk at the collaboration summit that is
> essentially going to cover this tree.  Conferences have a lower bar
> for acceptance than Linus does, but at least it must have caught
> someone's interest.

Added from today.

One thing, the last few commits from Takashi do not have your
Signed-off-by even though you committed them.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
s...@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.


pgpG2yHQVkYby.pgp
Description: PGP signature

New MFD tree for linux-next

[Samuel Ortiz]

Hi Stephen,

I am moving the MFD development from mfd-2.6.git/for-next to a new mfd-next
tree:

git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git

Could you please point linux-next at it ? Many thanks in advance.

Cheers,
Samuel.

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

Re: gcc/binutils bug suspected -- recommended actions?

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

On 14 March 2013 02:36, Sergey Yanovich  wrote:
> 3.8.2 ARM kernel panics on boot. BUG() log:
>
> Where should I look?

It wasn't gcc or ldd. I hit a BUG_ON() in kernel code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] workqueue: update comments and a warning message

[Tejun Heo]

* Update incorrect and add missing synchronization labels.

* Update incorrect or misleading comments.  Add new comments where
  clarification is necessary.  Reformat / rephrase some comments.

* drain_workqueue() can be used separately from destroy_workqueue()
  but its warning message was incorrectly referring to destruction.

Other than the warning message change, this patch doesn't make any
functional changes.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 84 --
 1 file changed, 44 insertions(+), 40 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7567614..248a1e9 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -145,7 +145,7 @@ struct worker_pool {
struct timer_list   idle_timer; /* L: worker idle timeout */
struct timer_list   mayday_timer;   /* L: SOS timer for workers */
 
-   /* workers are chained either in busy_hash or idle_list */
+   /* a workers is either on busy_hash or idle_list, or the manager */
DECLARE_HASHTABLE(busy_hash, BUSY_WORKER_HASH_ORDER);
/* L: hash of busy workers */
 
@@ -154,8 +154,8 @@ struct worker_pool {
struct ida  worker_ida; /* L: for worker IDs */
 
struct workqueue_attrs  *attrs; /* I: worker attributes */
-   struct hlist_node   hash_node;  /* R: unbound_pool_hash node */
-   int refcnt; /* refcnt for unbound pools */
+   struct hlist_node   hash_node;  /* W: unbound_pool_hash node */
+   int refcnt; /* W: refcnt for unbound pools 
*/
 
/*
 * The current concurrency level.  As it's likely to be accessed
@@ -213,8 +213,8 @@ struct wq_flusher {
 struct wq_device;
 
 /*
- * The externally visible workqueue abstraction is an array of
- * per-CPU workqueues:
+ * The externally visible workqueue.  It relays the issued work items to
+ * the appropriate worker_pool through its pool_workqueues.
  */
 struct workqueue_struct {
unsigned intflags;  /* W: WQ_* flags */
@@ -247,9 +247,10 @@ struct workqueue_struct {
 
 static struct kmem_cache *pwq_cache;
 
-/* hash of all unbound pools keyed by pool->attrs */
+/* W: hash of all unbound pools keyed by pool->attrs */
 static DEFINE_HASHTABLE(unbound_pool_hash, UNBOUND_POOL_HASH_ORDER);
 
+/* I: attributes used when instantiating standard unbound pools on demand */
 static struct workqueue_attrs *unbound_std_wq_attrs[NR_STD_WORKER_POOLS];
 
 struct workqueue_struct *system_wq __read_mostly;
@@ -434,16 +435,13 @@ static DEFINE_SPINLOCK(workqueue_lock);
 static LIST_HEAD(workqueues);
 static bool workqueue_freezing;/* W: have wqs started 
freezing? */
 
-/*
- * The CPU and unbound standard worker pools.  The unbound ones have
- * POOL_DISASSOCIATED set, and their workers have WORKER_UNBOUND set.
- */
+/* the per-cpu worker pools */
 static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
 cpu_worker_pools);
 
 /*
- * idr of all pools.  Modifications are protected by workqueue_lock.  Read
- * accesses are protected by sched-RCU protected.
+ * R: idr of all pools.  Modifications are protected by workqueue_lock.
+ * Read accesses are protected by sched-RCU protected.
  */
 static DEFINE_IDR(worker_pool_idr);
 
@@ -890,13 +888,12 @@ static inline void worker_clr_flags(struct worker 
*worker, unsigned int flags)
  * recycled work item as currently executing and make it wait until the
  * current execution finishes, introducing an unwanted dependency.
  *
- * This function checks the work item address, work function and workqueue
- * to avoid false positives.  Note that this isn't complete as one may
- * construct a work function which can introduce dependency onto itself
- * through a recycled work item.  Well, if somebody wants to shoot oneself
- * in the foot that badly, there's only so much we can do, and if such
- * deadlock actually occurs, it should be easy to locate the culprit work
- * function.
+ * This function checks the work item address and work function to avoid
+ * false positives.  Note that this isn't complete as one may construct a
+ * work function which can introduce dependency onto itself through a
+ * recycled work item.  Well, if somebody wants to shoot oneself in the
+ * foot that badly, there's only so much we can do, and if such deadlock
+ * actually occurs, it should be easy to locate the culprit work function.
  *
  * CONTEXT:
  * spin_lock_irq(pool->lock).
@@ -1187,9 +1184,9 @@ static void insert_work(struct pool_workqueue *pwq, 
struct work_struct *work,
get_pwq(pwq);
 
/*
-* Ensure either worker_sched_deactivated() sees the above
-* list_add_tail() or we see zero nr_running to avoid workers
-* lying around lazily while there are works to be proce

[PATCH 2/6] workqueue: implement and use pwq_adjust_max_active()

[Tejun Heo]

Rename pwq_set_max_active() to pwq_adjust_max_active() and move
pool_workqueue->max_active synchronization and max_active
determination logic into it.

The new function should be called with workqueue_lock held for stable
workqueue->saved_max_active, determines the current max_active value
the target pool_workqueue should be using from @wq->saved_max_active
and the state of the associated pool, and applies it with proper
synchronization.

The current two users - workqueue_set_max_active() and
thaw_workqueues() - are updated accordingly.  In addition, the manual
freezing handling in __alloc_workqueue_key() and
freeze_workqueues_begin() are replaced with calls to
pwq_adjust_max_active().

This centralizes max_active handling so that it's less error-prone.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 83 +-
 1 file changed, 38 insertions(+), 45 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index d519289..9e2ec4c 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3726,23 +3726,38 @@ static void pwq_unbound_release_workfn(struct 
work_struct *work)
 }
 
 /**
- * pwq_set_max_active - adjust max_active of a pwq
+ * pwq_adjust_max_active - update a pwq's max_active to the current setting
  * @pwq: target pool_workqueue
- * @max_active: new max_active value.
- *
- * Set @pwq->max_active to @max_active and activate delayed works if
- * increased.
  *
- * CONTEXT:
- * spin_lock_irq(pool->lock).
+ * If @pwq isn't freezing, set @pwq->max_active to the associated
+ * workqueue's saved_max_active and activate delayed work items
+ * accordingly.  If @pwq is freezing, clear @pwq->max_active to zero.
  */
-static void pwq_set_max_active(struct pool_workqueue *pwq, int max_active)
+static void pwq_adjust_max_active(struct pool_workqueue *pwq)
 {
-   pwq->max_active = max_active;
+   struct workqueue_struct *wq = pwq->wq;
+   bool freezable = wq->flags & WQ_FREEZABLE;
+
+   /* for @wq->saved_max_active */
+   lockdep_assert_held(&workqueue_lock);
+
+   /* fast exit for non-freezable wqs */
+   if (!freezable && pwq->max_active == wq->saved_max_active)
+   return;
+
+   spin_lock(&pwq->pool->lock);
+
+   if (!freezable || !(pwq->pool->flags & POOL_FREEZING)) {
+   pwq->max_active = wq->saved_max_active;
 
-   while (!list_empty(&pwq->delayed_works) &&
-  pwq->nr_active < pwq->max_active)
-   pwq_activate_first_delayed(pwq);
+   while (!list_empty(&pwq->delayed_works) &&
+  pwq->nr_active < pwq->max_active)
+   pwq_activate_first_delayed(pwq);
+   } else {
+   pwq->max_active = 0;
+   }
+
+   spin_unlock(&pwq->pool->lock);
 }
 
 static void init_and_link_pwq(struct pool_workqueue *pwq,
@@ -3932,15 +3947,14 @@ struct workqueue_struct *__alloc_workqueue_key(const 
char *fmt,
goto err_destroy;
 
/*
-* workqueue_lock protects global freeze state and workqueues
-* list.  Grab it, set max_active accordingly and add the new
-* workqueue to workqueues list.
+* workqueue_lock protects global freeze state and workqueues list.
+* Grab it, adjust max_active and add the new workqueue to
+* workqueues list.
 */
spin_lock_irq(&workqueue_lock);
 
-   if (workqueue_freezing && wq->flags & WQ_FREEZABLE)
-   for_each_pwq(pwq, wq)
-   pwq->max_active = 0;
+   for_each_pwq(pwq, wq)
+   pwq_adjust_max_active(pwq);
 
list_add(&wq->list, &workqueues);
 
@@ -4055,17 +4069,8 @@ void workqueue_set_max_active(struct workqueue_struct 
*wq, int max_active)
 
wq->saved_max_active = max_active;
 
-   for_each_pwq(pwq, wq) {
-   struct worker_pool *pool = pwq->pool;
-
-   spin_lock(&pool->lock);
-
-   if (!(wq->flags & WQ_FREEZABLE) ||
-   !(pool->flags & POOL_FREEZING))
-   pwq_set_max_active(pwq, max_active);
-
-   spin_unlock(&pool->lock);
-   }
+   for_each_pwq(pwq, wq)
+   pwq_adjust_max_active(pwq);
 
spin_unlock_irq(&workqueue_lock);
 }
@@ -4358,14 +4363,8 @@ void freeze_workqueues_begin(void)
 
/* suppress further executions by setting max_active to zero */
list_for_each_entry(wq, &workqueues, list) {
-   if (!(wq->flags & WQ_FREEZABLE))
-   continue;
-
-   for_each_pwq(pwq, wq) {
-   spin_lock(&pwq->pool->lock);
-   pwq->max_active = 0;
-   spin_unlock(&pwq->pool->lock);
-   }
+   for_each_pwq(pwq, wq)
+   pwq_adjust_max_active(pwq);
}
 
spin_unlock_irq(&workqueue_lock);
@@ -4445,14 +,8 @@ void thaw_workqueues(void)
 
/* restore max_active and rep

[PATCH 3/6] workqueue: fix max_active handling in init_and_link_pwq()

[Tejun Heo]

Since 9e8cd2f589 ("workqueue: implement apply_workqueue_attrs()"),
init_and_link_pwq() may be called to initialize a new pool_workqueue
for a workqueue which is already online, but the function was setting
pwq->max_active to wq->saved_max_active without proper
synchronization.

Fix it by calling pwq_adjust_max_active() under proper locking instead
of manually setting max_active.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9e2ec4c..7567614 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3771,21 +3771,25 @@ static void init_and_link_pwq(struct pool_workqueue 
*pwq,
pwq->wq = wq;
pwq->flush_color = -1;
pwq->refcnt = 1;
-   pwq->max_active = wq->saved_max_active;
INIT_LIST_HEAD(&pwq->delayed_works);
INIT_LIST_HEAD(&pwq->mayday_node);
INIT_WORK(&pwq->unbound_release_work, pwq_unbound_release_workfn);
 
-   /*
-* Link @pwq and set the matching work_color.  This is synchronized
-* with flush_mutex to avoid confusing flush_workqueue().
-*/
mutex_lock(&wq->flush_mutex);
spin_lock_irq(&workqueue_lock);
 
+   /*
+* Set the matching work_color.  This is synchronized with
+* flush_mutex to avoid confusing flush_workqueue().
+*/
if (p_last_pwq)
*p_last_pwq = first_pwq(wq);
pwq->work_color = wq->work_color;
+
+   /* sync max_active to the current setting */
+   pwq_adjust_max_active(pwq);
+
+   /* link in @pwq */
list_add_rcu(&pwq->pwqs_node, &wq->pwqs);
 
spin_unlock_irq(&workqueue_lock);
-- 
1.8.1.4

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

[PATCH 6/6] workqueue: inline trivial wrappers

[Tejun Heo]

There's no reason to make these trivial wrappers full (exported)
functions.  Inline the followings.

 queue_work()
 queue_delayed_work()
 mod_delayed_work()
 schedule_work_on()
 schedule_work()
 schedule_delayed_work_on()
 schedule_delayed_work()
 keventd_up()

Signed-off-by: Tejun Heo 
---
 include/linux/workqueue.h | 123 +-
 kernel/workqueue.c| 111 -
 2 files changed, 111 insertions(+), 123 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index df30763..835d12b 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -417,28 +417,16 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
 
 extern bool queue_work_on(int cpu, struct workqueue_struct *wq,
struct work_struct *work);
-extern bool queue_work(struct workqueue_struct *wq, struct work_struct *work);
 extern bool queue_delayed_work_on(int cpu, struct workqueue_struct *wq,
struct delayed_work *work, unsigned long delay);
-extern bool queue_delayed_work(struct workqueue_struct *wq,
-   struct delayed_work *work, unsigned long delay);
 extern bool mod_delayed_work_on(int cpu, struct workqueue_struct *wq,
struct delayed_work *dwork, unsigned long delay);
-extern bool mod_delayed_work(struct workqueue_struct *wq,
-   struct delayed_work *dwork, unsigned long delay);
 
 extern void flush_workqueue(struct workqueue_struct *wq);
 extern void drain_workqueue(struct workqueue_struct *wq);
 extern void flush_scheduled_work(void);
 
-extern bool schedule_work_on(int cpu, struct work_struct *work);
-extern bool schedule_work(struct work_struct *work);
-extern bool schedule_delayed_work_on(int cpu, struct delayed_work *work,
-unsigned long delay);
-extern bool schedule_delayed_work(struct delayed_work *work,
- unsigned long delay);
 extern int schedule_on_each_cpu(work_func_t func);
-extern int keventd_up(void);
 
 int execute_in_process_context(work_func_t fn, struct execute_work *);
 
@@ -455,6 +443,117 @@ extern bool current_is_workqueue_rescuer(void);
 extern bool workqueue_congested(int cpu, struct workqueue_struct *wq);
 extern unsigned int work_busy(struct work_struct *work);
 
+/**
+ * queue_work - queue work on a workqueue
+ * @wq: workqueue to use
+ * @work: work to queue
+ *
+ * Returns %false if @work was already on a queue, %true otherwise.
+ *
+ * We queue the work to the CPU on which it was submitted, but if the CPU dies
+ * it can be processed by another CPU.
+ */
+static inline bool queue_work(struct workqueue_struct *wq,
+ struct work_struct *work)
+{
+   return queue_work_on(WORK_CPU_UNBOUND, wq, work);
+}
+
+/**
+ * queue_delayed_work - queue work on a workqueue after delay
+ * @wq: workqueue to use
+ * @dwork: delayable work to queue
+ * @delay: number of jiffies to wait before queueing
+ *
+ * Equivalent to queue_delayed_work_on() but tries to use the local CPU.
+ */
+static inline bool queue_delayed_work(struct workqueue_struct *wq,
+ struct delayed_work *dwork,
+ unsigned long delay)
+{
+   return queue_delayed_work_on(WORK_CPU_UNBOUND, wq, dwork, delay);
+}
+
+/**
+ * mod_delayed_work - modify delay of or queue a delayed work
+ * @wq: workqueue to use
+ * @dwork: work to queue
+ * @delay: number of jiffies to wait before queueing
+ *
+ * mod_delayed_work_on() on local CPU.
+ */
+static inline bool mod_delayed_work(struct workqueue_struct *wq,
+   struct delayed_work *dwork,
+   unsigned long delay)
+{
+   return mod_delayed_work_on(WORK_CPU_UNBOUND, wq, dwork, delay);
+}
+
+/**
+ * schedule_work_on - put work task on a specific cpu
+ * @cpu: cpu to put the work task on
+ * @work: job to be done
+ *
+ * This puts a job on a specific cpu
+ */
+static inline bool schedule_work_on(int cpu, struct work_struct *work)
+{
+   return queue_work_on(cpu, system_wq, work);
+}
+
+/**
+ * schedule_work - put work task in global workqueue
+ * @work: job to be done
+ *
+ * Returns %false if @work was already on the kernel-global workqueue and
+ * %true otherwise.
+ *
+ * This puts a job in the kernel-global workqueue if it was not already
+ * queued and leaves it in the same position on the kernel-global
+ * workqueue otherwise.
+ */
+static inline bool schedule_work(struct work_struct *work)
+{
+   return queue_work(system_wq, work);
+}
+
+/**
+ * schedule_delayed_work_on - queue work in global workqueue on CPU after delay
+ * @cpu: cpu to use
+ * @dwork: job to be done
+ * @delay: number of jiffies to wait
+ *
+ * After waiting for a given time this puts a job in the kernel-global
+ * workqueue on the specified CPU.
+ */
+static inline bool schedule_de

[PATCH 1/6] workqueue: relocate pwq_set_max_active()

[Tejun Heo]

pwq_set_max_active() is gonna be modified and used during
pool_workqueue init.  Move it above init_and_link_pwq().

This patch is pure code reorganization and doesn't introduce any
functional changes.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f5c8bbb..d519289 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3725,6 +3725,26 @@ static void pwq_unbound_release_workfn(struct 
work_struct *work)
kfree(wq);
 }
 
+/**
+ * pwq_set_max_active - adjust max_active of a pwq
+ * @pwq: target pool_workqueue
+ * @max_active: new max_active value.
+ *
+ * Set @pwq->max_active to @max_active and activate delayed works if
+ * increased.
+ *
+ * CONTEXT:
+ * spin_lock_irq(pool->lock).
+ */
+static void pwq_set_max_active(struct pool_workqueue *pwq, int max_active)
+{
+   pwq->max_active = max_active;
+
+   while (!list_empty(&pwq->delayed_works) &&
+  pwq->nr_active < pwq->max_active)
+   pwq_activate_first_delayed(pwq);
+}
+
 static void init_and_link_pwq(struct pool_workqueue *pwq,
  struct workqueue_struct *wq,
  struct worker_pool *pool,
@@ -4012,26 +4032,6 @@ void destroy_workqueue(struct workqueue_struct *wq)
 EXPORT_SYMBOL_GPL(destroy_workqueue);
 
 /**
- * pwq_set_max_active - adjust max_active of a pwq
- * @pwq: target pool_workqueue
- * @max_active: new max_active value.
- *
- * Set @pwq->max_active to @max_active and activate delayed works if
- * increased.
- *
- * CONTEXT:
- * spin_lock_irq(pool->lock).
- */
-static void pwq_set_max_active(struct pool_workqueue *pwq, int max_active)
-{
-   pwq->max_active = max_active;
-
-   while (!list_empty(&pwq->delayed_works) &&
-  pwq->nr_active < pwq->max_active)
-   pwq_activate_first_delayed(pwq);
-}
-
-/**
  * workqueue_set_max_active - adjust max_active of a workqueue
  * @wq: target workqueue
  * @max_active: new max_active value.
-- 
1.8.1.4

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

[PATCH 5/6] workqueue: rename @id to @pi in for_each_each_pool()

[Tejun Heo]

Rename @id argument of for_each_pool() to @pi so that it doesn't get
reused accidentally when for_each_pool() is used in combination with
other iterators.

This patch is purely cosmetic.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 248a1e9..147fc5a 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -283,7 +283,7 @@ EXPORT_SYMBOL_GPL(system_freezable_wq);
 /**
  * for_each_pool - iterate through all worker_pools in the system
  * @pool: iteration cursor
- * @id: integer used for iteration
+ * @pi: integer used for iteration
  *
  * This must be called either with workqueue_lock held or sched RCU read
  * locked.  If the pool needs to be used beyond the locking in effect, the
@@ -292,8 +292,8 @@ EXPORT_SYMBOL_GPL(system_freezable_wq);
  * The if/else clause exists only for the lockdep assertion and can be
  * ignored.
  */
-#define for_each_pool(pool, id)
\
-   idr_for_each_entry(&worker_pool_idr, pool, id)  \
+#define for_each_pool(pool, pi)
\
+   idr_for_each_entry(&worker_pool_idr, pool, pi)  \
if (({ assert_rcu_or_wq_lock(); false; })) { }  \
else
 
@@ -4354,7 +4354,7 @@ void freeze_workqueues_begin(void)
struct worker_pool *pool;
struct workqueue_struct *wq;
struct pool_workqueue *pwq;
-   int id;
+   int pi;
 
spin_lock_irq(&workqueue_lock);
 
@@ -4362,7 +4362,7 @@ void freeze_workqueues_begin(void)
workqueue_freezing = true;
 
/* set FREEZING */
-   for_each_pool(pool, id) {
+   for_each_pool(pool, pi) {
spin_lock(&pool->lock);
WARN_ON_ONCE(pool->flags & POOL_FREEZING);
pool->flags |= POOL_FREEZING;
@@ -4435,7 +4435,7 @@ void thaw_workqueues(void)
struct workqueue_struct *wq;
struct pool_workqueue *pwq;
struct worker_pool *pool;
-   int id;
+   int pi;
 
spin_lock_irq(&workqueue_lock);
 
@@ -4443,7 +4443,7 @@ void thaw_workqueues(void)
goto out_unlock;
 
/* clear FREEZING */
-   for_each_pool(pool, id) {
+   for_each_pool(pool, pi) {
spin_lock(&pool->lock);
WARN_ON_ONCE(!(pool->flags & POOL_FREEZING));
pool->flags &= ~POOL_FREEZING;
@@ -4457,7 +4457,7 @@ void thaw_workqueues(void)
}
 
/* kick workers */
-   for_each_pool(pool, id) {
+   for_each_pool(pool, pi) {
spin_lock(&pool->lock);
wake_up_worker(pool);
spin_unlock(&pool->lock);
-- 
1.8.1.4

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

[PATCHSET wq/for-3.10] workqueue: misc cleanups

[Tejun Heo]

Hello,

This patchset contains mostly cleanups and a fix for a bug in the new
unbound pools w/ attrs.

This patchset contains the following six patches.

 0001-workqueue-relocate-pwq_set_max_active.patch
 0002-workqueue-implement-and-use-pwq_adjust_max_active.patch
 0003-workqueue-fix-max_active-handling-in-init_and_link_p.patch
 0004-workqueue-update-comments-and-a-warning-message.patch
 0005-workqueue-rename-id-to-pi-in-for_each_each_pool.patch
 0006-workqueue-inline-trivial-wrappers.patch

0001-0002 clean up pwq->max_active handling.

0003 fixes a race condition around max_active handling for the new
unbound pools w/ attrs.

0004-0006 are cleanups which make no functional differences other than
inlining of some trivial wrappers.

This patch is on top of wq/for-3.10 e626761691 ("workqueue: implement
current_is_workqueue_rescuer()").

diffstat follows.  Thanks.

 include/linux/workqueue.h |  123 +++--
 kernel/workqueue.c|  324 +++---
 2 files changed, 218 insertions(+), 229 deletions(-)

--
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][GIT PULL][3.9] tracing: Fix free of probe entry by calling call_rcu_sched()

[Steven Rostedt]

Ingo,

While testing my new code I stumbled upon this bug. This is a real
bug and has been in the kernel forever. Luckily, it's in a feature
that is seldom used. But it can cause a crash if the race is hit.

I based this off of my last pull request of tip/perf/urgent.

Thanks,

-- Steve


Please pull the latest tip/perf/urgent-2 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/urgent-2

Head SHA1: 740466bc89ad8bd5afcc8de220f715f62b21e365


Steven Rostedt (Red Hat) (1):
  tracing: Fix free of probe entry by calling call_rcu_sched()


 kernel/trace/ftrace.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
---
commit 740466bc89ad8bd5afcc8de220f715f62b21e365
Author: Steven Rostedt (Red Hat) 
Date:   Wed Mar 13 11:15:19 2013 -0400

tracing: Fix free of probe entry by calling call_rcu_sched()

Because function tracing is very invasive, and can even trace
calls to rcu_read_lock(), RCU access in function tracing is done
with preempt_disable_notrace(). This requires a synchronize_sched()
for updates and not a synchronize_rcu().

Function probes (traceon, traceoff, etc) must be freed after
a synchronize_sched() after its entry has been removed from the
hash. But call_rcu() is used. Fix this by using call_rcu_sched().

Also fix the usage to use hlist_del_rcu() instead of hlist_del().

Cc: sta...@vger.kernel.org
Cc: Paul McKenney 
Signed-off-by: Steven Rostedt 

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 98ca94a..e6effd0 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3108,8 +3108,8 @@ __unregister_ftrace_function_probe(char *glob, struct 
ftrace_probe_ops *ops,
continue;
}
 
-   hlist_del(&entry->node);
-   call_rcu(&entry->rcu, ftrace_free_entry_rcu);
+   hlist_del_rcu(&entry->node);
+   call_rcu_sched(&entry->rcu, ftrace_free_entry_rcu);
}
}
__disable_ftrace_function_probe();


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: cyapa - Firmware update via request firmware

[Benson Leung]

From: Daniel Kurtz 

Use the kernel request_firmware API to allow a hotplug script to load new
firmware into CYAPA device.  When request_firmware is called by a driver,
the kernel creates 'loading' and 'data' sysfs entries, and generates a
firmware udev event containing the name of a file ("cyapa.bin").

A udev rule can detect this event and use the sysfs entries to provide the
driver with the contents of a binary image firmware image. For instance,
the gentoo distribution includes /lib/udev/rules.d/50-firmware.rules,
which looks in /lib/firmware/ for a file matching the requested filename,
and sends the file to the driver using its sysfs entries.

Userspace can initiate the firmware update procedure by copying cyapa.bin
to /lib/firmware, and then writing anything to the device sysfs attribute:
  /sys/bus/i2c/devices/7-0067/update_fw

Signed-off-by: Daniel Kurtz 
Signed-off-by: Benson Leung 
---
 drivers/input/mouse/cyapa.c | 351 
 1 file changed, 351 insertions(+)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index a631aca..e622c25 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -116,6 +117,9 @@
 #define BL_STATUS_SIZE  3  /* length of bootloader status registers */
 #define BLK_HEAD_BYTES 32
 
+/* Macro for register map group offset. */
+#define CYAPA_REG_MAP_SIZE  256
+
 #define PRODUCT_ID_SIZE  16
 #define QUERY_DATA_SIZE  27
 #define REG_PROTOCOL_GEN_QUERY_OFFSET  20
@@ -220,6 +224,8 @@ struct cyapa {
int physical_size_y;
 };
 
+static const u8 bl_activate[] = { 0x00, 0xff, 0x38, 0x00, 0x01, 0x02, 0x03,
+   0x04, 0x05, 0x06, 0x07 };
 static const u8 bl_deactivate[] = { 0x00, 0xff, 0x3b, 0x00, 0x01, 0x02, 0x03,
0x04, 0x05, 0x06, 0x07 };
 static const u8 bl_exit[] = { 0x00, 0xff, 0xa5, 0x00, 0x01, 0x02, 0x03, 0x04,
@@ -316,6 +322,41 @@ static const struct cyapa_cmd_len cyapa_smbus_cmds[] = {
{ CYAPA_SMBUS_BLK_HEAD, 16 },
 };
 
+#define CYAPA_FW_NAME  "cyapa.bin"
+#define CYAPA_FW_BLOCK_SIZE64
+#define CYAPA_FW_HDR_START 0x0780
+#define CYAPA_FW_HDR_BLOCK_COUNT  2
+#define CYAPA_FW_HDR_BLOCK_START  (CYAPA_FW_HDR_START / CYAPA_FW_BLOCK_SIZE)
+#define CYAPA_FW_HDR_SIZE  (CYAPA_FW_HDR_BLOCK_COUNT * \
+CYAPA_FW_BLOCK_SIZE)
+#define CYAPA_FW_DATA_START0x0800
+#define CYAPA_FW_DATA_BLOCK_COUNT  480
+#define CYAPA_FW_DATA_BLOCK_START  (CYAPA_FW_DATA_START / CYAPA_FW_BLOCK_SIZE)
+#define CYAPA_FW_DATA_SIZE (CYAPA_FW_DATA_BLOCK_COUNT * \
+CYAPA_FW_BLOCK_SIZE)
+#define CYAPA_FW_SIZE  (CYAPA_FW_HDR_SIZE + CYAPA_FW_DATA_SIZE)
+#define CYAPA_CMD_LEN  16
+
+#define BYTE_PER_LINE  8
+void cyapa_dump_data(struct cyapa *cyapa, size_t length, const u8 *data)
+{
+#ifdef DEBUG
+   struct device *dev = &cyapa->client->dev;
+   int i;
+   char buf[BYTE_PER_LINE * 3 + 1];
+   char *s = buf;
+
+   for (i = 0; i < length; i++) {
+   s += sprintf(s, " %02x", data[i]);
+   if ((i + 1) == length || ((i + 1) % BYTE_PER_LINE) == 0) {
+   dev_dbg(dev, "%s\n", buf);
+   s = buf;
+   }
+   }
+#endif
+}
+#undef BYTE_PER_LINE
+
 static ssize_t cyapa_i2c_reg_read_block(struct cyapa *cyapa, u8 reg, size_t 
len,
u8 *values)
 {
@@ -498,6 +539,75 @@ static int cyapa_poll_state(struct cyapa *cyapa, unsigned 
int timeout)
return (ret == -EAGAIN || ret == -ETIMEDOUT) ? -ETIMEDOUT : ret;
 }
 
+/*
+ * Enter bootloader by soft resetting the device.
+ *
+ * If device is already in the bootloader, the function just returns.
+ * Otherwise, reset the device; after reset, device enters bootloader idle
+ * state immediately.
+ *
+ * Also, if device was unregister device from input core.  Device will
+ * re-register after it is detected following resumption of operational mode.
+ *
+ * Returns:
+ *   0 on success
+ *   -EAGAIN  device was reset, but is not now in bootloader idle state
+ *   < 0 if the device never responds within the timeout
+ */
+static int cyapa_bl_enter(struct cyapa *cyapa)
+{
+   int ret;
+
+   if (cyapa->input) {
+   disable_irq(cyapa->irq);
+   input_unregister_device(cyapa->input);
+   cyapa->input = NULL;
+   }
+
+   ret = cyapa_get_state(cyapa);
+   if (ret < 0)
+   return ret;
+   if (cyapa->state == CYAPA_STATE_BL_IDLE)
+   return 0;
+
+   if (cyapa->state != CYAPA_STATE_OP)
+   return -EAGAIN;
+
+   cyapa->state = CYAPA_STATE_NO_DEVICE;
+   ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET, 0x01);
+   if (ret < 0)
+   return -EIO;
+
+   usleep_range(25000, 5);
+   ret = cyapa_get_state(cyapa);
+   if (ret < 0)
+   

[PATCH 4/4] Input: cyapa - Add sysfs attrs for product_id and fw version

[Benson Leung]

Add attributes to expose the product_id and firmware_version read
from the device firmware.

Signed-off-by: Dudley Du 
Signed-off-by: Benson Leung 
---
 drivers/input/mouse/cyapa.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 51e9d44..97828f6 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -216,6 +216,8 @@ struct cyapa {
 
/* read from query data region. */
char product_id[16];
+   u8 fw_maj_ver;  /* firmware major version. */
+   u8 fw_min_ver;  /* firmware minor version. */
u8 btn_capability;
u8 gen;
int max_abs_x;
@@ -714,6 +716,9 @@ static int cyapa_get_query_data(struct cyapa *cyapa)
memcpy(&cyapa->product_id[13], &query_data[11], 2);
cyapa->product_id[15] = '\0';
 
+   cyapa->fw_maj_ver = query_data[15];
+   cyapa->fw_min_ver = query_data[16];
+
cyapa->btn_capability = query_data[19] & CAPABILITY_BTN_MASK;
 
cyapa->gen = query_data[20] & 0x0f;
@@ -1175,6 +1180,21 @@ done:
 /*
  * Sysfs Interface.
  */
+static ssize_t cyapa_show_fm_ver(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   return scnprintf(buf, PAGE_SIZE, "%d.%d\n", cyapa->fw_maj_ver,
+cyapa->fw_min_ver);
+}
+
+static ssize_t cyapa_show_product_id(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   return scnprintf(buf, PAGE_SIZE, "%s\n", cyapa->product_id);
+}
+
 static ssize_t cyapa_update_fw_store(struct device *dev,
 struct device_attribute *attr,
 const char *buf, size_t count)
@@ -1199,9 +1219,13 @@ static ssize_t cyapa_update_fw_store(struct device *dev,
return ret ? ret : count;
 }
 
+static DEVICE_ATTR(firmware_version, S_IRUGO, cyapa_show_fm_ver, NULL);
+static DEVICE_ATTR(product_id, S_IRUGO, cyapa_show_product_id, NULL);
 static DEVICE_ATTR(update_fw, S_IWUSR, NULL, cyapa_update_fw_store);
 
 static struct attribute *cyapa_sysfs_entries[] = {
+   &dev_attr_firmware_version.attr,
+   &dev_attr_product_id.attr,
&dev_attr_update_fw.attr,
NULL,
 };
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: cyapa - Allow filename to be changed in update_fw

[Benson Leung]

Allow the name of the designated firmware to be passed as the
argument to update_fw from user space. This will allow user space
to specify which firmware to load.

Signed-off-by: Benson Leung 
---
 drivers/input/mouse/cyapa.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index e622c25..51e9d44 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -1180,9 +1180,16 @@ static ssize_t cyapa_update_fw_store(struct device *dev,
 const char *buf, size_t count)
 {
struct cyapa *cyapa = dev_get_drvdata(dev);
-   const char *fw_name = CYAPA_FW_NAME;
+   const char *fw_name;
int ret;
 
+   /* Do not allow paths that step out of /lib/firmware  */
+   if (strstr(buf, "../") != NULL)
+   return -EINVAL;
+
+   fw_name = !strncmp(buf, "1", count) ||
+ !strncmp(buf, "1\n", count) ? CYAPA_FW_NAME : buf;
+
ret = cyapa_firmware(cyapa, fw_name);
if (ret)
dev_err(dev, "firmware update failed, %d\n", ret);
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: cyapa - Add firmware update feature

[Benson Leung]

Add a feature to update trackpad firmware via request_firmware to cyapa.
The last patch in the series adds sysfs attributses useful for version
and product identification that a user mode utility will need to
keep track of the current firmware on the device.

This is used today on Chromebook systems with cypress trackpads:
Samsung Series 5 550 Chromebook
Acer C7
HP Pavilion 14
Samsung Chromebook (2012, ARM version)

[PATCH 1/4] Input: cyapa - Move common initialization to cyapa_detect
[PATCH 2/4] Input: cyapa - Firmware update via request firmware
[PATCH 3/4] Input: cyapa - Allow filename to be changed in update_fw
[PATCH 4/4] Input: cyapa - Add sysfs attrs for product_id and fw_version
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/