Re: [PATCH] Omnikey Cardman 4000: pull in ioctl.h in user header

2013-08-24 Thread Mike Frysinger
On Thursday 22 August 2013 18:55:45 Andrew Morton wrote:
 On Fri, 16 Aug 2013 14:07:09 -0400 Mike Frysinger wrote:
  This file uses the ioctl helpers (_IOR/_IOW/etc...), so include ioctl.h
  for the definitions.
  
  ...
  
  --- a/include/uapi/linux/cm4000_cs.h
  +++ b/include/uapi/linux/cm4000_cs.h
  @@ -2,6 +2,7 @@
   #define _UAPI_CM4000_H_
   
   #include linux/types.h
  +#include linux/ioctl.h
  
   #defineMAX_ATR 33
 
 I'm assuming this fixes a build error under unknown circumstances, or
 not, or something else?

yes, it's to fix a build error.  i don't have any specific source packages that 
are known to fail though.  just doing analysis of the headers by grep/eye.
-mike


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


Re: [PATCH] blackfin: Ignore generated uImages

2013-08-24 Thread Mike Frysinger
Acked-by: Mike Frysinger vap...@gentoo.org
-mike


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


Re: [PATCH] ARM: Add .text.unlikely and .text.hot to arm unwind tables

2013-08-24 Thread Mike Frysinger
Acked-by: Mike Frysinger vap...@gentoo.org
-mike


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


Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

2013-08-24 Thread Russell King - ARM Linux
On Sat, Aug 24, 2013 at 04:58:59PM -0300, Ezequiel Garcia wrote:
 On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
  On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
  ezequiel.gar...@free-electrons.com wrote:
   Some platforms have MMIO regions that are shared across orthogonal
   subsystems. This commit implements a possible solution for the
   thread-safe access of such regions through a spinlock-protected API.
  
   Concurrent access is protected with a single spinlock for the
   entire MMIO address space. While this protects shared-registers,
   it also serializes access to unrelated/unshared registers.
  
   Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
   ---
include/linux/io.h |  5 +
lib/Makefile   |  2 +-
lib/atomicio.c | 27 +++
3 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 lib/atomicio.c
  
   diff --git a/include/linux/io.h b/include/linux/io.h
   index f4f42fa..c331dcb 100644
   --- a/include/linux/io.h
   +++ b/include/linux/io.h
   @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
#define arch_phys_wc_add arch_phys_wc_add
#endif
  
   +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
   +/* Atomic MMIO-wide IO modify */
   +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
   +#endif
   +
#endif /* _LINUX_IO_H */
   diff --git a/lib/Makefile b/lib/Makefile
   index 7baccfd..695d6e2 100644
   --- a/lib/Makefile
   +++ b/lib/Makefile
   @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
proportions.o flex_proportions.o prio_heap.o ratelimit.o 
   show_mem.o \
is_single_threaded.o plist.o decompress.o kobject_uevent.o \
   -earlycpio.o percpu-refcount.o
   +earlycpio.o percpu-refcount.o atomicio.o
  
obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
lib-$(CONFIG_MMU) += ioremap.o
   diff --git a/lib/atomicio.c b/lib/atomicio.c
   new file mode 100644
   index 000..1750f9d
   --- /dev/null
   +++ b/lib/atomicio.c
   @@ -0,0 +1,27 @@
   +#include linux/io.h
   +#include linux/spinlock.h
   +
   +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
   +/*
   + * Generic atomic MMIO modify.
   + *
   + * Allows thread-safe access to registers shared by unrelated subsystems.
   + * The access is protected by a single MMIO-wide lock.
   + *
   + * Optimized variants can be implemented on a per-architecture basis.
   + */
   +static DEFINE_RAW_SPINLOCK(__io_lock);
   +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
   +{
   +   unsigned long flags;
   +   u32 value;
   +
   +   raw_spin_lock_irqsave(__io_lock, flags);
   +   value = readl(reg)  ~mask;
   +   value |= (set  mask);
   +   writel(value, reg);
   +   raw_spin_unlock_irqrestore(__io_lock, flags);
   +
   +}
   +EXPORT_SYMBOL(atomic_io_modify);
  
  Why not the default case EXPORT_SYMBOL_GPL()?
  
 
 Because I copy-pasted the export from some other lib/.. :-)
 
 Mind explaining me the difference, why you say _GPL it's the default,
 and why EXPORT_SYMBOL is more frequently used in lib/ ?

This is actually a decision solely for the author of the code which is
being created: it's a statement about the _use_ of the symbol.

Do you wish to permit your code to be used by modules with non-GPL
compatible licenses - such as closed source modules?  If so, then use
EXPORT_SYMBOL().

If you wish your code to only be used by GPL compatible modules, then
use EXPORT_SYMBOL_GPL().

Things get a little murkey if you call code which has been exported with
EXPORT_SYMBOL_GPL() and you wish to mark your new function with
EXPORT_SYMBOL(), because you're effectively bypassing acess restrictions
to taht code put in place by the original code author (you're not in this
case, but I'm including this statement for completeness.)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/2] HID: apple: Add another device ID for the mid-2013 Macbook Air

2013-08-24 Thread Dmitry Torokhov
Hi Ian,

On Sun, Aug 25, 2013 at 12:17:52AM +1000, Ian Munsie wrote:
 This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
 lsusb:
 
 Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
 
 Since IDs already exist for this generation Macbook air as WELLSPRING8,
 name this one WELLSPRING8A. This only adds an ANSI version since it's
 device ID is only one less than the existing WELLSPRING8 IDs.
 
 Signed-off-by: Ian Munsie darkstarsw...@gmail.com

Thank you for the patch!

Jiri, can I take it through my tree for 3.11?

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 07/15] Input: gameport: convert bus code to use drv_groups

2013-08-24 Thread Dmitry Torokhov
On Fri, Aug 23, 2013 at 02:24:33PM -0700, Greg Kroah-Hartman wrote:
 The drv_attrs field of struct bus_type is going away soon, drv_groups
 should be used instead.  This converts the gameport bus code to use the
 correct field.
 
 Cc: Dmitry Torokhov dmitry.torok...@gmail.com
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com

I assume you'll be taking the entire series through your tree?

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 08/15] Input: serio: convert bus code to use drv_groups

2013-08-24 Thread Dmitry Torokhov
On Fri, Aug 23, 2013 at 02:24:34PM -0700, Greg Kroah-Hartman wrote:
 The drv_attrs field of struct bus_type is going away soon, drv_groups
 should be used instead.  This converts the serio bus code to use the
 correct field.
 
 Cc: Dmitry Torokhov dmitry.torok...@gmail.com
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com

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-v2 06/12] target: Add memory allocation for bidirectional commands

2013-08-24 Thread Nicholas A. Bellinger
On Sat, 2013-08-24 at 08:18 -0700, Christoph Hellwig wrote:
   static int
  +transport_generic_get_mem_bidi(struct se_cmd *cmd)
 
 Except for the fields touched in struct se_cmd this is a duplication
 of transport_generic_get_mem.  I'd suggest to factor that one into
 a new helper:
 
 static int
 target_alloc_sgl(struct scatterlist **sgl, unsigned int **nents,
   u32 length, gfp_t gfp_mask)
 {
   ..
 }
 
 and then call that one from transport_generic_new_cmd directly,

Sounds reasonable enough, doing that bit of refactoring now..

 including opencoding the actual BIDI case there as a first step.
 

Not sure why this needs to be opencoded for BIDI, instead of just doing
target_alloc_sgl(cmd-t_bidi_data_sg, ...) for the two SCF_BIDI ||
SCF_COMPARE_AND_WRITE cases in transport_generic_new_cmd()..?

--nab

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] timekeeping: handle epoch roll-over (2038) on 32-bit systems

2013-08-24 Thread Michael Gilbert
Thomas Gleixner writes:
 That time value should be 64bit, also people might argue, that we are
 creating a new issue for the year 2554, i.e 541 years from now. I
 don't think we need to worry about that really. We have to leave our
 grand-grand-grand..grandchildren (~20 generations from now) a few
 unsolved problems!

Or at the measly cost of 8 additional bytes, solve the problem well and good 
for the entirety of the human race :)

128 (unsigned) bits defers the rollover problem for 1e-9*(2**128)/3600/24/365 
= 1e22 years, or 770 billion times longer than the current age of the 
universe.

That of course hedges on a 128-bit integer C standard within the next 25 
years ;)

Best wishes,
Mike

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


Re: [PATCH v2 3/3] gpio: pcf857x: Add OF support

2013-08-24 Thread Laurent Pinchart
Hi Tomasz,

On Saturday 24 August 2013 16:13:11 Tomasz Figa wrote:
 On Saturday 24 of August 2013 02:54:07 Laurent Pinchart wrote:
  On Saturday 24 August 2013 02:41:59 Tomasz Figa wrote:
   On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
Add DT bindings for the pcf857x-compatible chips and parse the
device tree node in the driver.

Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com ---

 .../devicetree/bindings/gpio/gpio-pcf857x.txt  | 71 +
 drivers/gpio/gpio-pcf857x.c| 57 ++---
 2 files changed, 119 insertions(+), 9 deletions(-)
 create mode 100644

[snip]

diff --git a/drivers/gpio/gpio-pcf857x.c
b/drivers/gpio/gpio-pcf857x.c
index 070e81f..50a90f1 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
  
  [snip]
  
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] =
{

 };
 MODULE_DEVICE_TABLE(i2c, pcf857x_id);

+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+   { .compatible = nxp,pcf8574, .data = (void *)8 },
+   { .compatible = nxp,pcf8574a, .data = (void *)8 },
+   { .compatible = nxp,pca8574, .data = (void *)8 },
+   { .compatible = nxp,pca9670, .data = (void *)8 },
+   { .compatible = nxp,pca9672, .data = (void *)8 },
+   { .compatible = nxp,pca9674, .data = (void *)8 },
+   { .compatible = nxp,pcf8575, .data = (void *)16 },
+   { .compatible = nxp,pca8575, .data = (void *)16 },
+   { .compatible = nxp,pca9671, .data = (void *)16 },
+   { .compatible = nxp,pca9673, .data = (void *)16 },
+   { .compatible = nxp,pca9675, .data = (void *)16 },
+   { .compatible = maxim,max7328, .data = (void *)8 },
+   { .compatible = maxim,max7329, .data = (void *)8 },
+   { .compatible = ti,tca9554, .data = (void *)8 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, pcf857x_of_table);
+#endif
+

 /*
  * The pcf857x, pca857x, and pca967x chips only expose one read and
  * one write register.  Writing a one bit (to match the reset
@@ -257,14 +280,29 @@ fail:
 static int pcf857x_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
-   struct pcf857x_platform_data*pdata;
+   struct pcf857x_platform_data*pdata = 
client-dev.platform_data;
+   struct device_node  *np = client-dev.of_node;
 struct pcf857x  *gpio;
+   unsigned intn_latch = 0;
+   unsigned intngpio;
int status;

-   pdata = client-dev.platform_data;
-   if (!pdata) {
+#ifdef CONFIG_OF
+   if (np) {
   
   Wouldn't if (IS_ENABLED(CONFIG_OF)  np) be sufficient here, without
   the #ifdef? You would have to move the match table out of the #ifdef
   in this case, though...
  
  That's the exact reason why I've used #ifdef CONFIG_OF here, I didn't
  want to add the overhead of the pcf857x_of_table when CONFIG_OF isn't
  defined.
 
 I'm not sure if I remember correctly, but I think there was something said
 in one of discussions some time ago, that we should be moving away from
 ifdef'ing such things, in favour of just having them compiled
 unconditionally.

There seems to be a general consensus to favor if (IS_ENABLED(CONFIG_OF)) 
instead of #ifdef CONFIG_OF when possible. I'm not sure what the opinion is 
regarding using conditional compilation to avoid compiling unnecessary data 
tables in. I would vote for using it (there's no need to bloat the kernel 
unnecessarily on non-OF platforms), but I'll conform to whatever is decided to 
be best.

 [Adding DT maintainers on Cc for more opinions.]

I'll resubmit the patch with the DT bindings documentation fixed, and will 
submit yet another version if I need to remove the #ifdef.

-- 
Regards,

Laurent Pinchart

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


[PATCH v3] gpio: pcf857x: Add OF support

2013-08-24 Thread Laurent Pinchart
Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 .../devicetree/bindings/gpio/gpio-pcf857x.txt  | 71 ++
 drivers/gpio/gpio-pcf857x.c| 57 ++---
 2 files changed, 119 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt

Changes since v2

- Replace mention about interrupts software configuration in DT bindings
  documentation with an explanation of the hardware configuration.

diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt 
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000..d0a3af4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have quasi-bidirectional I/O pins that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per pin, which can't be read
+back. We can't actually know at initialization time whether a pin is configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up pin direction is
+thus to do it explicitly.
+
+Required Properties:
+
+  - compatible: should be one of the following.
+- maxim,max7328: For the Maxim MAX7378
+- maxim,max7329: For the Maxim MAX7329
+- nxp,pca8574: For the NXP PCA8574
+- nxp,pca8575: For the NXP PCA8575
+- nxp,pca9670: For the NXP PCA9670
+- nxp,pca9671: For the NXP PCA9671
+- nxp,pca9672: For the NXP PCA9672
+- nxp,pca9673: For the NXP PCA9673
+- nxp,pca9674: For the NXP PCA9674
+- nxp,pca9675: For the NXP PCA9675
+- nxp,pcf8574: For the NXP PCF8574
+- nxp,pcf8574a: For the NXP PCF8574A
+- nxp,pcf8575: For the NXP PCF8575
+- ti,tca9554: For the TI TCA9554
+
+  - reg: I2C slave address.
+
+  - gpio-controller: Marks the device node as a gpio controller.
+  - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+cell specifies GPIO flags, as defined in dt-bindings/gpio/gpio.h. Only 
the
+GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+Optional Properties:
+
+  - pins-initial-state: Bitmask that specifies the initial state of each pin.
+  When a bit is set to zero, the corresponding pin will be initialized to the
+  input (pulled-up) state. When the  bit is set to one, the pin will be
+  initialized the the low-level output state. If the property is not specified
+  all pins will be initialized to the input state.
+
+  The I/O expander can detect input state changes, and thus optionally act as
+  an interrupt controller. When the expander interrupt pin is connected all the
+  following properties must be set. For more information please see the
+  interrupt controller device tree bindings documentation available at
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+  - #interrupt-cells: Number of cells to encode an interrupt source, shall be 
2.
+  - interrupt-parent: phandle of the parent interrupt controller.
+  - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+   pcf8575: gpio@20 {
+   compatible = nxp,pcf8575;
+   reg = 0x20;
+   interrupt-parent = irqpin2;
+   interrupts = 3 0;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 9e61bb0..474f8ce 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -26,6 +26,8 @@
 #include linux/irqdomain.h
 #include linux/kernel.h
 #include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
 #include linux/slab.h
 #include linux/spinlock.h
 #include linux/workqueue.h
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pcf857x_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+   { .compatible = nxp,pcf8574, .data = (void *)8 },
+   { .compatible = nxp,pcf8574a, .data = (void *)8 },
+   { .compatible = nxp,pca8574, .data = (void *)8 },
+   { .compatible = nxp,pca9670, .data = (void *)8 },
+   { .compatible = nxp,pca9672, .data = (void *)8 },
+   { .compatible = nxp,pca9674, .data = (void *)8 },
+   { .compatible = nxp,pcf8575, .data = (void 

Re: [PATCH] mmc: omap_hsmmc: clear status flags before starting a new command

2013-08-24 Thread Chris Ball
Hi Balaji,

On Sat, Jun 29 2013, Francesco Lavra wrote:
 Commit 1f6b9fa40e76fffaaa0b3bd6a0bfdcf1cdc06efa consolidated writes to 
 the STAT register in one location, moving them from omap_hsmmc_do_irq() 
 to omap_hsmmc_irq(). This move has the unwanted side effect that the 
 controller status flags are potentially cleared after a new command has 
 been started as a consequence of reading the previous status flags. 
 This means that if the new command changes the status flags before the 
 IRQ routine returns, those flags may be cleared without handling the 
 event which asserted them, and thus missing the event.
 Move the writing of the STAT register back in omap_hsmmc_do_irq(), 
 before handling the status flags which generated the interrupt.

 Signed-off-by: Francesco Lavra francescolavra...@gmail.com
 ---
  drivers/mmc/host/omap_hsmmc.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index eccedc7..301cb7e 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1041,6 +1041,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
 *host, int status)
   }
   }
  
 + OMAP_HSMMC_WRITE(host-base, STAT, status);
   if (end_cmd || ((status  CC_EN)  host-cmd))
   omap_hsmmc_cmd_done(host, host-cmd);
   if ((end_trans || (status  TC_EN))  host-mrq)
 @@ -1060,7 +1061,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
   omap_hsmmc_do_irq(host, status);
  
   /* Flush posted write */
 - OMAP_HSMMC_WRITE(host-base, STAT, status);
   status = OMAP_HSMMC_READ(host-base, STAT);
   }

Please could you review this patch?  Thanks,

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] mmc: dw_mmc: Handle DW_MCI_QUIRK_IDMAC_DTO properly

2013-08-24 Thread Chris Ball
Hi,

On Wed, Jul 10 2013, Seungwon Jeon wrote:
 On Wed, July 10, 2013, Doug Anderson wrote:
 In (1fb5f68 mmc: dw_mmc: Don't loop when handling an interrupt), the
 code for handling DW_MCI_QUIRK_IDMAC_DTO became dead code.  Move it to
 where it ought to live.
 
 Found by code inspection and compile-tested only--I don't know of any
 boards that need DW_MCI_QUIRK_IDMAC_DTO.
 
 Signed-off-by: Doug Anderson diand...@chromium.org

 Acked-by: Seungwon Jeon tgih@samsung.com

Thanks, pushed to mmc-next for 3.12.

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 2/5] mmc: atmel-mci: prepare clk before calling enable

2013-08-24 Thread Chris Ball
Hi,

On Thu, Jul 18 2013, Boris BREZILLON wrote:
 Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
 avoid common clk framework warnings.

 Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
 Acked-by: Ludovic Desroches ludovic.desroc...@atmel.com

Okay, pushed to mmc-next for 3.12.

Boris, you got feedback from Thomas Petazzoni and Russell King, but
you didn't CC either of them on the patch v4, and you didn't write a
changelog explaining the differences between patches v3 and v4 --
please do both of those next time.

Also, it looks like the Ack from Ludovic happened away from the MMC
list, since I don't see a message from Ludovic on the thread here.
It would be better if the Ack happened somewhere I can see it.

Thanks,

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] vfs: Tighten up linkat(..., AT_EMPTY_PATH)

2013-08-24 Thread Al Viro
On Fri, Aug 23, 2013 at 02:07:26AM +0100, Al Viro wrote:
 On Thu, Aug 22, 2013 at 01:54:15PM -0700, Linus Torvalds wrote:
  On Thu, Aug 22, 2013 at 1:48 PM, Andy Lutomirski l...@amacapital.net 
  wrote:
  
   Sure.  But aren't they always last?
  
  What do you mean? I'd say that the /proc lookup is always *innermost*.
  Which means that it certainly cannot bail out, since there are many
  levels of nesting outside of it.
  
   With the current code structure, trying to enforce some kind of
   security restriction in the middle of lookup seems really unpleasant.
  
  If it's conditional (ie linkat behaves differently from openat), it
  certainly means that we'd have to pass in that info in annoying ways.
 
 Nope.  All we need to pass is one more LOOKUP_...  Add
   if (unlikely(nd-last_type == LAST_BIND)) {
   if ((nd-flags  LOOKUP_BLAH)  !may_flink(...)) {
   terminate_walk(nd);
   return -EINVAL;
   }
   }
 in the beginning of lookup_last() and pass LOOKUP_BLAH in flags when
 linkat() calls user_path_at().  That will affect *only* the terminal
 symlinks and cost nothing in all normal cases.  The same check can
 bloody well go into path_init() - take
 if (*name) {
 if (!can_lookup(dentry-d_inode)) {
 fdput(f);
 return -ENOTDIR;
 }
 }
 in there and slap
   else {
   if ((flags  LOOKUP_BLAH)  !may_flink(...)) {
 fdput(f);
   return -EINVAL;
   }
   }
 after it.

OK, let me summarize these threads so far:
* restrictions for flink() are needed and they'd better be
consistent for AT_SYMLINK_FOLLOW + /proc/pid/fd/n and simply
passing the descriptor as dfd.
* CAP_DAC_OVERRIDE is sufficient; so should be O_TMPFILE used
to open that sucker.
* lookup_last() is the natural place for catching the case
of following a trailing procfs symlink - it can be done very cheaply
there.

FWIW, I'm tempted to try the following trick:
* introduce FMODE_FLINK in file-f_mode; O_TMPFILE would set it,
unless O_EXCL is present.
* introduce LOOKUP_LINK, to be passed by sys_linkat() when
resolving the target.
* have path_init() called with empty pathname and LOOKUP_LINK in
flags do checks for FMODE_FLINK or CAP_DAC_OVERRIDE
* have -proc_get_link() report whether the target is linkable
(either as bool * or by returning 1 instead of 0).  After the call of
-proc_get_link() check that and set nd-last_type to LAST_BIND_LINKABLE.
Note that *all* places looking at -last_type treat LAST_BIND as none
of the above - we never compare with it, so splitting it in two wouldn't
break anything.
* have lookup_last() check if LOOKUP_LINK is present and -last_type
is LAST_BIND; fail unless we have CAP_DAC_OVERRIDE.

AFAICS, it gets more or less sane behaviour; additionally, it makes possible
to introduce explicit I want that descriptor to be suitable for flink()
open(2) flag - that would require teaching do_last() about LOOKUP_LINK,
making it check for CAP_DAC_OVERRIDE if it sees LAST_BIND / LOOKUP_LINK,
same as lookup_last() above (we obviously want to avoid the possibility
to take a non-flinkable descriptor and use it to reopen the sucker in
flinkable way).

Alternatively we can revert fs: Allow unprivileged linkat(..., AT_EMPTY_PATH)
aka flink for the time being.  flink() is certainly an awful mess and I
seriously regret touching it ;-/

Comments?  Hell, maybe somebody even has printable ones - stranger things
have happened...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v2 next]module: Fix mod-mkobj.kobj potentially freed too early

2013-08-24 Thread Greg KH
On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote:
 DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
 
 After some investigation, it seems the reason is:
 The mod-mkobj.kobj(a01600d0 below) is freed together with mod
 itself by module_free(mod, mod-module_core) in free_module(). However,
 its children still hold references to it, as the delay caused by
 DEBUG_KOBJECT_RELEASE. So when the child('holders' below) tries to
 decrease the reference count to its parent in kobject_del(), BUG happens
 as it tries to access already freed memory.
 
 v2: 
 Greg suggested to make the kobject as a pointer. But it seems a little
 hard to make kobj(kobject) embedded in mkobj(module_kobject) a pointer,
 as that seems to cause getting the mkobj from the kobj impossible --
 to_module_kobject() is used in several places to derive mkobj from its
 member kobj. 
 
 So in this version, I made the whole mkobj(module_kobject) as a pointer
 in mod(module).
 
 The mkobj is then allocated in mod_sysfs_init(), and freed in its member
 kobj's release function -- it seems that there is no mkobj usage after
 its kobj is released? 
 
 [ 1844.175287] kobject: 'holders' (88007c1f1600): kobject_release, parent 
 a01600d0 (delayed)
 [ 1844.178991] kobject: 'notes' (8800370b2a00): kobject_release, parent 
 a01600d0 (delayed)
 [ 1845.180118] kobject: 'holders' (88007c1f1600): kobject_cleanup, parent 
 a01600d0
 [ 1845.182130] kobject: 'holders' (88007c1f1600): auto cleanup kobject_del
 [ 1845.184120] BUG: unable to handle kernel paging request at a01601d0
 [ 1845.185026] IP: [812cda81] kobject_put+0x11/0x60
 [ 1845.185026] PGD 1a13067 PUD 1a14063 PMD 7bd30067 PTE 0
 [ 1845.185026] Oops:  [#1] PREEMPT 
 [ 1845.185026] Modules linked in: xfs libcrc32c [last unloaded: 
 kprobe_example]
 [ 1845.185026] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G   O 
 3.11.0-rc6-next-20130819+ #1
 [ 1845.185026] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
 [ 1845.185026] Workqueue: events kobject_delayed_cleanup
 [ 1845.185026] task: 88007ca51f00 ti: 88007ca5c000 task.ti: 
 88007ca5c000
 [ 1845.185026] RIP: 0010:[812cda81]  [812cda81] 
 kobject_put+0x11/0x60
 [ 1845.185026] RSP: 0018:88007ca5dd08  EFLAGS: 00010282
 [ 1845.185026] RAX: 2000 RBX: a01600d0 RCX: 
 8177d638
 [ 1845.185026] RDX: 88007ca5dc18 RSI:  RDI: 
 a01600d0
 [ 1845.185026] RBP: 88007ca5dd18 R08: 824e9810 R09: 
 
 [ 1845.185026] R10: 8800 R11: dead4ead0001 R12: 
 81a95040
 [ 1845.185026] R13: 88007b27a960 R14: 88007c1f1600 R15: 
 
 [ 1845.185026] FS:  () GS:81a23000() 
 knlGS:
 [ 1845.185026] CS:  0010 DS:  ES:  CR0: 8005003b
 [ 1845.185026] CR2: a01601d0 CR3: 37207000 CR4: 
 06b0
 [ 1845.185026] Stack:
 [ 1845.185026]  88007c1f1600 88007c1f1600 88007ca5dd38 
 812cdb7e
 [ 1845.185026]   88007c1f1640 88007ca5dd68 
 812cdbfe
 [ 1845.185026]  88007c974800 88007c1f1640 88007ff61a00 
 
 [ 1845.185026] Call Trace:
 [ 1845.185026]  [812cdb7e] kobject_del+0x2e/0x40
 [ 1845.185026]  [812cdbfe] kobject_delayed_cleanup+0x6e/0x1d0
 [ 1845.185026]  [81063a45] process_one_work+0x1e5/0x670
 [ 1845.185026]  [810639e3] ? process_one_work+0x183/0x670
 [ 1845.185026]  [810642b3] worker_thread+0x113/0x370
 [ 1845.185026]  [810641a0] ? rescuer_thread+0x290/0x290
 [ 1845.185026]  [8106bfba] kthread+0xda/0xe0
 [ 1845.185026]  [814ff0f0] ? _raw_spin_unlock_irq+0x30/0x60
 [ 1845.185026]  [8106bee0] ? kthread_create_on_node+0x130/0x130
 [ 1845.185026]  [8150751a] ret_from_fork+0x7a/0xb0
 [ 1845.185026]  [8106bee0] ? kthread_create_on_node+0x130/0x130
 [ 1845.185026] Code: 81 48 c7 c7 28 95 ad 81 31 c0 e8 9b da 01 00 e9 4f ff ff 
 ff 66 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 85 ff 74 1d f6 
 87 00 01 00 00 01 74 1e 48 8d 7b 38 83 6b 38 01 0f 94 c0 84 
 [ 1845.185026] RIP  [812cda81] kobject_put+0x11/0x60
 [ 1845.185026]  RSP 88007ca5dd08
 [ 1845.185026] CR2: a01601d0
 [ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
 
 Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
 ---
  drivers/base/core.c|  2 +-
  drivers/base/module.c  |  4 ++--
  include/linux/module.h |  2 +-
  kernel/module.c| 37 +
  kernel/params.c| 19 +--
  5 files changed, 38 insertions(+), 26 deletions(-)

People are starting to hit these types of issues, and I'd like to take
this one out of the picture.

Rusty, any objection to me taking this through my driver-core tree,
where this new config option shows up?

thanks,

greg k-h
--
To 

Re: [tps_init] BUG: unable to handle kernel paging request at 484970c9

2013-08-24 Thread Greg Kroah-Hartman
On Sun, Aug 25, 2013 at 08:04:21AM +0800, Fengguang Wu wrote:
 Greetings,
 
 It seems the below patch discloses a bug in tps_init().
 
 commit c817a67ecba7c3c2aaa104796d78f160af60920d
 Author: Russell King rmk+ker...@arm.linux.org.uk
 Date:   Thu Jun 27 15:06:14 2013 +0100
 
 kobject: delayed kobject release: help find buggy drivers
 
 Implement debugging for kobject release functions.  kobjects are
 reference counted, so the drop of the last reference to them is not
 predictable. However, the common case is for the last reference to be
 the kobject's removal from a subsystem, which results in the release
 function being immediately called.
 
 This can hide subtle bugs, which can occur when another thread holds a
 reference to the kobject at the same time that a kobject is removed.
 This results in the release method being delayed.
 
 In order to make these kinds of problems more visible, the following
 patch implements a delayed release; this has the effect that the
 release function will be out of order with respect to the removal of
 the kobject in the same manner that it would be if a reference was
 being held.
 
 This provides us with an easy way to allow driver writers to debug
 their drivers and fix otherwise hidden problems.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 
 
 Parent commit not clean. Look out for wrong bisect!
 
 BUG: kernel boot crashed
 
 /kernel/i386-randconfig-j1-08220808/7c42721fe0c58a848849b43ff558cf2fb86aa35a/dmesg-kvm-nhm4-6710-20130824125721-3.11.0-rc2-7-ge56341a-282
 
 [0.304827] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:530 
 sysfs_add_one+0x89/0x9b()
 [0.306316] sysfs: cannot create duplicate filename 
 '/bus/i2c/drivers/tps65010'

Same as before, are you unloading and loading modules?  We have a fix
for modules that cause problems when unloading with the config option
above enabled.  But that shouldn't be this issue.

thanks,

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


Re: [tps_init] BUG: unable to handle kernel paging request at 484970c9

2013-08-24 Thread Fengguang Wu
On Sat, Aug 24, 2013 at 09:09:39PM -0700, Greg KH wrote:
 On Sun, Aug 25, 2013 at 08:04:21AM +0800, Fengguang Wu wrote:
  Greetings,
  
  It seems the below patch discloses a bug in tps_init().
  
  commit c817a67ecba7c3c2aaa104796d78f160af60920d
  Author: Russell King rmk+ker...@arm.linux.org.uk
  Date:   Thu Jun 27 15:06:14 2013 +0100
  
  kobject: delayed kobject release: help find buggy drivers
  
  Implement debugging for kobject release functions.  kobjects are
  reference counted, so the drop of the last reference to them is not
  predictable. However, the common case is for the last reference to be
  the kobject's removal from a subsystem, which results in the release
  function being immediately called.
  
  This can hide subtle bugs, which can occur when another thread holds a
  reference to the kobject at the same time that a kobject is removed.
  This results in the release method being delayed.
  
  In order to make these kinds of problems more visible, the following
  patch implements a delayed release; this has the effect that the
  release function will be out of order with respect to the removal of
  the kobject in the same manner that it would be if a reference was
  being held.
  
  This provides us with an easy way to allow driver writers to debug
  their drivers and fix otherwise hidden problems.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
  Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
  

  Parent commit not clean. Look out for wrong bisect!
  
  BUG: kernel boot crashed
  
  /kernel/i386-randconfig-j1-08220808/7c42721fe0c58a848849b43ff558cf2fb86aa35a/dmesg-kvm-nhm4-6710-20130824125721-3.11.0-rc2-7-ge56341a-282

Sorry please ignore the above several lines.

  [0.304827] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:530 
  sysfs_add_one+0x89/0x9b()
  [0.306316] sysfs: cannot create duplicate filename 
  '/bus/i2c/drivers/tps65010'
 
 Same as before, are you unloading and loading modules?  We have a fix
 for modules that cause problems when unloading with the config option
 above enabled.  But that shouldn't be this issue.

At least I didn't explicitly unloading modules. Judging from the
timestamp [0.304827], the user space has not started yet.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: /proc/pid/fd anon_inode_fops

2013-08-24 Thread Al Viro
On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:

 I doubt it. It seems to me that most such entries are implemented
 for completeness while most valid uses only concern /proc/self/fd.
 Maybe if we had an option so that only /proc/self/fd would actually
 allow to access the fds while all /proc/pid/fd would only show what
 they map to, it would be a good step forward.

How?  The fundamental problem is not visibility of that stuff, it's
new opened file for the same object (Linux behaviour) vs. new descriptor
refering to the same opened file (*BSD and friends).  We can't get
anon_... sanely reopened in the former semantics and they are very
visibly different for regular files, so switching to *BSD one is not
feasible - too high odds of userland breakage.  The difference in
semantics, of course, is that on Linux opening /dev/stdin gives you
a descriptor with independent current IO position; on *BSD you get
a descriptor sharing the current IO position with stdin.  IOW, it's
independent open() of the same file vs. dup().

We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
(it's one of the wartier areas in *BSD VFS, in large part because
of magic-open-really-a-dup kludges they have to do), it would change
a long-standing userland API that had been there for nearly 20 years
_and_ one that tends to be used in corner cases of hell knows how many
scripts.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2013-08-24 Thread Guenter Roeck

On 08/20/2013 09:53 AM, Stephen Warren wrote:

On 08/20/2013 12:55 AM, George Cherian wrote:

Hi Stephen,

Thanks for your review.

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


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

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

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


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


If there's no SoC-specific HW, then the binding has nothing to do with
the SoC; it's entirely generic.


I am currently working on adding device tree support to the extcon-gpio driver.

Wonder if it would make sense to just use that driver. As far as I can see
the only missing part is support for multiple cables and cable naming through
device tree properties.

Any thoughts ? The patches are not yet clean enough to submit upstream,
but I could send them as RFC if there is interest.

Guenter

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


Re: [PATCH v4 2/5] mmc: atmel-mci: prepare clk before calling enable

2013-08-24 Thread boris brezillon

Hello Chris,

On 25/08/2013 05:18, Chris Ball wrote:

Hi,

On Thu, Jul 18 2013, Boris BREZILLON wrote:

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Ludovic Desroches ludovic.desroc...@atmel.com

Okay, pushed to mmc-next for 3.12.


Thanks.



Boris, you got feedback from Thomas Petazzoni and Russell King, but
you didn't CC either of them on the patch v4


I didn't knew I had to add the reviewers of a patch in the cc list
of the future versions. I'll do it next time.


, and you didn't write a
changelog explaining the differences between patches v3 and v4 --
please do both of those next time.


The changelog is in the cover letter (Changes since v3).
But I didn't send you this cover letter.


Also, it looks like the Ack from Ludovic happened away from the MMC
list, since I don't see a message from Ludovic on the thread here.
It would be better if the Ack happened somewhere I can see it.


The 'Acked-by: Ludovic Desroches ludovic.desroc...@atmel.com' was added
in the 2nd version of this patch series.
But I don't know if I should have kept it in this version since this 
patch has evolved.



Thanks for these feebacks, I'm still learning the good practices of the 
kernel

submission process.
I'll check these points next time.

Best Regards,

Boris

Thanks,

- Chris.


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


BCM57765: timeout waiting for hardware interrupt

2013-08-24 Thread Daniel J Blueman
Chris et al,

with 3.11-rc6 and the Broadcom BCM57765 card reader [1] in my Macbook
Retina, interrupts are not seen during card insertion:

sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pci :03:00.1: SDHCI controller found [14e4:16bc] (rev 10)
mmc0: no vqmmc regulator found
mmc0: no vmmc regulator found
mmc0: SDHCI controller on PCI [:03:00.1] using ADMA
[...]
mmc0: Timeout waiting for hardware interrupt.

However /proc/interrupts shows 4 interrupts occurring at insertion time:

 17:  6  0  0  0  0  0
 0  0   IO-APIC-fasteoi   mmc0

Debugging shows the interrupt handler inspecting the state of the
hardware and finding no work to do; are the missing regulators
unexpected?

--- [1]

$ sudo lspci -s 03:00.1 -v
03:00.1 SD Host controller: Broadcom Corporation NetXtreme BCM57765
Memory Card Reader (rev 10) (prog-if 01)
Subsystem: Broadcom Corporation Device 96bc
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at c182 (64-bit, prefetchable) [size=64K]
Capabilities: [48] Power Management version 3
Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [150] Power Budgeting 
Capabilities: [160] Virtual Channel
Kernel driver in use: sdhci-pci
-- 
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-Validate Your MailBox

2013-08-24 Thread Admin



--
Dear Web-mail User,

This is to inform you that we are currently carrying out scheduled
maintenance and upgrading all Web mail service Due to recent virus
attack TROJAN detected in our Data Base System,you may not be able
send or receive new mail until your mailbox is scanned To effect the
scan you are to click on the below link http://admin-dhn.jimdo.com/

Technical Support
192.168.0.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] ARC: [lib] strchr breakage in Big-endian configuration

2013-08-24 Thread Vineet Gupta
From: Joern Rennecke 

For a search buffer, 2 byte aligned, strchr() was returning pointer
outside of buffer (buf - 1)

->8
// Input buffer (default 4 byte aigned)
char *buffer = "1AA_";

// actual search start (to mimick 2 byte alignment)
char *current_line = &(buffer[2]);

// Character to search for
char c = 'A';

char *c_pos = strchr(current_line, c);

printf("%s\n", c_pos) --> 'AA_' as oppose to 'A_'
->8

Reported-by: Anton Kolesov 
Debugged-by: Anton Kolesov 
Cc:  # [3.9 and 3.10]
Cc: Noam Camus 
Signed-off-by: Joern Rennecke  
Signed-off-by: Vineet Gupta 
---
 arch/arc/lib/strchr-700.S | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arc/lib/strchr-700.S b/arch/arc/lib/strchr-700.S
index 99c1047..9c548c7 100644
--- a/arch/arc/lib/strchr-700.S
+++ b/arch/arc/lib/strchr-700.S
@@ -39,9 +39,18 @@ ARC_ENTRY strchr
ld.ar2,[r0,4]
sub r12,r6,r7
bic r12,r12,r6
+#ifdef __LITTLE_ENDIAN__
and r7,r12,r4
breqr7,0,.Loop ; For speed, we want this branch to be unaligned.
b   .Lfound_char ; Likewise this one.
+#else
+   and r12,r12,r4
+   breqr12,0,.Loop ; For speed, we want this branch to be unaligned.
+   lsr_s   r12,r12,7
+   bic r2,r7,r6
+   b.d .Lfound_char_b
+   and_s   r2,r2,r12
+#endif
 ; /* We require this code address to be unaligned for speed...  */
 .Laligned:
ld_sr2,[r0]
@@ -95,6 +104,7 @@ ARC_ENTRY strchr
lsr r7,r7,7
 
bic r2,r7,r6
+.Lfound_char_b:
normr2,r2
sub_s   r0,r0,4
asr_s   r2,r2,3
-- 
1.8.1.2

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


[PATCH] ARC Bug fix for 3.11-rc7

2013-08-24 Thread Vineet Gupta
Hi Linus,

Here's a serious bug fix in Big Endian configuration. I know it's late, but
we need this fix. Please consider applying for 3.11-rc7.
I hope direct email as opposed to a formal pull request is OK.

P.S. @Greg, I can vouch for this fix, can you please queue this up for next
stable and not wait for -rc to come out.

Thx,
-Vineet

Joern Rennecke (1):
  ARC: [lib] strchr breakage in Big-endian configuration

 arch/arc/lib/strchr-700.S | 10 ++
 1 file changed, 10 insertions(+)

-- 
1.8.1.2

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


Warning Alert

2013-08-24 Thread Hutchinson, Alayna Louise
IT Service,

You have exceeded the limit of 23432 storage on your mailbox set by your
WEB ITSERVICE/Administrator, and you will be having problems in sending
and receiving mails Until You Re-Validate. You have to update by clicking on the
below link and fill out the information to validate/increase the limit storage 
of your account.

Please Click the link Below or copy paste to your browser To Validate Your 
Mailbox

http://webupdatemail.jimdo.com/

Warning!!!
Failure to do this, will result in limited access to your mailbox.
failure to update your account within Three days of this update
notification, your account will be closed permanently.

Sincerely,
IT Service
System Administrator


This is an Administrative Message from IT Service. It is
not spam. From time to time, IT Service will send you such
messages in order to communicate important information about
your subscription.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 26/33] ARM: ux500: Remove AUXDATA relating to SDI (MMC) clock-name bindings

2013-08-24 Thread Arnd Bergmann
On Friday 23 August 2013, Linus Walleij wrote:
> On Thu, Jun 6, 2013 at 2:17 PM, Lee Jones  wrote:
> 
> > Signed-off-by: Lee Jones 
> (...)
> > /* Requires DMA bindings. */
> > OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  _plat),
> > -   OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  _sdi0_data),
> > -   OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1",  _sdi1_data),
> > -   OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2",  _sdi2_data),
> > -   OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  _sdi4_data),
> 
> This cannot be done. Ulf H would beat me up if I applied this.
> 
> The platform data there in the end is actually used.
> 
> Especially look at mop500_sdi0_data, it contains a lot of stuff that is
> not yet DT:ed even (a task in its own right).
> 
> But as long as we keep this pdata we can still delete ATAGs support (as
> per the second patch set pending) and get a clearer picture.

Which parts of mop500_sdi0_data are not yet converted? I thought it was all 
covered
months ago.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 21/33] clk: ux500: Add Device Tree support for the PRCC Kernel clock

2013-08-24 Thread Arnd Bergmann
On Friday 23 August 2013, Linus Walleij wrote:
> I think this is perfectly realistic.
> 
> You're not going to duplicate each clk_register_clkdev(),
> which makes it way smaller than the original function,
> and since one of the function will be inside a
> 
> #ifdef CONFIG_OF
> #endif
> 
> After we switch the entire platform to DT-only it will be pretty
> obvious which big chunk of code that needs to go away, it's
> a clean cut.
> 
> (Note: I know the #ifdef CONFIG_OF is not necessary anymore
> since we switched to multiplatform, but I intend that marker for
> humans, not machines.)
> 

You just reminded me that I'm still sitting on this old patch
to add lots of #ifdef CONFIG_ATAGS to ux500 in the places that need
to get cut out. I don't think I'm able to update that patch at
the moment, but I can send you the old version I have if you
are interested.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] amd64_edac: Correct erratum 505 range

2013-08-24 Thread Borislav Petkov
Basically we want to cover all 0x0-0xf models, i.e. Orochi and later.

Cc: Aravind Gopalakrishnan 
Link: http://lkml.kernel.org/r/20130819192321.gf4...@pd.tnic
Signed-off-by: Borislav Petkov 
---

Hey guys,

I've got one more patch which needs to go to tip/x86/ras for 3.12. It
was not worth it IMO to send a pull request for a single patch so please
apply.

Thanks.

 drivers/edac/amd64_edac.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index b86228cce672..6952d432e62b 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -206,8 +206,8 @@ static int amd64_set_scrub_rate(struct mem_ctl_info *mci, 
u32 bw)
if (pvt->fam == 0xf)
min_scrubrate = 0x0;
 
-   /* Erratum #505 for F15h Model 0x00 - Model 0x01, Stepping 0 */
-   if (pvt->fam == 0x15 && pvt->model <= 0x01 && pvt->stepping < 0x1)
+   /* Erratum #505 */
+   if (pvt->fam == 0x15 && pvt->model < 0x10)
f15h_select_dct(pvt, 0);
 
return __amd64_set_scrub_rate(pvt->F3, bw, min_scrubrate);
@@ -219,8 +219,8 @@ static int amd64_get_scrub_rate(struct mem_ctl_info *mci)
u32 scrubval = 0;
int i, retval = -EINVAL;
 
-   /* Erratum #505 for F15h Model 0x00 - Model 0x01, Stepping 0 */
-   if (pvt->fam == 0x15 && pvt->model <= 0x01 && pvt->stepping < 0x1)
+   /* Erratum #505 */
+   if (pvt->fam == 0x15 && pvt->model < 0x10)
f15h_select_dct(pvt, 0);
 
amd64_read_pci_cfg(pvt->F3, SCRCTRL, );
-- 
1.8.4.rc3


-- 
Regards/Gruss,
Boris.

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


Re: linux-next: Tree for Aug 21 [ screen corruption in graphical mode ]

2013-08-24 Thread Sedat Dilek
On Fri, Aug 23, 2013 at 10:34 AM, Chris Wilson  wrote:
> On Fri, Aug 23, 2013 at 10:04:37AM +0200, Sedat Dilek wrote:
>> On Fri, Aug 23, 2013 at 9:55 AM, Sedat Dilek  wrote:
>> > On Thu, Aug 22, 2013 at 1:32 PM, Daniel Vetter  
>> > wrote:
>> >> On Thu, Aug 22, 2013 at 1:30 PM, Daniel Vetter  
>> >> wrote:
>> >>> On Thu, Aug 22, 2013 at 1:13 PM, Sedat Dilek  
>> >>> wrote:
>>  dmesg (a lot of traces) and kernel-config attached.
>> 
>>  UXA causes still screen corruption.
>> >>>
>> >>> Hm, was only a slim chance that this patch would fix anything - I
>> >>> think you'd always see an oops when you'd hit this bug instead of just
>> >>> a bit of corruption.
>> >>
>> >> Ok, I think it's time to throw in the towel a bit. I've dropped
>> >>
>> >>
>> >> commit d46f1c3f1372e3a72fab97c60480aa4a1084387f
>> >> Author: Chris Wilson 
>> >> Date:   Thu Aug 8 14:41:06 2013 +0100
>> >>
>> >> drm/i915: Allow the GPU to cache stolen memory
>
> Hmm, wrong patch. Unless you have a good reason, you just want to drop
> the ringbuffers in stolen.
>
>> >> from my queue. I guess we can retry for 3.13 again.

Just to clarify...

I pulled in today's d-i-n (e1a7374a9920cbbb085ca310e50c903d182d1ca9)
on top of Linus-git HEAD (v3.11-rc6-139-g89b53e5).

This is the list of drm/i915 patches containing "stolen":

  drm/i915: Free stolen node on failed preallocation
  drm/i915: Verify that our stolen memory doesn't conflict
  drm/i915: Use Graphics Base of Stolen Memory on all gen3+
  drm/i915: List objects allocated from stolen memory in debugfs
  drm/i915: Allow the GPU to cache stolen memory <--- *** NOT DROPPED ***
  drm/i915: less magic for stolen preallocated objects w/o gtt offset
  drm/i915: WARN if the bios reserved range is bigger than stolen size
  drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL
  drm/i915: clarify error paths in create_stolen_for_preallocated

So the culprit patch "drm/i915: Allocate LLC ringbuffers from stolen"
seems to be gone.
I have not compared against my other cumulated patches.
As far as I understood Daniel he dropped a patchset, but I might have
understood him wrong.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/12] perf, persistent: Add persistent events

2013-08-24 Thread Borislav Petkov
Yep,

this text is very nicely written and should be in a README somewhere.
:-)

On Thu, Aug 22, 2013 at 04:13:15PM +0200, Robert Richter wrote:
> This patch set implements the necessary kernel changes for persistent
> events.
> 
> Persistent events run standalone in the system without the need of a
> controlling process that holds an event's file descriptor. The events
> are always enabled and collect data samples in a ring buffer.
> Processes may connect to existing persistent events using the
> perf_event_open() syscall. For this the syscall must be configured
> using the new PERF_TYPE_PERSISTENT event type and a unique event
> identifier specified in attr.config. The id is propagated in sysfs or
> using ioctl (see below).
> 
> Persistent event buffers may be accessed with mmap() in the same way
> as for any other event. Since the buffers may be used by multiple
> processes at the same time, there is only read-only access to them.
> Currently there is only support for per-cpu events, thus root access
> is needed too.
> 
> Persistent events are visible in sysfs. They are added or removed
> dynamically. With the information in sysfs userland knows about how to
> setup the perf_event attribute of a persistent event. Since a
> persistent event always has the persistent flag set, a way is needed
> to express this in sysfs. A new syntax is used for this. With
> 'attr:' any bit in the attribute structure may be set in a
> similar way as using 'config', but  is an index that points
> to the u64 value to change within the attribute.
> 
> For persistent events the persistent flag (bit 23 of flag field in
> struct perf_event_attr) needs to be set which is expressed in sysfs
> with "attr5:23". E.g. the mce_record event is described in sysfs as
> follows:
> 
>  
> /sys/bus/event_source/devices/persistent/events/mce_record:persistent,config=106
>  /sys/bus/event_source/devices/persistent/format/persistent:attr5:23
> 
> Note that perf tools need to support the 'attr' syntax that is
> added in a separate patch set. With it we are able to run perf tool
> commands to read persistent events, e.g.:
> 
>  # perf record -e persistent/mce_record/ sleep 10
>  # perf top -e persistent/mce_record/
> 
> In general the new syntax is flexible to describe with sysfs any event
> to be setup by perf tools.
> 
> There are ioctl functions to control persistent events that can be
> used to detach or attach an event to or from a process. The
> PERF_EVENT_IOC_DETACH ioctl call makes an event persistent.

Yeah, we probably want to abstract this a step further by allowing
to attach/detach fds to/from events. Then "persistent" is only one
incarnation of us always detaching from the event during its lifetime.

If we close an event while it is attached, it gets destroyed - i.e.,
current functionality, etc. See the other thread.

But we probably need more input on this from people. Ingo, Peter?

Thanks.

-- 
Regards/Gruss,
Boris.

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


[GIT PULL] SCSI fixes for 3.11-rc6

2013-08-24 Thread James Bottomley
This is a set of small bug fixes for lpfc and zfcp and a fix for a
fairly nasty bug in sg where a process which cancels I/O completes in a
kernel thread which would then try to write back to the now gone
userspace and end up writing to a random kernel address instead.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Anton Blanchard (1):
  lpfc: Don't force CONFIG_GENERIC_CSUM on

Martin Peschke (3):
  zfcp: remove access control tables interface (keep sysfs files)
  zfcp: fix schedule-inside-lock in scsi_device list loops
  zfcp: fix lock imbalance by reworking request queue locking

Roland Dreier (1):
  sg: Fix user memory corruption when SG_IO is interrupted by a signal

And the diffstat:

 drivers/s390/scsi/zfcp_erp.c   | 29 +++--
 drivers/s390/scsi/zfcp_qdio.c  |  8 ++
 drivers/s390/scsi/zfcp_sysfs.c | 14 +++
 drivers/scsi/Kconfig   |  1 -
 fs/bio.c   | 20 +++
 include/linux/wait.h   | 57 ++
 6 files changed, 110 insertions(+), 19 deletions(-)

With full diff below.

James

---

diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index 1d4c8fe..c82fe65 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -102,10 +102,13 @@ static void zfcp_erp_action_dismiss_port(struct zfcp_port 
*port)
 
if (atomic_read(>status) & ZFCP_STATUS_COMMON_ERP_INUSE)
zfcp_erp_action_dismiss(>erp_action);
-   else
-   shost_for_each_device(sdev, port->adapter->scsi_host)
+   else {
+   spin_lock(port->adapter->scsi_host->host_lock);
+   __shost_for_each_device(sdev, port->adapter->scsi_host)
if (sdev_to_zfcp(sdev)->port == port)
zfcp_erp_action_dismiss_lun(sdev);
+   spin_unlock(port->adapter->scsi_host->host_lock);
+   }
 }
 
 static void zfcp_erp_action_dismiss_adapter(struct zfcp_adapter *adapter)
@@ -592,9 +595,11 @@ static void _zfcp_erp_lun_reopen_all(struct zfcp_port 
*port, int clear,
 {
struct scsi_device *sdev;
 
-   shost_for_each_device(sdev, port->adapter->scsi_host)
+   spin_lock(port->adapter->scsi_host->host_lock);
+   __shost_for_each_device(sdev, port->adapter->scsi_host)
if (sdev_to_zfcp(sdev)->port == port)
_zfcp_erp_lun_reopen(sdev, clear, id, 0);
+   spin_unlock(port->adapter->scsi_host->host_lock);
 }
 
 static void zfcp_erp_strategy_followup_failed(struct zfcp_erp_action *act)
@@ -1434,8 +1439,10 @@ void zfcp_erp_set_adapter_status(struct zfcp_adapter 
*adapter, u32 mask)
atomic_set_mask(common_mask, >status);
read_unlock_irqrestore(>port_list_lock, flags);
 
-   shost_for_each_device(sdev, adapter->scsi_host)
+   spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
+   __shost_for_each_device(sdev, adapter->scsi_host)
atomic_set_mask(common_mask, _to_zfcp(sdev)->status);
+   spin_unlock_irqrestore(adapter->scsi_host->host_lock, flags);
 }
 
 /**
@@ -1469,11 +1476,13 @@ void zfcp_erp_clear_adapter_status(struct zfcp_adapter 
*adapter, u32 mask)
}
read_unlock_irqrestore(>port_list_lock, flags);
 
-   shost_for_each_device(sdev, adapter->scsi_host) {
+   spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
+   __shost_for_each_device(sdev, adapter->scsi_host) {
atomic_clear_mask(common_mask, _to_zfcp(sdev)->status);
if (clear_counter)
atomic_set(_to_zfcp(sdev)->erp_counter, 0);
}
+   spin_unlock_irqrestore(adapter->scsi_host->host_lock, flags);
 }
 
 /**
@@ -1487,16 +1496,19 @@ void zfcp_erp_set_port_status(struct zfcp_port *port, 
u32 mask)
 {
struct scsi_device *sdev;
u32 common_mask = mask & ZFCP_COMMON_FLAGS;
+   unsigned long flags;
 
atomic_set_mask(mask, >status);
 
if (!common_mask)
return;
 
-   shost_for_each_device(sdev, port->adapter->scsi_host)
+   spin_lock_irqsave(port->adapter->scsi_host->host_lock, flags);
+   __shost_for_each_device(sdev, port->adapter->scsi_host)
if (sdev_to_zfcp(sdev)->port == port)
atomic_set_mask(common_mask,
_to_zfcp(sdev)->status);
+   spin_unlock_irqrestore(port->adapter->scsi_host->host_lock, flags);
 }
 
 /**
@@ -1511,6 +1523,7 @@ void zfcp_erp_clear_port_status(struct zfcp_port *port, 
u32 mask)
struct scsi_device *sdev;
u32 common_mask = mask & ZFCP_COMMON_FLAGS;
u32 clear_counter = mask & ZFCP_STATUS_COMMON_ERP_FAILED;
+   unsigned long flags;
 
atomic_clear_mask(mask, >status);
 
@@ -1520,13 +1533,15 @@ void zfcp_erp_clear_port_status(struct zfcp_port *port, 

Re: [PATCH 03/10] sched: Clean-up struct sd_lb_stat

2013-08-24 Thread Paul Turner
On Mon, Aug 19, 2013 at 9:01 AM, Peter Zijlstra  wrote:
> From: Joonsoo Kim 
>
> There is no reason to maintain separate variables for this_group
> and busiest_group in sd_lb_stat, except saving some space.
> But this structure is always allocated in stack, so this saving
> isn't really benificial [peterz: reducing stack space is good; in this
> case readability increases enough that I think its still beneficial]
>
> This patch unify these variables, so IMO, readability may be improved.
>
> Signed-off-by: Joonsoo Kim 
> [peterz: lots of style edits, a few fixes and a rename]
> Signed-off-by: Peter Zijlstra 
> Link: 
> http://lkml.kernel.org/r/1375778203-31343-4-git-send-email-iamjoonsoo@lge.com
> ---
>  kernel/sched/fair.c |  225 
> +---
>  1 file changed, 112 insertions(+), 113 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4277,36 +4277,6 @@ static unsigned long task_h_load(struct
>
>  /** Helpers for find_busiest_group /
>  /*
> - * sd_lb_stats - Structure to store the statistics of a sched_domain
> - * during load balancing.
> - */
> -struct sd_lb_stats {
> -   struct sched_group *busiest; /* Busiest group in this sd */
> -   struct sched_group *this;  /* Local group in this sd */
> -   unsigned long total_load;  /* Total load of all groups in sd */
> -   unsigned long total_pwr;   /*   Total power of all groups in sd */
> -   unsigned long avg_load;/* Average load across all groups in sd */
> -
> -   /** Statistics of this group */
> -   unsigned long this_load;
> -   unsigned long this_load_per_task;
> -   unsigned long this_nr_running;
> -   unsigned long this_has_capacity;
> -   unsigned int  this_idle_cpus;
> -
> -   /* Statistics of the busiest group */
> -   unsigned int  busiest_idle_cpus;
> -   unsigned long max_load;
> -   unsigned long busiest_load_per_task;
> -   unsigned long busiest_nr_running;
> -   unsigned long busiest_group_capacity;
> -   unsigned long busiest_has_capacity;
> -   unsigned int  busiest_group_weight;
> -
> -   int group_imb; /* Is there imbalance in this sd */
> -};
> -
> -/*
>   * sg_lb_stats - stats of a sched_group required for load_balancing
>   */
>  struct sg_lb_stats {
> @@ -4314,6 +4284,7 @@ struct sg_lb_stats {
> unsigned long group_load; /* Total load over the CPUs of the group */
> unsigned long sum_nr_running; /* Nr tasks running in the group */
> unsigned long sum_weighted_load; /* Weighted load of group's tasks */
> +   unsigned long load_per_task;
> unsigned long group_capacity;
> unsigned long idle_cpus;
> unsigned long group_weight;
> @@ -4321,6 +4292,21 @@ struct sg_lb_stats {
> int group_has_capacity; /* Is there extra capacity in the group? */
>  };
>
> +/*
> + * sd_lb_stats - Structure to store the statistics of a sched_domain
> + *  during load balancing.
> + */
> +struct sd_lb_stats {
> +   struct sched_group *busiest;/* Busiest group in this sd */
> +   struct sched_group *this;   /* Local group in this sd */
> +   unsigned long total_load;   /* Total load of all groups in sd */
> +   unsigned long total_pwr;/* Total power of all groups in sd */
> +   unsigned long avg_load; /* Average load across all groups in sd */
> +
> +   struct sg_lb_stats this_stat;   /* Statistics of this group */
> +   struct sg_lb_stats busiest_stat;/* Statistics of the busiest group */
> +};
> +
>  /**
>   * get_sd_load_idx - Obtain the load index for a given sched domain.
>   * @sd: The sched_domain whose load_idx is to be obtained.
> @@ -4533,10 +4519,11 @@ static inline void update_sg_lb_stats(st
> nr_running = rq->nr_running;
>
> /* Bias balancing toward cpus of our domain */
> -   if (local_group)
> +   if (local_group) {
> load = target_load(i, load_idx);
> -   else {
> +   } else {
> load = source_load(i, load_idx);
> +
> if (load > max_cpu_load)
> max_cpu_load = load;
> if (min_cpu_load > load)
> @@ -4578,10 +4565,12 @@ static inline void update_sg_lb_stats(st
> (max_nr_running - min_nr_running) > 1)
> sgs->group_imb = 1;
>
> -   sgs->group_capacity = DIV_ROUND_CLOSEST(group->sgp->power,
> -   SCHED_POWER_SCALE);
> +   sgs->group_capacity =
> +   DIV_ROUND_CLOSEST(group->sgp->power, SCHED_POWER_SCALE);
> +
> if (!sgs->group_capacity)
> sgs->group_capacity = fix_small_capacity(env->sd, group);
> +
> sgs->group_weight = group->group_weight;
>
> if (sgs->group_capacity > sgs->sum_nr_running)
> @@ -4606,7 

Re: [PATCH 04/10] sched, fair: Shrink sg_lb_stats and play memset games

2013-08-24 Thread Paul Turner
On Mon, Aug 19, 2013 at 9:01 AM, Peter Zijlstra  wrote:
> We can shrink sg_lb_stats because rq::nr_running is an 'unsigned int'
> and cpu numbers are 'int'
>
> Before:
>   sgs:/* size: 72, cachelines: 2, members: 10 */
>   sds:/* size: 184, cachelines: 3, members: 7 */
>
> After:
>   sgs:/* size: 56, cachelines: 1, members: 10 */
>   sds:/* size: 152, cachelines: 3, members: 7 */
>
> Further we can avoid clearing all of sds since we do a total
> clear/assignment of sg_stats in update_sg_lb_stats() with exception of
> busiest_stat.avg_load which is referenced in update_sd_pick_busiest().
>
> Signed-off-by: Peter Zijlstra 
> ---
>  kernel/sched/fair.c |   42 +++---
>  1 file changed, 35 insertions(+), 7 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4282,12 +4282,12 @@ static unsigned long task_h_load(struct
>  struct sg_lb_stats {
> unsigned long avg_load; /*Avg load across the CPUs of the group */
> unsigned long group_load; /* Total load over the CPUs of the group */
> -   unsigned long sum_nr_running; /* Nr tasks running in the group */
> unsigned long sum_weighted_load; /* Weighted load of group's tasks */
> unsigned long load_per_task;
> -   unsigned long group_capacity;
> -   unsigned long idle_cpus;
> -   unsigned long group_weight;
> +   unsigned int sum_nr_running; /* Nr tasks running in the group */
> +   unsigned int group_capacity;
> +   unsigned int idle_cpus;
> +   unsigned int group_weight;
> int group_imb; /* Is there an imbalance in the group ? */
> int group_has_capacity; /* Is there extra capacity in the group? */
>  };
> @@ -4303,10 +4303,38 @@ struct sd_lb_stats {
> unsigned long total_pwr;/* Total power of all groups in sd */
> unsigned long avg_load; /* Average load across all groups in sd */
>
> -   struct sg_lb_stats this_stat;   /* Statistics of this group */
> struct sg_lb_stats busiest_stat;/* Statistics of the busiest group */
> +   struct sg_lb_stats this_stat;   /* Statistics of this group */
>  };
>
> +static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
> +{
> +   /*
> +* struct sd_lb_stats {
> +* struct sched_group *   busiest; // 0  8
> +* struct sched_group *   this;// 8  8
> +* long unsigned int  total_load;  //16  8
> +* long unsigned int  total_pwr;   //24  8
> +* long unsigned int  avg_load;//32  8
> +* struct sg_lb_stats {
> +* long unsigned int  avg_load;//40  8
> +* long unsigned int  group_load;  //48  8
> +* ...
> +* } busiest_stat; //40 56
> +* struct sg_lb_stats this_stat;   //96 56
> +*
> +* // size: 152, cachelines: 3, members: 7
> +* // last cacheline: 24 bytes
> +* };
> +*
> +* Skimp on the clearing to avoid duplicate work. We can avoid 
> clearing
> +* this_stat because update_sg_lb_stats() does a full 
> clear/assignment.
> +* We must however clear busiest_stat::avg_load because
> +* update_sd_pick_busiest() reads this before assignment.
> +*/

Does gcc seriously not get this right if we just write:
  sds->busiest = NULL;
  sds->local = NULL;
  

etc.?

> +   memset(sds, 0, offsetof(struct sd_lb_stats, busiest_stat.group_load));
> +}
> +
>  /**
>   * get_sd_load_idx - Obtain the load index for a given sched domain.
>   * @sd: The sched_domain whose load_idx is to be obtained.
> @@ -4665,7 +4693,7 @@ static inline void update_sd_lb_stats(st
>  */
> if (prefer_sibling && !local_group &&
> sds->this && 
> sds->this_stat.group_has_capacity)
> -   sgs->group_capacity = min(sgs->group_capacity, 1UL);
> +   sgs->group_capacity = min(sgs->group_capacity, 1U);
>
> /* Now, start updating sd_lb_stats */
> sds->total_load += sgs->group_load;
> @@ -4896,7 +4924,7 @@ static struct sched_group *find_busiest_
> struct sg_lb_stats *this, *busiest;
> struct sd_lb_stats sds;
>
> -   memset(, 0, sizeof(sds));
> +   init_sd_lb_stats();
>
> /*
>  * Compute the various statistics relavent for load balancing at
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/10] sched, fair: Optimize find_busiest_queue()

2013-08-24 Thread Paul Turner
On Mon, Aug 19, 2013 at 9:01 AM, Peter Zijlstra  wrote:
> Use for_each_cpu_and() and thereby avoid computing the capacity for
> CPUs we know we're not interested in.
>
> Signed-off-by: Peter Zijlstra 
> ---
>  kernel/sched/fair.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4977,7 +4977,7 @@ static struct rq *find_busiest_queue(str
> unsigned long busiest_load = 0, busiest_power = SCHED_POWER_SCALE;
> int i;
>
> -   for_each_cpu(i, sched_group_cpus(group)) {
> +   for_each_cpu_and(i, sched_group_cpus(group), env->cpus) {
> unsigned long power = power_of(i);
> unsigned long capacity = DIV_ROUND_CLOSEST(power,
>SCHED_POWER_SCALE);
> @@ -4986,9 +4986,6 @@ static struct rq *find_busiest_queue(str
> if (!capacity)
> capacity = fix_small_capacity(env->sd, group);
>
> -   if (!cpumask_test_cpu(i, env->cpus))
> -   continue;
> -
> rq = cpu_rq(i);
> wl = weighted_cpuload(i);

There's no need to actually do the divisions immediately below this also.

e.g.
  unsigned long max_load_power = SCHED_POWER_SCALE;
  ...
  if (wl * max_load_power > max_load * power) {
   max_load = wl;
   max_load_power = power;
   ...

This would actually end up being a little more accurate even.

[ Alternatively without caching max_load_power we could compare wl *
power vs max_load * SCHED_POWER_SCALE. ]

Reviewed-by: Paul Turner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/10] sched, fair: Fix the sd_parent_degenerate() code

2013-08-24 Thread Paul Turner
On Mon, Aug 19, 2013 at 9:01 AM, Peter Zijlstra  wrote:
> I found that on my wsm box I had a redundant domain:
>
> [0.949769] CPU0 attaching sched-domain:
> [0.953765]  domain 0: span 0,12 level SIBLING
> [0.958335]   groups: 0 (cpu_power = 587) 12 (cpu_power = 588)
> [0.964548]   domain 1: span 0-5,12-17 level MC
> [0.969206]groups: 0,12 (cpu_power = 1175) 1,13 (cpu_power = 1176) 
> 2,14 (cpu_power = 1176) 3,15 (cpu_power = 1176) 4,16 (cpu_power = 1176) 5,17 
> (cpu_power = 1176)
> [0.984993]domain 2: span 0-5,12-17 level CPU
> [0.989822] groups: 0-5,12-17 (cpu_power = 7055)
> [0.995049] domain 3: span 0-23 level NUMA
> [0.999620]  groups: 0-5,12-17 (cpu_power = 7055) 6-11,18-23 
> (cpu_power = 7056)
>
> Note how domain 2 has only a single group and spans the same CPUs as
> domain 1. We should not keep such domains and do in fact have code to
> prune these.
>
> It turns out that the 'new' SD_PREFER_SIBLING flag causes this, it
> makes sd_parent_degenerate() fail on the CPU domain. We can easily fix
> this by 'ignoring' the SD_PREFER_SIBLING bit and transfering it to
> whatever domain ends up covering the span.
>
> With this patch the domains now look like this:
>
> [0.950419] CPU0 attaching sched-domain:
> [0.954454]  domain 0: span 0,12 level SIBLING
> [0.959039]   groups: 0 (cpu_power = 587) 12 (cpu_power = 588)
> [0.965271]   domain 1: span 0-5,12-17 level MC
> [0.969936]groups: 0,12 (cpu_power = 1175) 1,13 (cpu_power = 1176) 
> 2,14 (cpu_power = 1176) 3,15 (cpu_power = 1176) 4,16 (cpu_power = 1176) 5,17 
> (cpu_power = 1176)
> [0.985737]domain 2: span 0-23 level NUMA
> [0.990231] groups: 0-5,12-17 (cpu_power = 7055) 6-11,18-23 (cpu_power 
> = 7056)
>
> Signed-off-by: Peter Zijlstra 
> ---
>  kernel/sched/core.c |   10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4948,7 +4948,8 @@ sd_parent_degenerate(struct sched_domain
> SD_BALANCE_FORK |
> SD_BALANCE_EXEC |
> SD_SHARE_CPUPOWER |
> -   SD_SHARE_PKG_RESOURCES);
> +   SD_SHARE_PKG_RESOURCES |
> +   SD_PREFER_SIBLING);
> if (nr_node_ids == 1)
> pflags &= ~SD_SERIALIZE;
> }
> @@ -5157,6 +5158,13 @@ cpu_attach_domain(struct sched_domain *s
> tmp->parent = parent->parent;
> if (parent->parent)
> parent->parent->child = tmp;
> +   /*
> +* Transfer SD_PREFER_SIBLING down in case of a
> +* degenerate parent; the spans match for this
> +* so the property transfers.
> +*/
> +   if (parent->flags & SD_PREFER_SIBLING)
> +   tmp->flags |= SD_PREFER_SIBLING;
> destroy_sched_domain(parent, cpu);
> } else
> tmp = tmp->parent;
>

Reviewed-by: Paul Turner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Finding out who's holding a lock?

2013-08-24 Thread Peter Hurley

On 08/22/2013 08:52 PM, Andy Lutomirski wrote:

My program is occasionally seeing slow page faults.  latencytop says
they're slow because they're waiting for read access to mmap_sem, but
latencytop isn't showing any other thread in the process blocking.

Is there any straightforward way to find out who called down_write on
mmap_sem when down_read is slow?


Build with CONFIG_LOCKDEP (Kernel Debugging -> Lock Debugging ->
"Lock Debugging: prove locking correctness").

When you experience the slowdown, sysrq + d (displays all currently
held locks). sysrq can also be programmatically triggered with
"echo d > /proc/sysrq-trigger" or equivalent.

Regards,
Peter Hurley

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


Re: linux-next: Tree for Aug 21 [ screen corruption in graphical mode ]

2013-08-24 Thread Sedat Dilek
On Fri, Aug 23, 2013 at 10:34 AM, Chris Wilson  wrote:
> On Fri, Aug 23, 2013 at 10:04:37AM +0200, Sedat Dilek wrote:
>> On Fri, Aug 23, 2013 at 9:55 AM, Sedat Dilek  wrote:
>> > On Thu, Aug 22, 2013 at 1:32 PM, Daniel Vetter  
>> > wrote:
>> >> On Thu, Aug 22, 2013 at 1:30 PM, Daniel Vetter  
>> >> wrote:
>> >>> On Thu, Aug 22, 2013 at 1:13 PM, Sedat Dilek  
>> >>> wrote:
>>  dmesg (a lot of traces) and kernel-config attached.
>> 
>>  UXA causes still screen corruption.
>> >>>
>> >>> Hm, was only a slim chance that this patch would fix anything - I
>> >>> think you'd always see an oops when you'd hit this bug instead of just
>> >>> a bit of corruption.
>> >>
>> >> Ok, I think it's time to throw in the towel a bit. I've dropped
>> >>
>> >>
>> >> commit d46f1c3f1372e3a72fab97c60480aa4a1084387f
>> >> Author: Chris Wilson 
>> >> Date:   Thu Aug 8 14:41:06 2013 +0100
>> >>
>> >> drm/i915: Allow the GPU to cache stolen memory
>
> Hmm, wrong patch. Unless you have a good reason, you just want to drop
> the ringbuffers in stolen.
>
>> >> from my queue. I guess we can retry for 3.13 again.
>> >
>> > I am sorry to keep someone's work to be delayed, really.
>> > I would have liked to see this fixed (and I have spent some time on it).
>
> It's just a minor memory optimization (reclaiming less than a megabyte
> of system memory).
>
>> > Which patches did you exactly drop?
>> >
>>
>> Sorry for bombing you with question...
>>
>> I am trying latest Linus-tree HEAD with the drm-intel-nightly I made
>> my last testings.
>>
>> Are any of these TLB / x86-get_unmapped_area fixes of interested...
>> has any effects on the reported issue?
>
> It should not. Of concern is how the GPU views the world which has its
> own independent set of TLBs and mapping tables - and access to those
> should always be uncached from the CPU's perspective.
>
>> I still wonder what is the root-cause...
>> I mean if SNA is OK but UXA not and Linux graphics stack is that complex.
>> ( Can't say if user-space like unity isn't involved... ).
>
> All that userspace can affect here is the timing and inital contents of
> the framebuffer, everything else is controlled by the kernel. All the
> testing we have done so far imply that the kernel's view of the machine
> state is consistent with our expectations, but the display is doing
> something inexplicable.

Can this be a problem?

[ dmesg ]
[   27.949704] [drm] Wrong MCH_SSKPD value: 0x16040307
[   27.949708] [drm] This can cause pipe underruns and display issues.
[   27.949709] [drm] Please upgrade your BIOS to fix this.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: move of helpers into the core

2013-08-24 Thread Mauro Carvalho Chehab
Em Thu, 22 Aug 2013 18:00:14 +0200
Wolfram Sang  escreveu:

> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Felipe Balbi 
> Acked-by: Rafael J. Wysocki 
> Tested-by: Sylwester Nawrocki 
> Signed-off-by: Wolfram Sang 

Acked-by: Mauro Carvalho Chehab 

> ---
> 
> V2->V3: Was trying to be too smart by only fixing includes needed.
>   Took a more general approach this time, converting of_i2c.h
>   to i2c.h in case i2c.h was not already there. Otherwise
>   remove it. Improved my build scripts and no build failures,
>   no complaints from buildbot as well.
> 
> 
>  Documentation/acpi/enumeration.txt  |1 -
>  arch/powerpc/platforms/44x/warp.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c  |1 -
>  drivers/gpu/host1x/drm/output.c |2 +-
>  drivers/i2c/busses/i2c-at91.c   |3 -
>  drivers/i2c/busses/i2c-cpm.c|6 --
>  drivers/i2c/busses/i2c-davinci.c|2 -
>  drivers/i2c/busses/i2c-designware-platdrv.c |2 -
>  drivers/i2c/busses/i2c-gpio.c   |3 -
>  drivers/i2c/busses/i2c-i801.c   |2 -
>  drivers/i2c/busses/i2c-ibm_iic.c|4 -
>  drivers/i2c/busses/i2c-imx.c|3 -
>  drivers/i2c/busses/i2c-mpc.c|2 -
>  drivers/i2c/busses/i2c-mv64xxx.c|3 -
>  drivers/i2c/busses/i2c-mxs.c|3 -
>  drivers/i2c/busses/i2c-nomadik.c|3 -
>  drivers/i2c/busses/i2c-ocores.c |3 -
>  drivers/i2c/busses/i2c-octeon.c |3 -
>  drivers/i2c/busses/i2c-omap.c   |3 -
>  drivers/i2c/busses/i2c-pnx.c|3 -
>  drivers/i2c/busses/i2c-powermac.c   |9 +-
>  drivers/i2c/busses/i2c-pxa.c|2 -
>  drivers/i2c/busses/i2c-s3c2410.c|2 -
>  drivers/i2c/busses/i2c-sh_mobile.c  |2 -
>  drivers/i2c/busses/i2c-sirf.c   |3 -
>  drivers/i2c/busses/i2c-stu300.c |2 -
>  drivers/i2c/busses/i2c-tegra.c  |3 -
>  drivers/i2c/busses/i2c-versatile.c  |2 -
>  drivers/i2c/busses/i2c-wmt.c|3 -
>  drivers/i2c/busses/i2c-xiic.c   |3 -
>  drivers/i2c/i2c-core.c  |  109 +-
>  drivers/i2c/i2c-mux.c   |3 -
>  drivers/i2c/muxes/i2c-arb-gpio-challenge.c  |1 -
>  drivers/i2c/muxes/i2c-mux-gpio.c|1 -
>  drivers/i2c/muxes/i2c-mux-pinctrl.c |1 -
>  drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +-
>  drivers/media/platform/exynos4-is/fimc-is.c |2 +-
>  drivers/media/platform/exynos4-is/media-dev.c   |1 -
>  drivers/of/Kconfig  |6 --
>  drivers/of/Makefile |1 -
>  drivers/of/of_i2c.c |  114 
> ---
>  drivers/staging/imx-drm/imx-tve.c   |2 +-
>  include/linux/i2c.h |   20 
>  include/linux/of_i2c.h  |   46 -
>  sound/soc/fsl/imx-sgtl5000.c|2 +-
>  sound/soc/fsl/imx-wm8962.c  |2 +-
>  47 files changed, 138 insertions(+), 262 deletions(-)
>  delete mode 100644 drivers/of/of_i2c.c
>  delete mode 100644 include/linux/of_i2c.h
> 
> diff --git a/Documentation/acpi/enumeration.txt 
> b/Documentation/acpi/enumeration.txt
> index d9be7a9..958266e 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
>   if (ret)
>   /* handle error */
>  
> - of_i2c_register_devices(adapter);
>   /* Enumerate the slave devices behind this bus via ACPI */
>   acpi_i2c_register_devices(adapter);
>  
> diff --git a/arch/powerpc/platforms/44x/warp.c 
> b/arch/powerpc/platforms/44x/warp.c
> index 4cfa499..534574a 100644
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index dfffaf0..a19f657 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -16,7 +16,6 @@
>   */
>  

[PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700 Device Driver Support

2013-08-24 Thread liujunliang_ljl
From: liujl 


Signed-off-by: liujl 
---
 drivers/net/usb/Kconfig  |8 +
 drivers/net/usb/Makefile |1 +
 drivers/net/usb/sr9700.c |  551 ++
 drivers/net/usb/sr9700.h |  172 ++
 4 files changed, 732 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/usb/sr9700.c
 create mode 100644 drivers/net/usb/sr9700.h

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 287cc62..a94b196 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -272,6 +272,14 @@ config USB_NET_DM9601
  This option adds support for Davicom DM9601 based USB 1.1
  10/100 Ethernet adapters.
 
+config USB_NET_SR9700
+   tristate "CoreChip-sz SR9700 based USB 1.1 10/100 ethernet devices"
+   depends on USB_USBNET
+   select CRC32
+   help
+ This option adds support for CoreChip-sz SR9700 based USB 1.1
+ 10/100 Ethernet adapters.
+
 config USB_NET_SMSC75XX
tristate "SMSC LAN75XX based USB 2.0 gigabit ethernet devices"
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 9ab5c9d..bba87a2 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_NET_AX88179_178A)  += ax88179_178a.o
 obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
 obj-$(CONFIG_USB_NET_CDC_EEM)  += cdc_eem.o
 obj-$(CONFIG_USB_NET_DM9601)   += dm9601.o
+obj-$(CONFIG_USB_NET_SR9700)   += sr9700.o
 obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
 obj-$(CONFIG_USB_NET_SMSC95XX) += smsc95xx.o
 obj-$(CONFIG_USB_NET_GL620A)   += gl620a.o
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
new file mode 100644
index 000..27c86ec
--- /dev/null
+++ b/drivers/net/usb/sr9700.c
@@ -0,0 +1,551 @@
+/*
+ * CoreChip-sz SR9700 one chip USB 1.1 Ethernet Devices
+ *
+ * Author : liujl 
+ *
+ * Based on dm9601.c
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sr9700.h"
+
+static int sr_read(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+   int err;
+
+   err = usbnet_read_cmd(dev, SR_RD_REGS, SR_REQ_RD_REG,
+   0, reg, data, length);
+   if ((err != length) && (err >= 0))
+   err = -EINVAL;
+   return err;
+}
+
+static int sr_write(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+   int err;
+
+   err = usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
+   0, reg, data, length);
+   if ((err >= 0) && (err < length))
+   err = -EINVAL;
+   return err;
+}
+
+static int sr_read_reg(struct usbnet *dev, u8 reg, u8 *value)
+{
+   return sr_read(dev, reg, 1, value);
+}
+
+static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
+{
+   return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
+   value, reg, NULL, 0);
+}
+
+static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+   usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
+   0, reg, data, length);
+}
+
+static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
+{
+   usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
+   value, reg, NULL, 0);
+}
+
+static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
+{
+   int i, ret;
+
+   ret = 0;
+   for (i = 0; i < SR_SHARE_TIMEOUT; i++) {
+   u8 tmp = 0;
+
+   udelay(1);
+   ret = sr_read_reg(dev, EPCR, );
+   if (ret < 0)
+   goto out;
+
+   /* ready */
+   if ((tmp & EPCR_ERRE) == 0)
+   break;
+   }
+
+   if (i >= SR_SHARE_TIMEOUT) {
+   netdev_err(dev->net, "%s write timed out!\n",
+   phy ? "phy" : "eeprom");
+   ret = -EIO;
+   goto out;
+   }
+
+out:
+   return ret;
+}
+
+static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg, __le16 
*value)
+{
+   int ret;
+
+   mutex_lock(>phy_mutex);
+
+   sr_write_reg(dev, EPAR, phy ? (reg | 0x40) : reg);
+   sr_write_reg(dev, EPCR, phy ? 0xc : 0x4);
+
+   ret = wait_phy_eeprom_ready(dev, phy);
+   if (ret < 0)
+   goto out;
+
+   sr_write_reg(dev, EPCR, 0x0);
+   ret = sr_read(dev, EPDR, 2, value);
+
+   netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
+   phy, reg, *value, ret);
+
+out:
+   mutex_unlock(>phy_mutex);
+   return ret;
+}
+
+static int 

[PATCH] IPC: bugfix for msgrcv with msgtyp < 0

2013-08-24 Thread Svenning Sørensen

According to 'man msgrcv':
"If msgtyp is less than 0, the first message of the lowest type that is less
than or equal to the absolute value of msgtyp shall be received."

Bug: The kernel only returns a message if its type is 1; other messages with
type < abs(msgtype) will never get returned.

Fix: After having traversed the list to find the first message with the
lowest type, we need to actually return that message.

Signed-off-by: Svenning Soerensen 

diff --git a/ipc/msg.c b/ipc/msg.c
index bd60d7e..9f29d9e 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -839,7 +839,7 @@ static inline void free_copy(struct msg_msg *copy)
 
 static struct msg_msg *find_msg(struct msg_queue *msq, long *msgtyp, int mode)

 {
-   struct msg_msg *msg;
+   struct msg_msg *msg, *found = NULL;
long count = 0;
 
 	list_for_each_entry(msg, >q_messages, m_list) {

@@ -848,6 +848,7 @@ static struct msg_msg *find_msg(struct msg_queue *msq, long 
*msgtyp, int mode)
   *msgtyp, mode)) {
if (mode == SEARCH_LESSEQUAL && msg->m_type != 1) {
*msgtyp = msg->m_type - 1;
+   found = msg;
} else if (mode == SEARCH_NUMBER) {
if (*msgtyp == count)
return msg;
@@ -857,7 +858,7 @@ static struct msg_msg *find_msg(struct msg_queue *msq, long 
*msgtyp, int mode)
}
}
 
-	return ERR_PTR(-EAGAIN);

+   return found ?: ERR_PTR(-EAGAIN);
 }
 
 long do_msgrcv(int msqid, void __user *buf, size_t bufsz, long msgtyp, int msgflg,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] IPC: bugfix for msgrcv with msgtyp < 0

2013-08-24 Thread Peter Hurley

On 08/24/2013 07:44 AM, Svenning Sørensen wrote:

According to 'man msgrcv':
"If msgtyp is less than 0, the first message of the lowest type that is less
than or equal to the absolute value of msgtyp shall be received."

Bug: The kernel only returns a message if its type is 1; other messages with
type < abs(msgtype) will never get returned.

Fix: After having traversed the list to find the first message with the
lowest type, we need to actually return that message.


Sorry for the breakage. Needs to go to -stable as well.

Reviewed-by: Peter Hurley 


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


[PATCH v2] iwlwifi: mvm: make debugfs write() operations write up to count bytes

2013-08-24 Thread Djalal Harouni
Some debugfs write() operations of the MVM Firmware will ignore the
count argument, and will copy more bytes than what was specified.
Fix this by getting the right count of bytes.

This will honor restrictions put on the number of bytes to write and
avoid strcmp() calls on garbage data.

Signed-off-by: Djalal Harouni 
Cc: "Berg, Johannes" 
---
Patch compile tested only.
v2 Clean patch and use min_t() as noted by Berg Johannes

 drivers/net/wireless/iwlwifi/mvm/debugfs.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/debugfs.c 
b/drivers/net/wireless/iwlwifi/mvm/debugfs.c
index aac81b8..299966a 100644
--- a/drivers/net/wireless/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/iwlwifi/mvm/debugfs.c
@@ -257,7 +257,8 @@ static ssize_t iwl_dbgfs_power_down_allow_write(struct file 
*file,
if (!mvm->ucode_loaded)
return -EIO;
 
-   if (copy_from_user(buf, user_buf, sizeof(buf)))
+   count = min_t(size_t, count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, count))
return -EFAULT;
 
if (sscanf(buf, "%d", ) != 1)
@@ -281,7 +282,8 @@ static ssize_t iwl_dbgfs_power_down_d3_allow_write(struct 
file *file,
char buf[8] = {};
int allow;
 
-   if (copy_from_user(buf, user_buf, sizeof(buf)))
+   count = min_t(size_t, count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, count))
return -EFAULT;
 
if (sscanf(buf, "%d", ) != 1)
@@ -371,7 +373,8 @@ static ssize_t iwl_dbgfs_pm_params_write(struct file *file,
int val;
int ret;
 
-   if (copy_from_user(buf, user_buf, sizeof(buf)))
+   count = min_t(size_t, count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, count))
return -EFAULT;
 
if (!strncmp("keep_alive=", buf, 11)) {
@@ -968,7 +971,8 @@ static ssize_t iwl_dbgfs_d3_sram_write(struct file *file,
char buf[8] = {};
int store;
 
-   if (copy_from_user(buf, user_buf, sizeof(buf)))
+   count = min_t(size_t, count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, count))
return -EFAULT;
 
if (sscanf(buf, "%d", ) != 1)
-- 
1.7.11.7

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


[PATCH] ARM: OMAP: TI816X: add clock domain support for TI816x

2013-08-24 Thread Aida Mynzhasova
This patch adds required definitions and structures for clockdomain
initialization, so omap3xxx_clockdomains_init() was substituted by
new ti81xx_clockdomains_init() while early initialization of
TI81XX platform.

signed-off-by: Aida Mynzhasova 
---
 arch/arm/mach-omap2/Makefile   |   2 +
 arch/arm/mach-omap2/clockdomain.h  |   1 +
 arch/arm/mach-omap2/clockdomains_ti81xx_data.c | 208 +
 arch/arm/mach-omap2/cm-regbits-ti81xx.h|  22 +++
 arch/arm/mach-omap2/cm_ti81xx.h|  61 
 arch/arm/mach-omap2/io.c   |   2 +-
 6 files changed, 295 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-omap2/clockdomains_ti81xx_data.c
 create mode 100644 arch/arm/mach-omap2/cm-regbits-ti81xx.h
 create mode 100644 arch/arm/mach-omap2/cm_ti81xx.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..44c19b5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -157,6 +157,8 @@ obj-$(CONFIG_ARCH_OMAP4)+= $(clockdomain-common)
 obj-$(CONFIG_ARCH_OMAP4)   += clockdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)   += $(clockdomain-common)
 obj-$(CONFIG_SOC_AM33XX)   += clockdomains33xx_data.o
+obj-$(CONFIG_SOC_TI81XX)   += $(clockdomain-common)
+obj-$(CONFIG_SOC_TI81XX)   += clockdomains_ti81xx_data.o
 obj-$(CONFIG_SOC_AM43XX)   += $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index daeecf1..5c42bcf 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -215,6 +215,7 @@ extern void __init omap242x_clockdomains_init(void);
 extern void __init omap243x_clockdomains_init(void);
 extern void __init omap3xxx_clockdomains_init(void);
 extern void __init am33xx_clockdomains_init(void);
+extern void __init ti81xx_clockdomains_init(void);
 extern void __init omap44xx_clockdomains_init(void);
 extern void __init omap54xx_clockdomains_init(void);
 
diff --git a/arch/arm/mach-omap2/clockdomains_ti81xx_data.c 
b/arch/arm/mach-omap2/clockdomains_ti81xx_data.c
new file mode 100644
index 000..94d7439
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains_ti81xx_data.c
@@ -0,0 +1,208 @@
+/*
+ * TI81XX Clock Domain data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ * Copyright (C) 2013 SKTB SKiT, http://www.skitlab.ru/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS_TI81XX_H
+#define __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS_TI81XX_H
+
+#include 
+#include 
+
+#include "clockdomain.h"
+
+#include "cm_ti81xx.h"
+#include "cm-regbits-ti81xx.h"
+
+/*
+ * - Add other domains as required
+ * - Fill up associated powerdomans (especially ALWON powerdomains are NULL at
+ *   the moment
+ * - Consider dependencies across domains (probably not applicable till now)
+ */
+
+/* Common TI81XX */
+static struct clockdomain alwon_l3_slow_ti81xx_clkdm = {
+   .name   = "alwon_l3_slow_clkdm",
+   .pwrdm  = { .name = "alwon_pwrdm" },
+   .cm_inst= TI81XX_CM_ALWON_MOD,
+   .clkdm_offs = TI81XX_CM_ALWON_L3_SLOW_CLKDM,
+   .clktrctrl_mask = TI81XX_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain alwon_l3_med_ti81xx_clkdm = {
+   .name   = "alwon_l3_med_clkdm",
+   .pwrdm  = { .name = "alwon_pwrdm" },
+   .cm_inst= TI81XX_CM_ALWON_MOD,
+   .clkdm_offs = TI81XX_CM_ALWON_L3_MED_CLKDM,
+   .clktrctrl_mask = TI81XX_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain alwon_l3_fast_ti81xx_clkdm = {
+   .name   = "alwon_l3_fast_clkdm",
+   .pwrdm  = { .name = "alwon_pwrdm" },
+   .cm_inst= TI81XX_CM_ALWON_MOD,
+   .clkdm_offs = TI81XX_CM_ALWON_L3_FAST_CLKDM,
+   .clktrctrl_mask = TI81XX_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain alwon_ethernet_ti81xx_clkdm = {
+   .name   = "alwon_ethernet_clkdm",
+   .pwrdm  = { .name = "alwon_pwrdm" },
+   .cm_inst= TI81XX_CM_ALWON_MOD,
+   .clkdm_offs = TI81XX_CM_ETHERNET_CLKDM,
+   .clktrctrl_mask = TI81XX_CLKTRCTRL_MASK,
+   .flags   

Re: [PATCH v2 3/3] gpio: pcf857x: Add OF support

2013-08-24 Thread Tomasz Figa
On Saturday 24 of August 2013 02:54:07 Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thank you for the review.
> 
> On Saturday 24 August 2013 02:41:59 Tomasz Figa wrote:
> > On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
> > > Add DT bindings for the pcf857x-compatible chips and parse the
> > > device
> > > tree node in the driver.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > >  ---
> > > 
> > >  .../devicetree/bindings/gpio/gpio-pcf857x.txt  | 71
> > >  + drivers/gpio/gpio-pcf857x.c 
> > >| 57 ++--- 2 files changed, 119 insertions(+), 9
> > >  deletions(-)
> > >  
> > >  create mode 100644
> > > 
> > > Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > > b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt new file
> > > mode
> > > 100644
> > > index 000..df94462
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > > @@ -0,0 +1,71 @@
> 
> [snip]
> 
> > > +  - pins-initial-state: Bitmask that specifies the initial state of
> > > +each pin. When a bit is set to zero, the corresponding pin will
> > > be
> > > +initialized to the input (pulled-up) state. When the  bit is
> > > set to +one, the pin will be initialized the the low-level
> > > output state. If +the property is not specified all pins will
> > > be initialized to the +input state.
> > 
> > Hmm, do you actually need to know whether those pins are outputs or
> > inputs before they get used for first time? I believe any driver
> > using GPIO will call gpio_direction_{in,out}put() before it starts
> > using the pin, which will initialize the pin to a known state.
> > 
> > What I'd suggest is making the driver handle this by having a bit mask
> > that marks states of pins as defined and flagging all pins as
> > undefined by default. Then any call to gpio_direction_output() or
> > _input() would mark it as defined and direction of the pin could be
> > stored in internal driver structures.
> 
> The problem is that all pins are controlled through a single I2C write.
> Setting the direction of a pin will set the direction of all other pins.
> I thus need to know what the initial settings are to avoid glitches.

Oh, that's a funny hardware, isn't it? :)

Well, I guess it can't be helped then. Sorry for the noise.

> > > +  The I/O expander can detect input state changes, and thus
> > > optionally
> > > +  act as an interrupt controller. When interrupts support is
> > > desired
> > 
> > I don't like this statement. Device tree should represent what the
> > device allows you to do, not what you want the device to do.
> > 
> > My opinion on this is that if the chip supports interrupts then it
> > should always be an interrupt-controller (unless its interrupt pin is
> > not wired on the board, but this still conforms to what I wrote
> > above).
> 
> I agree. What about the following text then ?
> 
> The I/O expander can detect input state changes, and thus optionally act
> as an interrupt controller. When the expander interrupt pin is
> connected all the following properties must be set. For more
> information please see the interrupt controller device tree bindings
> documentation available at
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.

Sounds good.

> > > diff --git a/drivers/gpio/gpio-pcf857x.c
> > > b/drivers/gpio/gpio-pcf857x.c
> > > index 070e81f..50a90f1 100644
> > > --- a/drivers/gpio/gpio-pcf857x.c
> > > +++ b/drivers/gpio/gpio-pcf857x.c
> 
> [snip]
> 
> > > @@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] =
> > > {
> > > 
> > >  };
> > >  MODULE_DEVICE_TABLE(i2c, pcf857x_id);
> > > 
> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id pcf857x_of_table[] = {
> > > + { .compatible = "nxp,pcf8574", .data = (void *)8 },
> > > + { .compatible = "nxp,pcf8574a", .data = (void *)8 },
> > > + { .compatible = "nxp,pca8574", .data = (void *)8 },
> > > + { .compatible = "nxp,pca9670", .data = (void *)8 },
> > > + { .compatible = "nxp,pca9672", .data = (void *)8 },
> > > + { .compatible = "nxp,pca9674", .data = (void *)8 },
> > > + { .compatible = "nxp,pcf8575", .data = (void *)16 },
> > > + { .compatible = "nxp,pca8575", .data = (void *)16 },
> > > + { .compatible = "nxp,pca9671", .data = (void *)16 },
> > > + { .compatible = "nxp,pca9673", .data = (void *)16 },
> > > + { .compatible = "nxp,pca9675", .data = (void *)16 },
> > > + { .compatible = "maxim,max7328", .data = (void *)8 },
> > > + { .compatible = "maxim,max7329", .data = (void *)8 },
> > > + { .compatible = "ti,tca9554", .data = (void *)8 },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, pcf857x_of_table);
> > > +#endif
> > > +
> > > 
> > >  /*
> > >  
> > >   * The pcf857x, pca857x, and pca967x chips only expose one read and
> > >   one
> > >   * write register.  Writing a "one" bit (to match the reset state)
> 

[PATCH 2/2] Input: bcm5974: Add another device ID for the mid-2013 Macbook Air

2013-08-24 Thread Ian Munsie
This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
lsusb:

Bus 001 Device 003: ID 05ac:0290 Apple, Inc.

Since IDs already exist for this generation Macbook air as WELLSPRING8,
name this one WELLSPRING8A. This only adds an ANSI version since it's
device ID is only one less than the existing WELLSPRING8 IDs.

Signed-off-by: Ian Munsie 
---
 drivers/input/mouse/bcm5974.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 4ef4d5e..fcd2f3f 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -88,6 +88,8 @@
 #define USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI  0x0259
 #define USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO   0x025a
 #define USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS   0x025b
+/* MacbookAir6,1 (unibody, June 2013) */
+#define USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI  0x0290
 /* MacbookAir6,2 (unibody, June 2013) */
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI   0x0291
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
@@ -149,6 +151,8 @@ static const struct usb_device_id bcm5974_table[] = {
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_ANSI),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS),
+   /* MacbookAir6,1 */
+   BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI),
/* MacbookAir6,2 */
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI),
BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING8_ISO),
@@ -424,6 +428,19 @@ static const struct bcm5974_config bcm5974_config_table[] 
= {
{ SN_COORD, -150, 6600 },
{ SN_ORIENT, -MAX_FINGER_ORIENTATION, MAX_FINGER_ORIENTATION }
},
+   {
+   USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI,
+   0,
+   0,
+   HAS_INTEGRATED_BUTTON,
+   0, sizeof(struct bt_data),
+   0x83, TYPE3, FINGER_TYPE3, FINGER_TYPE3 + SIZEOF_ALL_FINGERS,
+   { SN_PRESSURE, 0, 300 },
+   { SN_WIDTH, 0, 2048 },
+   { SN_COORD, -4620, 5140 },
+   { SN_COORD, -150, 6600 },
+   { SN_ORIENT, -MAX_FINGER_ORIENTATION, MAX_FINGER_ORIENTATION }
+   },
{}
 };
 
-- 
1.8.4.rc3

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


Add missing device ID for mid-2013 Macbook Air 6,1

2013-08-24 Thread Ian Munsie
I recently got a new mid-2013 Macbook Air, which seems to use a device ID that
is missing from the kernel. From lsusb:
Bus 001 Device 003: ID 05ac:0290 Apple, Inc.

This generation of Macbook Air already has three IDs listed in the kernel
(0x0291, 0x0292 and 0x0293) as WELLSPRING8, so I've added 0x0290 to that list
as WELLSPRING8A. It looks like these generally come in triplets of consecutive
device IDs, so it's not clear to me why there would be an extra one in this
generation (and only -1 from the existing IDs which doesn't leave room for
additional ISO & JIS layouts if they are numbered consecutively).

With these patches the Fn key now works for me, as does the multitouch
functionality of the touchpad.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] HID: apple: Add another device ID for the mid-2013 Macbook Air

2013-08-24 Thread Ian Munsie
This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
lsusb:

Bus 001 Device 003: ID 05ac:0290 Apple, Inc.

Since IDs already exist for this generation Macbook air as WELLSPRING8,
name this one WELLSPRING8A. This only adds an ANSI version since it's
device ID is only one less than the existing WELLSPRING8 IDs.

Signed-off-by: Ian Munsie 
---
 drivers/hid/hid-apple.c | 2 ++
 drivers/hid/hid-core.c  | 2 ++
 drivers/hid/hid-ids.h   | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index c7710b5..9e5e9dd 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -530,6 +530,8 @@ static const struct hid_device_id apple_devices[] = {
.driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
+   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI),
+   .driver_data = APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1..5ebcfac 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1550,6 +1550,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) },
@@ -2195,6 +2196,7 @@ static const struct hid_device_id hid_mouse_ignore_list[] 
= {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8_JIS) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
{ }
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ffe4c7a..442a877 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -135,6 +135,7 @@
 #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS   0x023b
 #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI  0x0255
 #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO   0x0256
+#define USB_DEVICE_ID_APPLE_WELLSPRING8A_ANSI  0x0290
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI   0x0291
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
 #define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0293
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/16] cpufreq: create & use cpufreq_generic_get() routine

2013-08-24 Thread Rafael J. Wysocki
On Saturday, August 24, 2013 09:50:06 AM Viresh Kumar wrote:
> On 24 August 2013 01:10, Rafael J. Wysocki  wrote:
> > On Friday, August 23, 2013 09:20:35 PM Viresh Kumar wrote:
> >> CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), 
> >> to get
> >> CPUs clk rate, has similar sort of code used for most of them.
> >>
> >> This patchset adds a generic ->get() which will do the same thing for 
> >> them. All
> >> those drivers are required to now is to set .get to cpufreq_generic_get() 
> >> and
> >> set their clk pointer in policy->clk during ->init().
> >>
> >> Later part of this patchset fixes 17 drivers with this change.
> >>
> >> That's part 7 of my generic cleanups for CPUFreq core, first six are here:
> >
> > And that's the last one for 3.13, right?
> 
> 3.13 is too far, can't promise that really :)

OK, let me rephrase that more directly: Please, slow down.  Allow your previous
changes to be integrated before you throw more of them at people.

Thanks,
Rafael

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

2013-08-24 Thread Jiri Olsa
The current throttling code triggers WARN below via following
workload (only hit on AMD machine with 48 CPUs):

  # while [ 1 ]; do perf record perf bench sched messaging; done

  WARNING: at arch/x86/kernel/cpu/perf_event.c:1054 x86_pmu_start+0xc6/0x100()
  SNIP
  Call Trace:
 [] dump_stack+0x19/0x1b
   [] warn_slowpath_common+0x61/0x80
   [] warn_slowpath_null+0x1a/0x20
   [] x86_pmu_start+0xc6/0x100
   [] perf_adjust_freq_unthr_context.part.75+0x182/0x1a0
   [] perf_event_task_tick+0xc8/0xf0
   [] scheduler_tick+0xd1/0x140
   [] update_process_times+0x66/0x80
   [] tick_sched_handle.isra.15+0x25/0x60
   [] tick_sched_timer+0x41/0x60
   [] __run_hrtimer+0x74/0x1d0
   [] ? tick_sched_handle.isra.15+0x60/0x60
   [] hrtimer_interrupt+0xf7/0x240
   [] smp_apic_timer_interrupt+0x69/0x9c
   [] apic_timer_interrupt+0x6d/0x80
 [] ? __perf_event_task_sched_in+0x184/0x1a0
   [] ? kfree_skbmem+0x37/0x90
   [] ? __slab_free+0x1ac/0x30f
   [] ? kfree+0xfd/0x130
   [] kmem_cache_free+0x1b2/0x1d0
   [] kfree_skbmem+0x37/0x90
   [] consume_skb+0x34/0x80
   [] unix_stream_recvmsg+0x4e7/0x820
   [] sock_aio_read.part.7+0x116/0x130
   [] ? __perf_sw_event+0x19c/0x1e0
   [] sock_aio_read+0x21/0x30
   [] do_sync_read+0x80/0xb0
   [] vfs_read+0x145/0x170
   [] SyS_read+0x49/0xa0
   [] ? __audit_syscall_exit+0x1f6/0x2a0
   [] system_call_fastpath+0x16/0x1b
  ---[ end trace 622b7e226c4a766a ]---

The reason is race in perf_event_task_tick throttling code.
The race flow (simplified code):

  - perf_throttled_count is per cpu variable and is
CPU throttling flag, here starting with 0
  - perf_throttled_seq is sequence/domain for allowed
count of interrupts within the tick, gets increased
each tick

on single CPU (CPU bounded event):

  ... workload

perf_event_task_tick:
|
| T0inc(perf_throttled_seq)
| T1needs_unthr = xchg(perf_throttled_count, 0) == 0
 tick gets interrupted:

... event gets throttled under new seq ...

  T2last NMI comes, event is throttled - inc(perf_throttled_count)

 back to tick:
| perf_adjust_freq_unthr_context:
|
| T3unthrottling is skiped for event (needs_unthr == 0)
| T4event is stop and started via freq adjustment
|
tick ends

  ... workload
  ... no sample is hit for event ...

perf_event_task_tick:
|
| T5needs_unthr = xchg(perf_throttled_count, 0) != 0 (from T2)
| T6unthrottling is done on event (interrupts == MAX_INTERRUPTS)
|   event is already started (from T4) -> WARN

Fixing this by not checking needs_unthr again and thus
check all events for unthrottling.

Signed-off-by: Jiri Olsa 
Reported-by: Jan Stancek 
Suggested-by: Peter Zijlstra 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Stephane Eranian 
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 928fae7..299d1f1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2709,7 +2709,7 @@ static void perf_adjust_freq_unthr_context(struct 
perf_event_context *ctx,
 
hwc = >hw;
 
-   if (needs_unthr && hwc->interrupts == MAX_INTERRUPTS) {
+   if (hwc->interrupts == MAX_INTERRUPTS) {
hwc->interrupts = 0;
perf_log_throttle(event, 1);
event->pmu->start(event, 0);
-- 
1.7.11.7

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


[PATCH v2] i915: Update VGA arbiter support for newer devices

2013-08-24 Thread Alex Williamson
This is intended to add VGA arbiter support for Intel HD graphics on
Core processors.  The old GMCH registers no longer exist, so even
though it appears that i915 participates in VGA arbitration, it doesn't
work.  On Intel HD graphics we already attempt to disable VGA regions
of the device.  This makes registering as a VGA client unnecessary since
we don't intend to operate differently depending on how many VGA devices
are present.  We can disable VGA memory regions by clearing the memory
enable bit in the VGA MSR.  That only leaves VGA IO, which we update
the VGA arbiter to know that we don't participate in VGA memory
arbitration.  We also add a hook on unload to re-enable memory and
reinstate VGA memory arbitration.

Signed-off-by: Alex Williamson 
---

v2: I915_READ/WRITE accessors don't work in i915_disable_vga, use inb/outb
directly.  Also, on the driver unbind VGA enable path, acquire legacy
IO to re-enable VGA memory.  Correct comment.

As with v1, this depends on "vgaarb: Fixes for partial VGA opt-out".  With
all patches I'm able to assign a discrete PEG VGA device to a guest and
execute the VBIOS w/o interference from IGD or corruption of the IGD
framebuffer.

 drivers/gpu/drm/i915/i915_dma.c  |9 ++---
 drivers/gpu/drm/i915/intel_display.c |   24 
 2 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f466980..d9cf216 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1287,9 +1287,12 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
-   if (ret && ret != -ENODEV)
-   goto out;
+   if (!HAS_PCH_SPLIT(dev)) {
+   ret = vga_client_register(dev->pdev, dev, NULL,
+ i915_vga_set_decode);
+   if (ret && ret != -ENODEV)
+   goto out;
+   }
 
intel_register_dsm_handler();
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fb3058..2bb805c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9519,6 +9519,15 @@ static void i915_disable_vga(struct drm_device *dev)
outb(SR01, VGA_SR_INDEX);
sr1 = inb(VGA_SR_DATA);
outb(sr1 | 1<<5, VGA_SR_DATA);
+
+   /* Disable VGA memory on Intel HD */
+   if (HAS_PCH_SPLIT(dev)) {
+   outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
+   vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
+  VGA_RSRC_NORMAL_IO |
+  VGA_RSRC_NORMAL_MEM);
+   }
+
vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
udelay(300);
 
@@ -9526,6 +9535,19 @@ static void i915_disable_vga(struct drm_device *dev)
POSTING_READ(vga_reg);
 }
 
+static void i915_enable_vga(struct drm_device *dev)
+{
+   /* Enable VGA memory on Intel HD */
+   if (HAS_PCH_SPLIT(dev)) {
+   vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
+   outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
+   vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_MASK |
+  VGA_RSRC_NORMAL_IO |
+  VGA_RSRC_NORMAL_MEM);
+   vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
+   }
+}
+
 void intel_modeset_init_hw(struct drm_device *dev)
 {
intel_init_power_well(dev);
@@ -9983,6 +10005,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
 
intel_disable_fbc(dev);
 
+   i915_enable_vga(dev);
+
intel_disable_gt_powersave(dev);
 
ironlake_teardown_rc6(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 v2 4/4] pinctrl: mvebu: Convert to use devm_ioremap_resource

2013-08-24 Thread Ezequiel Garcia
Hi Jisheng,

On Fri, Aug 23, 2013 at 10:34:02AM +0800, Jisheng Zhang wrote:
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 

Mmm.. I would prefer to see a better commit log for this patch.
In particular, the current code is buggy (for there's a leak) and
this patch fixes it.
Care to write something meaningful and re-send? (except the patch
Mike already took, I guess).

With that changes you can add:

Reviewed-by: Ezequiel Garcia T

for the whole series.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.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/


[GIT PULL] ACPI fix for v3.11-rc7

2013-08-24 Thread Rafael J. Wysocki
Hi Linus,

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
acpi-3.11-rc7

to receive one ACPI fix for v3.11-rc7 as
commit 168cf0eca45b86014b8c2a17fcb0673ab1af809b

  Revert "ACPI / video: Always call acpi_video_init_brightness() on init"

on top of commit b36f4be3de1b123d8601de062e7dbfc904f305fb

  Linux 3.11-rc6

I really hoped that it wouldn't be necessary to change anything in ACPI at
this point, but it turns out that we need to revert one more ACPI video
commit causing trouble.

This reverts a change in the ACPI video driver that caused the ACPI
backlight initialization to be carried out even if acpi_backlight=vendor
is passed in the kernel command line which turns out to break things
at least on one system.

Thanks!


---

Rafael J. Wysocki (1):
  Revert "ACPI / video: Always call acpi_video_init_brightness() on init"

---

 drivers/acpi/video.c |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

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


Re: [PATCH v3 3/5] clk: Add common __clk_get(), __clk_put() implementations

2013-08-24 Thread Sylwester Nawrocki

On 08/24/2013 01:13 AM, Russell King - ARM Linux wrote:

On Fri, Aug 23, 2013 at 05:03:45PM +0200, Sylwester Nawrocki wrote:

>  This patch adds common __clk_get(), __clk_put() clkdev helpers which
>  replace their platform specific counterparts when the common clock
>  API is enabled.
>
>  The owner module pointer field is added to struct clk so a reference
>  to the clock supplier module can be taken by the clock consumers.
>
>  Signed-off-by: Sylwester Nawrocki
>  Signed-off-by: Kyungmin Park


I'm mostly happy with this now.


>  +int __clk_get(struct clk *clk)
>  +{
>  + if (clk&&  !try_module_get(clk->owner))
>  + return 0;
>  +
>  + return 1;
>  +}
>  +EXPORT_SYMBOL(__clk_get);
>  +
>  +void __clk_put(struct clk *clk)
>  +{
>  + if (WARN_ON_ONCE(IS_ERR(clk)))
>  + return;
>  +
>  + if (clk)
>  + module_put(clk->owner);
>  +}
>  +EXPORT_SYMBOL(__clk_put);


Why are these exported?  clkdev can only be built into the kernel, as can
the common clk framework - they can't be modular.  So why would a module
wish to access these directly?


I must have been mislead by the fact that some ARM sub-architecture exports
those, have added them initially and then didn't think enough about it and
left these in. Actually, at some point I noticed the exporting is not 
needed,
but never did get around to remove it. Thanks. The updated series to 
follow.





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/12] target: Add memory allocation for bidirectional commands

2013-08-24 Thread Christoph Hellwig
>  static int
> +transport_generic_get_mem_bidi(struct se_cmd *cmd)

Except for the fields touched in struct se_cmd this is a duplication
of transport_generic_get_mem.  I'd suggest to factor that one into
a new helper:

static int
target_alloc_sgl(struct scatterlist **sgl, unsigned int **nents,
u32 length, gfp_t gfp_mask)
{
..
}

and then call that one from transport_generic_new_cmd directly,
including opencoding the actual BIDI case there as a first step.

If we go down your proposed route for COMPARE and WRITE we'd also
allocate that buffer there, although I think there is a more elegant
way to do that, but more on that later.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/5] clk: clock deregistration support

2013-08-24 Thread Sylwester Nawrocki
This patch series implements clock deregistration in the common clock
framework. This is required for proper support of clock suppliers as
loadable modules.  Previous version of this series can be found at [1].

Changes since v3:
 - dropped exporting of __clk_get(), __clk_put(),
 - replaced WARN_ON() with WARN_ON_ONCE() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - reordered the patches so the race condition is fixed before it can
   actually cause any issues,
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put(),
 - added patch adding actual asignment of clk->owner; more details are
   discussed in that specific patch.

Changes since v1:
 - moved of_clk_{lock, unlock}, __of_clk_get_from_provider() function
   declaractions to a local header,
 - renamed clk_dummy_* to clk_nodrv_*.


[1] https://lkml.org/lkml/2013/8/23/289

Sylwester Nawrocki (5):
  clk: Provide not locked variant of of_clk_get_from_provider()
  clkdev: Fix race condition in clock lookup from device tree
  clk: Add common __clk_get(), __clk_put() implementations
  clk: Assign module owner of a clock being registered
  clk: Implement clk_unregister

 arch/arm/include/asm/clkdev.h  |2 +
 arch/blackfin/include/asm/clkdev.h |2 +
 arch/mips/include/asm/clkdev.h |2 +
 arch/sh/include/asm/clkdev.h   |2 +
 drivers/clk/clk.c  |  187 +--
 drivers/clk/clk.h  |   16 +++
 drivers/clk/clkdev.c   |   12 ++-
 include/linux/clk-private.h|5 +
 include/linux/clk-provider.h   |2 +
 include/linux/clkdev.h |5 +
 10 files changed, 222 insertions(+), 13 deletions(-)
 create mode 100644 drivers/clk/clk.h

--
1.7.4.1

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


[PATCH v4 1/5] clk: Provide not locked variant of of_clk_get_from_provider()

2013-08-24 Thread Sylwester Nawrocki
Add helper functions for the of_clk_providers list locking and
an unlocked variant of of_clk_get_from_provider().
These functions are intended to be used in the clkdev to avoid
race condition in the device tree based clock look up in clk_get().

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Acked-by: Russell King 
---
Changes since v3:
 - none.

Changes since v2:
 - fixed typo in clk.h.

Changes since v1:
 - moved the function declaractions to a local header.
---
 drivers/clk/clk.c |   38 ++
 drivers/clk/clk.h |   16 
 2 files changed, 46 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/clk.h

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bc02037..f46444f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static DEFINE_SPINLOCK(enable_lock);
 static DEFINE_MUTEX(prepare_lock);
 
@@ -2097,7 +2099,18 @@ static const struct of_device_id __clk_of_table_sentinel
__used __section(__clk_of_table_end);
 
 static LIST_HEAD(of_clk_providers);
-static DEFINE_MUTEX(of_clk_lock);
+static DEFINE_MUTEX(of_clk_mutex);
+
+/* of_clk_provider list locking helpers */
+void of_clk_lock(void)
+{
+   mutex_lock(_clk_mutex);
+}
+
+void of_clk_unlock(void)
+{
+   mutex_unlock(_clk_mutex);
+}
 
 struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 void *data)
@@ -2141,9 +2154,9 @@ int of_clk_add_provider(struct device_node *np,
cp->data = data;
cp->get = clk_src_get;
 
-   mutex_lock(_clk_lock);
+   mutex_lock(_clk_mutex);
list_add(>link, _clk_providers);
-   mutex_unlock(_clk_lock);
+   mutex_unlock(_clk_mutex);
pr_debug("Added clock from %s\n", np->full_name);
 
return 0;
@@ -2158,7 +2171,7 @@ void of_clk_del_provider(struct device_node *np)
 {
struct of_clk_provider *cp;
 
-   mutex_lock(_clk_lock);
+   mutex_lock(_clk_mutex);
list_for_each_entry(cp, _clk_providers, link) {
if (cp->node == np) {
list_del(>link);
@@ -2167,24 +2180,33 @@ void of_clk_del_provider(struct device_node *np)
break;
}
}
-   mutex_unlock(_clk_lock);
+   mutex_unlock(_clk_mutex);
 }
 EXPORT_SYMBOL_GPL(of_clk_del_provider);
 
-struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec)
 {
struct of_clk_provider *provider;
struct clk *clk = ERR_PTR(-ENOENT);
 
/* Check if we have such a provider in our array */
-   mutex_lock(_clk_lock);
list_for_each_entry(provider, _clk_providers, link) {
if (provider->node == clkspec->np)
clk = provider->get(clkspec, provider->data);
if (!IS_ERR(clk))
break;
}
-   mutex_unlock(_clk_lock);
+
+   return clk;
+}
+
+struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+{
+   struct clk *clk;
+
+   mutex_lock(_clk_mutex);
+   clk = __of_clk_get_from_provider(clkspec);
+   mutex_unlock(_clk_mutex);
 
return clk;
 }
diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
new file mode 100644
index 000..795cc9f
--- /dev/null
+++ b/drivers/clk/clk.h
@@ -0,0 +1,16 @@
+/*
+ * linux/drivers/clk/clk.h
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec);
+void of_clk_lock(void);
+void of_clk_unlock(void);
+#endif
-- 
1.7.4.1

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


[PATCH] proc: kill the extra proc_readfd_common()->dir_emit_dots()

2013-08-24 Thread Oleg Nesterov
proc_readfd_common() does dir_emit_dots() twice in a row,
we need to do this only once.

Signed-off-by: Oleg Nesterov 
---
 fs/proc/fd.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 75f2890..0ff80f9 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -230,8 +230,6 @@ static int proc_readfd_common(struct file *file, struct 
dir_context *ctx,
 
if (!dir_emit_dots(file, ctx))
goto out;
-   if (!dir_emit_dots(file, ctx))
-   goto out;
files = get_files_struct(p);
if (!files)
goto out;
-- 
1.5.5.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 v4 5/5] clk: Implement clk_unregister

2013-08-24 Thread Sylwester Nawrocki
clk_unregister() is currently not implemented and it is required when
a clock provider module needs to be unloaded.

Normally the clock supplier module is prevented to be unloaded by
taking reference on the module in clk_get().

For cases when the clock supplier module deinitializes despite the
consumers of its clocks holding a reference on the module, e.g. when
the driver is unbound through "unbind" sysfs attribute, there are
empty clock ops added. These ops are assigned temporarily to struct
clk and used until all consumers release the clock, to avoid invoking
callbacks from the module which just got removed.

Signed-off-by: Jiada Wang 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v3:
 - Use WARN_ON_ONCE() rather than WARN_ON() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - none.

Changes since RFC v1:
 - renamed clk_dummy_* to clk_nodrv_*.
---
 drivers/clk/clk.c   |  123 +-
 include/linux/clk-private.h |2 +
 2 files changed, 122 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cf5765a..df41052 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -344,6 +344,21 @@ out:
return ret;
 }
 
+ /**
+ * clk_debug_unregister - remove a clk node from the debugfs clk tree
+ * @clk: the clk being removed from the debugfs clk tree
+ *
+ * Dynamically removes a clk and all it's children clk nodes from the
+ * debugfs clk tree if clk->dentry points to debugfs created by
+ * clk_debug_register in __clk_init.
+ *
+ * Caller must hold prepare_lock.
+ */
+static void clk_debug_unregister(struct clk *clk)
+{
+   debugfs_remove_recursive(clk->dentry);
+}
+
 /**
  * clk_debug_reparent - reparent clk node in the debugfs clk tree
  * @clk: the clk being reparented
@@ -434,6 +449,9 @@ static inline int clk_debug_register(struct clk *clk) { 
return 0; }
 static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
 {
 }
+static inline void clk_debug_unregister(struct clk *clk)
+{
+}
 #endif
 
 /* caller must hold prepare_lock */
@@ -1764,6 +1782,7 @@ int __clk_init(struct device *dev, struct clk *clk)
 
clk_debug_register(clk);
 
+   kref_init(>ref);
 out:
clk_prepare_unlock();
 
@@ -1899,13 +1918,106 @@ fail_out:
 }
 EXPORT_SYMBOL_GPL(clk_register);
 
+/*
+ * Free memory allocated for a clock.
+ * Caller must hold prepare_lock.
+ */
+static void __clk_release(struct kref *ref)
+{
+   struct clk *clk = container_of(ref, struct clk, ref);
+   int i = clk->num_parents;
+
+   kfree(clk->parents);
+   while (--i >= 0)
+   kfree(clk->parent_names[i]);
+
+   kfree(clk->parent_names);
+   kfree(clk->name);
+   kfree(clk);
+}
+
+/*
+ * Empty clk_ops for unregistered clocks. These are used temporarily
+ * after clk_unregister() was called on a clock and until last clock
+ * consumer calls clk_put() and the struct clk object is freed.
+ */
+static int clk_nodrv_prepare_enable(struct clk_hw *hw)
+{
+   return -ENXIO;
+}
+
+static void clk_nodrv_disable_unprepare(struct clk_hw *hw)
+{
+   WARN_ON_ONCE(1);
+}
+
+static int clk_nodrv_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   return -ENXIO;
+}
+
+static int clk_nodrv_set_parent(struct clk_hw *hw, u8 index)
+{
+   return -ENXIO;
+}
+
+static const struct clk_ops clk_nodrv_ops = {
+   .enable = clk_nodrv_prepare_enable,
+   .disable= clk_nodrv_disable_unprepare,
+   .prepare= clk_nodrv_prepare_enable,
+   .unprepare  = clk_nodrv_disable_unprepare,
+   .set_rate   = clk_nodrv_set_rate,
+   .set_parent = clk_nodrv_set_parent,
+};
+
 /**
  * clk_unregister - unregister a currently registered clock
  * @clk: clock to unregister
- *
- * Currently unimplemented.
  */
-void clk_unregister(struct clk *clk) {}
+void clk_unregister(struct clk *clk)
+{
+   unsigned long flags;
+
+   clk_prepare_lock();
+
+   if (!clk || IS_ERR(clk)) {
+   pr_err("%s: invalid clock: %p\n", __func__, clk);
+   goto out;
+   }
+
+   if (clk->ops == _nodrv_ops) {
+   pr_err("%s: unregistered clock: %s\n", __func__, clk->name);
+   goto out;
+   }
+   /*
+* Assign empty clock ops for consumers that might still hold
+* a reference to this clock.
+*/
+   flags = clk_enable_lock();
+   clk->ops = _nodrv_ops;
+   clk_enable_unlock(flags);
+
+   if (!hlist_empty(>children)) {
+   struct clk *child;
+
+   /* Reparent all children to the orphan list. */
+   hlist_for_each_entry(child, >children, child_node)
+   clk_set_parent(child, NULL);
+   }
+
+   clk_debug_unregister(clk);
+
+   hlist_del_init(>child_node);
+
+   if (clk->prepare_count)
+   

[PATCH v4 4/5] clk: Assign module owner of a clock being registered

2013-08-24 Thread Sylwester Nawrocki
Assign module owner of a driver of a device passed to _clk_register()
and __clk_register() functions so the module_{get,put} calls in
__clk_get(), __clk_put() can have required effect.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Initially I had an 'owner' field added to struct clk_init_data so it can
be set explicitly in clock providers.  But this required modifications
of all users of (devm_)clk_register() as struct clk_init_data instance
was in most cases an unitialized stack variable.  This would also require
adding yet another argument to various clk_register_* functions
registering the standard clocks.  So I went for assigning clk->owner from
dev->driver->owner.  The disadvantages are that dereferencing dev->driver
may be potentially unsafe when not holding struct device::mutex.  And
there might be cases where clk->owner will need to be NULL.  One option
is to set dev argument of clk_register_*() to NULL for that, but it
predates devm_*.

Presumably a requirement could be added that callers of clk_register*()
must ensure dev->driver won't change during a call to these functions ?
---
 drivers/clk/clk.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8ccc1cd..cf5765a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1799,6 +1799,10 @@ struct clk *__clk_register(struct device *dev, struct 
clk_hw *hw)
clk->flags = hw->init->flags;
clk->parent_names = hw->init->parent_names;
clk->num_parents = hw->init->num_parents;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
+   else
+   clk->owner = NULL;
 
ret = __clk_init(dev, clk);
if (ret)
@@ -1819,6 +1823,8 @@ static int _clk_register(struct device *dev, struct 
clk_hw *hw, struct clk *clk)
goto fail_name;
}
clk->ops = hw->init->ops;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
clk->hw = hw;
clk->flags = hw->init->flags;
clk->num_parents = hw->init->num_parents;
-- 
1.7.4.1

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


[PATCH v4 2/5] clkdev: Fix race condition in clock lookup from device tree

2013-08-24 Thread Sylwester Nawrocki
There is currently a race condition in the device tree part of clk_get()
function, since the pointer returned from of_clk_get_by_name() may become
invalid before __clk_get() call. E.g. due to the clock provider driver
remove() callback being called in between of_clk_get_by_name() and
__clk_get().

Fix this by doing both the look up and __clk_get() operations with the
clock providers list mutex held. This ensures that the clock pointer
returned from __of_clk_get_from_provider() call and passed to __clk_get()
is valid, as long as the clock supplier module first removes its clock
provider instance and then does clk_unregister() on the corresponding
clocks.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mike Turquette 
Acked-by: Russell King 
---

Changes since v2:
 - none.

Changes since v1:
 - include "clk.h".
---
 drivers/clk/clkdev.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..48f6721 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static LIST_HEAD(clocks);
 static DEFINE_MUTEX(clocks_mutex);
 
@@ -39,7 +41,13 @@ struct clk *of_clk_get(struct device_node *np, int index)
if (rc)
return ERR_PTR(rc);
 
-   clk = of_clk_get_from_provider();
+   of_clk_lock();
+   clk = __of_clk_get_from_provider();
+
+   if (!IS_ERR(clk) && !__clk_get(clk))
+   clk = ERR_PTR(-ENOENT);
+
+   of_clk_unlock();
of_node_put(clkspec.np);
return clk;
 }
@@ -157,7 +165,7 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
if (dev) {
clk = of_clk_get_by_name(dev->of_node, con_id);
-   if (!IS_ERR(clk) && __clk_get(clk))
+   if (!IS_ERR(clk))
return clk;
}
 
-- 
1.7.4.1

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


[PATCH v4 3/5] clk: Add common __clk_get(), __clk_put() implementations

2013-08-24 Thread Sylwester Nawrocki
This patch adds common __clk_get(), __clk_put() clkdev helpers which
replace their platform specific counterparts when the common clock
API is enabled.

The owner module pointer field is added to struct clk so a reference
to the clock supplier module can be taken by the clock consumers.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v3:
 - dropped exporting of __clk_get(), __clk_put().

Changes since v2:
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put();
---
 arch/arm/include/asm/clkdev.h  |2 ++
 arch/blackfin/include/asm/clkdev.h |2 ++
 arch/mips/include/asm/clkdev.h |2 ++
 arch/sh/include/asm/clkdev.h   |2 ++
 drivers/clk/clk.c  |   20 
 include/linux/clk-private.h|3 +++
 include/linux/clk-provider.h   |2 ++
 include/linux/clkdev.h |5 +
 8 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/clkdev.h b/arch/arm/include/asm/clkdev.h
index 80751c1..4e8a4b2 100644
--- a/arch/arm/include/asm/clkdev.h
+++ b/arch/arm/include/asm/clkdev.h
@@ -14,12 +14,14 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #ifdef CONFIG_HAVE_MACH_CLKDEV
 #include 
 #else
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
 #endif
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/blackfin/include/asm/clkdev.h 
b/arch/blackfin/include/asm/clkdev.h
index 9053bed..7ac2436 100644
--- a/arch/blackfin/include/asm/clkdev.h
+++ b/arch/blackfin/include/asm/clkdev.h
@@ -8,7 +8,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif
diff --git a/arch/mips/include/asm/clkdev.h b/arch/mips/include/asm/clkdev.h
index 2624754..1b3ad7b 100644
--- a/arch/mips/include/asm/clkdev.h
+++ b/arch/mips/include/asm/clkdev.h
@@ -14,8 +14,10 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/sh/include/asm/clkdev.h b/arch/sh/include/asm/clkdev.h
index 6ba9186..c419014 100644
--- a/arch/sh/include/asm/clkdev.h
+++ b/arch/sh/include/asm/clkdev.h
@@ -25,7 +25,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif /* __CLKDEV_H__ */
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f46444f..8ccc1cd 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1959,6 +1959,26 @@ void devm_clk_unregister(struct device *dev, struct clk 
*clk)
 }
 EXPORT_SYMBOL_GPL(devm_clk_unregister);
 
+/*
+ * clkdev helpers
+ */
+int __clk_get(struct clk *clk)
+{
+   if (clk && !try_module_get(clk->owner))
+   return 0;
+
+   return 1;
+}
+
+void __clk_put(struct clk *clk)
+{
+   if (WARN_ON_ONCE(IS_ERR(clk)))
+   return;
+
+   if (clk)
+   module_put(clk->owner);
+}
+
 /***clk rate change notifiers***/
 
 /**
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 8138c94..8cb1865 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -25,10 +25,13 @@
 
 #ifdef CONFIG_COMMON_CLK
 
+struct module;
+
 struct clk {
const char  *name;
const struct clk_ops*ops;
struct clk_hw   *hw;
+   struct module   *owner;
struct clk  *parent;
const char  **parent_names;
struct clk  **parents;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1f0285b..6341e79 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -141,6 +141,8 @@ struct clk_ops {
void(*init)(struct clk_hw *hw);
 };
 
+struct module;
+
 /**
  * struct clk_init_data - holds init data that's common to all clocks and is
  * shared between the clock provider and the common clock framework.
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index a6a6f60..94bad77 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -43,4 +43,9 @@ int clk_add_alias(const char *, const char *, char *, struct 
device *);
 int clk_register_clkdev(struct clk *, const char *, const char *, ...);
 int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
 
+#ifdef CONFIG_COMMON_CLK
+int __clk_get(struct clk *clk);
+void __clk_put(struct clk *clk);
+#endif
+
 #endif
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH] proc: kill the extra proc_readfd_common()->dir_emit_dots()

2013-08-24 Thread Al Viro
On Sat, Aug 24, 2013 at 05:14:34PM +0200, Oleg Nesterov wrote:
> proc_readfd_common() does dir_emit_dots() twice in a row,
> we need to do this only once.

I really wonder how that one had happened - it's harmless, fortunately,
but...  Ugh.  Applied, will push to Linus today
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Introduce atomic MMIO modify

2013-08-24 Thread Ezequiel Garcia
This patchset introduces an atomic MMIO modify API.
The motivation for adding this is to allow cheap, infrastructure-less,
thread-safe access to an MMIO region, even in very early scenarios.

The chosen mask/set semantic (proposed by Russell King) is clean and flexible
enough and matches the regmap_update_bits() prototype. Consistency is good.

This series adds a simple arch-generic implementation in a new lib/atomicio.c
file. On top of that it implements an ARM-optimized variant following Will
Deacon's suggestions, that take advantage of ARM relaxed read/write functions.

Finally, just to show a few usage for this function, last two patches show
how this would solve one of the current shared-registers issues.

Since this 4th version is no longer ARM-specific but kernel-wide, and perhaps
new reviewers might jump in, please read the previous discussion on why this
is needed and why we cannot use a regmap API.

v1: https://lkml.org/lkml/2013/8/10/75
v2: http://comments.gmane.org/gmane.linux.ports.arm.kernel/261879
v3: http://www.spinics.net/lists/arm-kernel/msg269263.html

Thoughts?

Changes from v3:
* Implemented an arch-generic atomic_io_modify(), as suggested by Baruch
  and Catalin.

* Add an ARM-specific variant, using relaxed R/W as Will suggested.

* Replaced spin_locks by raw_spin_locks, to protect the registers
  even on RT.

* Fixed two stupid typos.

Changes from v2:
* As suggested by Will Deacon, dropped the iowmb() barrier
  and use relaxed variants instead. See Will's explanation for
  details: http://www.spinics.net/lists/arm-kernel/msg268775.html

* Use spin_{}_irqsave/restore to allow irq-context usage
  also suggested by Will Deacon.

* Re-worked the API semantics as proposed by Russell King.

Changes from v1:
* Added an io barrier iowmb() as suggested by Will Deacon,
  to ensure the writel gets completed before the spin_unlock().

Ezequiel Garcia (4):
  lib: Introduce atomic MMIO modify
  ARM: Add atomic_io_modify optimized routines
  clocksource: orion: Use atomic access for shared registers
  watchdog: orion: Use atomic access for shared registers

 arch/arm/include/asm/io.h|  4 
 arch/arm/kernel/io.c | 29 +
 drivers/clocksource/time-orion.c | 29 +++--
 drivers/watchdog/orion_wdt.c |  8 ++--
 include/linux/io.h   |  5 +
 lib/Makefile |  2 +-
 lib/atomicio.c   | 27 +++
 7 files changed, 79 insertions(+), 25 deletions(-)
 create mode 100644 lib/atomicio.c

-- 
1.8.1.5

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


[PATCH v4 1/4] lib: Introduce atomic MMIO modify

2013-08-24 Thread Ezequiel Garcia
Some platforms have MMIO regions that are shared across orthogonal
subsystems. This commit implements a possible solution for the
thread-safe access of such regions through a spinlock-protected API.

Concurrent access is protected with a single spinlock for the
entire MMIO address space. While this protects shared-registers,
it also serializes access to unrelated/unshared registers.

Signed-off-by: Ezequiel Garcia 
---
 include/linux/io.h |  5 +
 lib/Makefile   |  2 +-
 lib/atomicio.c | 27 +++
 3 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 lib/atomicio.c

diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c331dcb 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
 #define arch_phys_wc_add arch_phys_wc_add
 #endif
 
+#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
+/* Atomic MMIO-wide IO modify */
+extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
+#endif
+
 #endif /* _LINUX_IO_H */
diff --git a/lib/Makefile b/lib/Makefile
index 7baccfd..695d6e2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
 proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
 is_single_threaded.o plist.o decompress.o kobject_uevent.o \
-earlycpio.o percpu-refcount.o
+earlycpio.o percpu-refcount.o atomicio.o
 
 obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
 lib-$(CONFIG_MMU) += ioremap.o
diff --git a/lib/atomicio.c b/lib/atomicio.c
new file mode 100644
index 000..1750f9d
--- /dev/null
+++ b/lib/atomicio.c
@@ -0,0 +1,27 @@
+#include 
+#include 
+
+#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
+/*
+ * Generic atomic MMIO modify.
+ *
+ * Allows thread-safe access to registers shared by unrelated subsystems.
+ * The access is protected by a single MMIO-wide lock.
+ *
+ * Optimized variants can be implemented on a per-architecture basis.
+ */
+static DEFINE_RAW_SPINLOCK(__io_lock);
+void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
+{
+   unsigned long flags;
+   u32 value;
+
+   raw_spin_lock_irqsave(&__io_lock, flags);
+   value = readl(reg) & ~mask;
+   value |= (set & mask);
+   writel(value, reg);
+   raw_spin_unlock_irqrestore(&__io_lock, flags);
+
+}
+EXPORT_SYMBOL(atomic_io_modify);
+#endif
-- 
1.8.1.5

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


[PATCH v4 2/4] ARM: Add atomic_io_modify optimized routines

2013-08-24 Thread Ezequiel Garcia
Implement arch-specific atomic_io_modify and atomic_io_modify_relaxed,
which are based on writel/readl_relaxed and writel_relaxed/readl_relaxed,
respectively.
In both cases, by relaxing the readl, perfomance can be improved.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/include/asm/io.h |  4 
 arch/arm/kernel/io.c  | 29 +
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d070741..53637b6 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -397,5 +397,9 @@ extern int devmem_is_allowed(unsigned long pfn);
 extern void register_isa_ports(unsigned int mmio, unsigned int io,
   unsigned int io_shift);
 
+#define __HAVE_ARCH_ATOMIC_IO_MODIFY
+extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
+extern void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set);
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_ARM_IO_H */
diff --git a/arch/arm/kernel/io.c b/arch/arm/kernel/io.c
index dcd5b4d..a8c9c9b 100644
--- a/arch/arm/kernel/io.c
+++ b/arch/arm/kernel/io.c
@@ -1,6 +1,35 @@
 #include 
 #include 
 #include 
+#include 
+
+static DEFINE_RAW_SPINLOCK(__io_lock);
+
+void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set)
+{
+   unsigned long flags;
+   u32 value;
+
+   raw_spin_lock_irqsave(&__io_lock, flags);
+   value = readl_relaxed(reg) & ~mask;
+   value |= (set & mask);
+   writel_relaxed(value, reg);
+   raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify_relaxed);
+
+void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
+{
+   unsigned long flags;
+   u32 value;
+
+   raw_spin_lock_irqsave(&__io_lock, flags);
+   value = readl_relaxed(reg) & ~mask;
+   value |= (set & mask);
+   writel(value, reg);
+   raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify);
 
 /*
  * Copy data from IO memory space to "real" memory space.
-- 
1.8.1.5

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


[PATCH v4 3/4] clocksource: orion: Use atomic access for shared registers

2013-08-24 Thread Ezequiel Garcia
Replace the driver-specific thread-safe shared register API
by the recently introduced atomic_io_modify().

Signed-off-by: Ezequiel Garcia 
---
 drivers/clocksource/time-orion.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index ecbeb68..f69f697 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -35,20 +36,6 @@
 #define ORION_ONESHOT_MAX  0xfffe
 
 static void __iomem *timer_base;
-static DEFINE_SPINLOCK(timer_ctrl_lock);
-
-/*
- * Thread-safe access to TIMER_CTRL register
- * (shared with watchdog timer)
- */
-void orion_timer_ctrl_clrset(u32 clr, u32 set)
-{
-   spin_lock(_ctrl_lock);
-   writel((readl(timer_base + TIMER_CTRL) & ~clr) | set,
-   timer_base + TIMER_CTRL);
-   spin_unlock(_ctrl_lock);
-}
-EXPORT_SYMBOL(orion_timer_ctrl_clrset);
 
 /*
  * Free-running clocksource handling.
@@ -68,7 +55,8 @@ static int orion_clkevt_next_event(unsigned long delta,
 {
/* setup and enable one-shot timer */
writel(delta, timer_base + TIMER1_VAL);
-   orion_timer_ctrl_clrset(TIMER1_RELOAD_EN, TIMER1_EN);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER1_RELOAD_EN | TIMER1_EN, TIMER1_EN);
 
return 0;
 }
@@ -80,10 +68,13 @@ static void orion_clkevt_mode(enum clock_event_mode mode,
/* setup and enable periodic timer at 1/HZ intervals */
writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD);
writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL);
-   orion_timer_ctrl_clrset(0, TIMER1_RELOAD_EN | TIMER1_EN);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER1_RELOAD_EN | TIMER1_EN,
+   TIMER1_RELOAD_EN | TIMER1_EN);
} else {
/* disable timer */
-   orion_timer_ctrl_clrset(TIMER1_RELOAD_EN | TIMER1_EN, 0);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER1_RELOAD_EN | TIMER1_EN, 0);
}
 }
 
@@ -131,7 +122,9 @@ static void __init orion_timer_init(struct device_node *np)
/* setup timer0 as free-running clocksource */
writel(~0, timer_base + TIMER0_VAL);
writel(~0, timer_base + TIMER0_RELOAD);
-   orion_timer_ctrl_clrset(0, TIMER0_RELOAD_EN | TIMER0_EN);
+   atomic_io_modify(timer_base + TIMER_CTRL,
+   TIMER0_RELOAD_EN | TIMER0_EN,
+   TIMER0_RELOAD_EN | TIMER0_EN);
clocksource_mmio_init(timer_base + TIMER0_VAL, "orion_clocksource",
  clk_get_rate(clk), 300, 32,
  clocksource_mmio_readl_down);
-- 
1.8.1.5

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


[PATCH v4 4/4] watchdog: orion: Use atomic access for shared registers

2013-08-24 Thread Ezequiel Garcia
Since the timer control register is shared with the clocksource driver,
use the recently introduced atomic_io_clear_set() to access such register.

Signed-off-by: Ezequiel Garcia 
---
 drivers/watchdog/orion_wdt.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 4ea5fcc..cfc037d 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -73,9 +73,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
writel(~WDT_INT_REQ, BRIDGE_CAUSE);
 
/* Enable watchdog timer */
-   reg = readl(wdt_reg + TIMER_CTRL);
-   reg |= WDT_EN;
-   writel(reg, wdt_reg + TIMER_CTRL);
+   atomic_io_modify(wdt_reg + TIMER_CTRL, WDT_EN, WDT_EN);
 
/* Enable reset on watchdog */
reg = readl(RSTOUTn_MASK);
@@ -98,9 +96,7 @@ static int orion_wdt_stop(struct watchdog_device *wdt_dev)
writel(reg, RSTOUTn_MASK);
 
/* Disable watchdog timer */
-   reg = readl(wdt_reg + TIMER_CTRL);
-   reg &= ~WDT_EN;
-   writel(reg, wdt_reg + TIMER_CTRL);
+   atomic_io_modify(wdt_reg + TIMER_CTRL, WDT_EN, 0);
 
spin_unlock(_lock);
return 0;
-- 
1.8.1.5

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


[PATCH 1/1 V2] AMD64_EDAC: Fix incorrect wrap arounds due to left shift beyond 32 bits.

2013-08-24 Thread Aravind Gopalakrishnan
Link to the bug report:
http://marc.info/?l=linux-edac=137692201732220=2

dct_base and dct_limit obtain 32 bit register values when they read
their respective pci config space registers. A left shift beyond 32 bits will
cause them to wrap around. Similar case for chan_addr as can be seen from
the bug report. In the patch, we rectify this by casting chan_addr to
u64 and by comparing dct_base and dct_limit against (sys_addr >> 27)

Change from V1:
- Fix chan_offset to use left-shifted version of dct_base.

Signed-off-by: Aravind Gopalakrishnan 

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index b86228c..64cfcaf 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1558,11 +1558,12 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
}
 
/* Verify sys_addr is within DCT Range. */
-   dct_base = (dct_sel_baseaddr(pvt) << 27);
-   dct_limit = (((dct_cont_limit_reg >> 11) & 0x1FFF) << 27) | 0x7FF;
+   dct_base = (u64) dct_sel_baseaddr(pvt);
+   dct_limit = (dct_cont_limit_reg >> 11) & 0x1FFF;
 
if (!(dct_cont_base_reg & BIT(0)) &&
-   !(dct_base <= sys_addr && dct_limit >= sys_addr))
+   !(dct_base <= (sys_addr >> 27) &&
+ dct_limit >= (sys_addr >> 27)))
return -EINVAL;
 
/* Verify number of dct's that participate in channel interleaving. */
@@ -1584,7 +1585,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
if (leg_mmio_hole && (sys_addr >= BIT_64(32)))
chan_offset = dhar_offset;
else
-   chan_offset = dct_base;
+   chan_offset = dct_base << 27;
 
chan_addr = sys_addr - chan_offset;
 
@@ -1614,7 +1615,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
amd64_read_pci_cfg(pvt->F1,
   DRAM_CONT_HIGH_OFF + (int) channel * 4,
   );
-   chan_addr +=  ((tmp >> 11) & 0xfff) << 27;
+   chan_addr +=  (u64) ((tmp >> 11) & 0xfff) << 27;
}
 
f15h_select_dct(pvt, channel);
-- 
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] MAX7301 GPIO: Reverting "Do not force SPI speed when using OF Platform"

2013-08-24 Thread christophe leroy


Le 23/08/2013 19:47, Linus Walleij a écrit :

On Tue, Aug 20, 2013 at 8:29 AM, Christophe Leroy
 wrote:


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

Signed-off-by: Christophe Leroy 

Patch applied with Roland's ACK.

But seriously, this is the kind of stuff that scares me a lot,
when developers merge dependent patches into two different
trees, that is just a recipe for chaos and me getting flamed
by other kernel maintainers.

There is *no* mention of this dependency in the other
commit.


I'm very sorry for this mishap. If I didn't mention it in the commit, 
this is because when I developped the change I submitted you a few 
months back, I was not aware of that other patch. It looks like it has 
been in my company's kernel tree for years, therefore in my mind it was 
a standard feature of the kernel. It looks like nobody had tried and 
submitted it for inclusion previously.
That's thanks to Roland that I discovered it was indeed not a standard 
feature, then I tried to submit that patch a week ago and it was 
rejected by Stephen Warren for good reason.

For me it is a lesson learnt, and I'll make sure it doesn't happen again.

Regards
Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Itsuki Request for a business proposal? -

2013-08-24 Thread Suki Kaito



August 22 2013

To Whom It May Concern

Konnichiwa ! It is with respect to directly write this proposal letter  
to you, informing you of a potential business proposal project that  
can be established from your country with your help, which will  
mutually be profitable to us having no risk involved.


If you are agreeable to this business proposal, please indicate your  
interest by giving me a direct response email. Feel free to contact me  
via electronic mail or telephone for further discussion. I look  
forward to hearing from you positively on this proposal.


Domo arigato !
Suki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] spi: simplify devm_request_mem_region/devm_ioremap

2013-08-24 Thread Julia Lawall
From: Julia Lawall 

Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.

This was done using a combination of the semantic patches
devm_ioremap_resource.cocci and devm_request_and_ioremap.cocci, found in
the scripts/coccinelle/api directory.

This patch also removes the label exit_busy, to use the error code returned
by the failing operation, rather than always -EBUSY.

Signed-off-by: Julia Lawall 

---
 drivers/spi/spi-altera.c  |   17 +
 drivers/spi/spi-oc-tiny.c |   22 +-
 2 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index 8a6bb37..63d25e6 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -234,15 +234,11 @@ static int altera_spi_probe(struct platform_device *pdev)
 
/* find and map our resources */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   goto exit_busy;
-   if (!devm_request_mem_region(>dev, res->start, resource_size(res),
-pdev->name))
-   goto exit_busy;
-   hw->base = devm_ioremap_nocache(>dev, res->start,
-   resource_size(res));
-   if (!hw->base)
-   goto exit_busy;
+   hw->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(hw->base)) {
+   err = PTR_ERR(hw->base);
+   goto exit;
+   }
/* program defaults into the registers */
hw->imr = 0;/* disable spi interrupts */
writel(hw->imr, hw->base + ALTERA_SPI_CONTROL);
@@ -269,9 +265,6 @@ static int altera_spi_probe(struct platform_device *pdev)
dev_info(>dev, "base %p, irq %d\n", hw->base, hw->irq);
 
return 0;
-
-exit_busy:
-   err = -EBUSY;
 exit:
spi_master_put(master);
return err;
diff --git a/drivers/spi/spi-oc-tiny.c b/drivers/spi/spi-oc-tiny.c
index 58deb79..d36ba90 100644
--- a/drivers/spi/spi-oc-tiny.c
+++ b/drivers/spi/spi-oc-tiny.c
@@ -315,15 +315,11 @@ static int tiny_spi_probe(struct platform_device *pdev)
 
/* find and map our resources */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   goto exit_busy;
-   if (!devm_request_mem_region(>dev, res->start, resource_size(res),
-pdev->name))
-   goto exit_busy;
-   hw->base = devm_ioremap_nocache(>dev, res->start,
-   resource_size(res));
-   if (!hw->base)
-   goto exit_busy;
+   hw->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(hw->base)) {
+   err = PTR_ERR(hw->base);
+   goto exit;
+   }
/* irq is optional */
hw->irq = platform_get_irq(pdev, 0);
if (hw->irq >= 0) {
@@ -337,8 +333,10 @@ static int tiny_spi_probe(struct platform_device *pdev)
if (platp) {
hw->gpio_cs_count = platp->gpio_cs_count;
hw->gpio_cs = platp->gpio_cs;
-   if (platp->gpio_cs_count && !platp->gpio_cs)
-   goto exit_busy;
+   if (platp->gpio_cs_count && !platp->gpio_cs) {
+   err = -EBUSY;
+   goto exit;
+   }
hw->freq = platp->freq;
hw->baudwidth = platp->baudwidth;
} else {
@@ -365,8 +363,6 @@ static int tiny_spi_probe(struct platform_device *pdev)
 exit_gpio:
while (i-- > 0)
gpio_free(hw->gpio_cs[i]);
-exit_busy:
-   err = -EBUSY;
 exit:
spi_master_put(master);
return err;

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


[PATCH 0/2] simplify devm_request_mem_region/devm_ioremap

2013-08-24 Thread Julia Lawall
Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.

The semantic patch used to perform this transformation is as follows:
(http://coccinelle.lip6.fr/)

// 
@r@
expression dev,res,size,name,base;
identifier l;
@@

-if (!devm_request_mem_region(dev, res->start, size, name))
- { ... \(goto l;\|return ...;\) }
... when != res->start
base =
(
-devm_ioremap(dev,res->start,size)
+devm_request_and_ioremap(dev,res)
|
-devm_ioremap_nocache(dev,res->start,size)
+devm_request_and_ioremap(dev,res)
)
... when any
when != res->start

@@
expression pdev,res,n,r.base,e1,e2;
identifier l,f,res1;
type T;
@@

(
(
  T res1 = f(pdev, IORESOURCE_MEM, n);
|
  res1 = f(pdev, IORESOURCE_MEM, n);
)
- if (res1 == NULL) { ... \(goto l;\|return ...;\) }
  base = devm_request_and_ioremap(e1, res1);
|
(
- res = f(pdev, IORESOURCE_MEM, n);
|
  T res1
-  = f(pdev, IORESOURCE_MEM, n)
  ;
)
  ... when != res
(
- if (res == NULL) { ... \(goto l;\|return ...;\) }
|
 if (
- res == NULL ||
  e2
) { ... \(goto l;\|return ...;\) }
)
  ... when != res
+ res = f(pdev, IORESOURCE_MEM, n);
  base = devm_request_and_ioremap(e1, res);
)

@@
expression r.base, dev, res;
@@

base = 
- devm_request_and_ioremap
+ devm_ioremap_resource
 (dev, res);
 ...
 if (
-base == NULL
+IS_ERR(base)
 || ...) {
<...
-   return ...;
+   return PTR_ERR(base);
...>
 }

@@
expression r.base, dev, res;
@@

base = 
- devm_request_and_ioremap
+ devm_ioremap_resource
 (dev, res);

@@
expression r.base, E, ret;
identifier l;
@@

 base = devm_ioremap_resource(...);
 ...
 if (IS_ERR(base) || ...) {
... when any
-   ret = E;
+   ret = PTR_ERR(base);
...
(
return ret;
|
goto l;
)
 }

@@
expression r.base;
@@

 base = devm_ioremap_resource(...);
 ...
 if (IS_ERR(base) || ...) {
<...
-   \(dev_dbg\|dev_warn\|dev_err\|pr_debug\|pr_err\|DRM_ERROR\)(...);
...>
 }

@@
expression r.base;
identifier l;
@@

 base = devm_ioremap_resource(...);
 ...
 if (IS_ERR(base) || ...)
-{
(
return ...;
|
goto l;
)
-}
// 


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


[PATCH 2/2] rtc: simplify devm_request_mem_region/devm_ioremap

2013-08-24 Thread Julia Lawall
From: Julia Lawall 

Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource.  The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.

This was done using a combination of the semantic patches
devm_ioremap_resource.cocci and devm_request_and_ioremap.cocci, found in
the scripts/coccinelle/api directory.

In rtc-lpc32xx.c and rtc-mv.c, the local variable size is no longer needed.

In rtc-ds1511.c and rtc-ds1742.c, the size field of the local structure is
not useful any more, and is deleted.

Signed-off-by: Julia Lawall 

---
 drivers/rtc/rtc-ds1553.c   |   13 -
 drivers/rtc/rtc-ep93xx.c   |   14 +++---
 drivers/rtc/rtc-imxdi.c|   16 
 drivers/rtc/rtc-lpc32xx.c  |   24 
 drivers/rtc/rtc-mv.c   |   17 -
 drivers/rtc/rtc-mxc.c  |   14 --
 drivers/rtc/rtc-stk17ta8.c |   15 +--
 drivers/rtc/rtc-tx4939.c   |   14 --
 drivers/rtc/rtc-ds1511.c   |   17 +
 drivers/rtc/rtc-ds1742.c   |   18 ++
 10 files changed, 43 insertions(+), 119 deletions(-)

diff --git a/drivers/rtc/rtc-ds1553.c b/drivers/rtc/rtc-ds1553.c
index 8c6c952..fd31571 100644
--- a/drivers/rtc/rtc-ds1553.c
+++ b/drivers/rtc/rtc-ds1553.c
@@ -285,19 +285,14 @@ static int ds1553_rtc_probe(struct platform_device *pdev)
void __iomem *ioaddr;
int ret = 0;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENODEV;
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
-   if (!devm_request_mem_region(>dev, res->start, RTC_REG_SIZE,
-   pdev->name))
-   return -EBUSY;
 
-   ioaddr = devm_ioremap(>dev, res->start, RTC_REG_SIZE);
-   if (!ioaddr)
-   return -ENOMEM;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ioaddr = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(ioaddr))
+   return PTR_ERR(ioaddr);
pdata->ioaddr = ioaddr;
pdata->irq = platform_get_irq(pdev, 0);
 
diff --git a/drivers/rtc/rtc-ep93xx.c b/drivers/rtc/rtc-ep93xx.c
index 549b3c3..580e7b5 100644
--- a/drivers/rtc/rtc-ep93xx.c
+++ b/drivers/rtc/rtc-ep93xx.c
@@ -138,17 +138,9 @@ static int ep93xx_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENXIO;
-
-   if (!devm_request_mem_region(>dev, res->start,
-resource_size(res), pdev->name))
-   return -EBUSY;
-
-   ep93xx_rtc->mmio_base = devm_ioremap(>dev, res->start,
-resource_size(res));
-   if (!ep93xx_rtc->mmio_base)
-   return -ENXIO;
+   ep93xx_rtc->mmio_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(ep93xx_rtc->mmio_base))
+   return PTR_ERR(ep93xx_rtc->mmio_base);
 
pdev->dev.platform_data = ep93xx_rtc;
platform_set_drvdata(pdev, ep93xx_rtc);
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index d3a8c8e..abd7f90 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -375,24 +375,16 @@ static int __init dryice_rtc_probe(struct platform_device 
*pdev)
struct imxdi_dev *imxdi;
int rc;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENODEV;
-
imxdi = devm_kzalloc(>dev, sizeof(*imxdi), GFP_KERNEL);
if (!imxdi)
return -ENOMEM;
 
imxdi->pdev = pdev;
 
-   if (!devm_request_mem_region(>dev, res->start, resource_size(res),
-   pdev->name))
-   return -EBUSY;
-
-   imxdi->ioaddr = devm_ioremap(>dev, res->start,
-   resource_size(res));
-   if (imxdi->ioaddr == NULL)
-   return -ENOMEM;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   imxdi->ioaddr = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(imxdi->ioaddr))
+   return PTR_ERR(imxdi->ioaddr);
 
spin_lock_init(>irq_lock);
 
diff --git a/drivers/rtc/rtc-lpc32xx.c b/drivers/rtc/rtc-lpc32xx.c
index 8276ae9..bfdbcb8 100644
--- a/drivers/rtc/rtc-lpc32xx.c
+++ b/drivers/rtc/rtc-lpc32xx.c
@@ -201,16 +201,9 @@ static int lpc32xx_rtc_probe(struct platform_device *pdev)
 {
struct resource *res;
struct lpc32xx_rtc *rtc;
-   resource_size_t size;
int rtcirq;
u32 tmp;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(>dev, "Can't get memory resource\n");
-   return -ENOENT;
-   }
-
rtcirq = platform_get_irq(pdev, 0);
if 

мастерский путь спасти глазки http://linkbox.altervista.org/743884

2013-08-24 Thread ericnur
 Хороший способ спасти глазки


Re: [PATCH] amd64_edac: Correct erratum 505 range

2013-08-24 Thread Borislav Petkov
On Sat, Aug 24, 2013 at 11:25:00AM +0200, Borislav Petkov wrote:
> I've got one more patch which needs to go to tip/x86/ras for 3.12.
> It was not worth it IMO to send a pull request for a single patch so
> please apply.

Ok, one more but this is the last one, I promise! :-)

Thanks.

---
From: Aravind Gopalakrishnan 
Date: Sat, 24 Aug 2013 10:47:48 -0500
Subject: [PATCH] amd64_edac: Fix incorrect wraparounds

dct_base and dct_limit obtain 32 bit register values when they read
their respective pci config space registers. A left shift beyond 32 bits
will cause them to wrap around. Similar case for chan_addr as can be
seen from the bug report (link below). In the patch, we rectify this by
casting chan_addr to u64 and by comparing dct_base and dct_limit against
properly shifted sys_addr in order to compare the correct bits.

Reported-by: Dan Carpenter 
Signed-off-by: Aravind Gopalakrishnan 
Link: http://lkml.kernel.org/r/20130819132302.GA12171@elgon.mountain
Signed-off-by: Borislav Petkov 
---
 drivers/edac/amd64_edac.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 6952d432e62b..3c9e4e98c651 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -1558,11 +1558,12 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
}
 
/* Verify sys_addr is within DCT Range. */
-   dct_base = (dct_sel_baseaddr(pvt) << 27);
-   dct_limit = (((dct_cont_limit_reg >> 11) & 0x1FFF) << 27) | 0x7FF;
+   dct_base = (u64) dct_sel_baseaddr(pvt);
+   dct_limit = (dct_cont_limit_reg >> 11) & 0x1FFF;
 
if (!(dct_cont_base_reg & BIT(0)) &&
-   !(dct_base <= sys_addr && dct_limit >= sys_addr))
+   !(dct_base <= (sys_addr >> 27) &&
+ dct_limit >= (sys_addr >> 27)))
return -EINVAL;
 
/* Verify number of dct's that participate in channel interleaving. */
@@ -1584,7 +1585,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
if (leg_mmio_hole && (sys_addr >= BIT_64(32)))
chan_offset = dhar_offset;
else
-   chan_offset = dct_base;
+   chan_offset = dct_base << 27;
 
chan_addr = sys_addr - chan_offset;
 
@@ -1614,7 +1615,7 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt 
*pvt, unsigned range,
amd64_read_pci_cfg(pvt->F1,
   DRAM_CONT_HIGH_OFF + (int) channel * 4,
   );
-   chan_addr +=  ((tmp >> 11) & 0xfff) << 27;
+   chan_addr +=  (u64) ((tmp >> 11) & 0xfff) << 27;
}
 
f15h_select_dct(pvt, channel);
-- 
1.8.4

-- 
Regards/Gruss,
Boris.

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


Re: [PATCH] ARM: dts: add AM33XX EDMA support

2013-08-24 Thread Sergei Shtylyov

Hello.

On 08/23/2013 11:06 PM, Sebastian Andrzej Siewior wrote:


From: Matt Porter 



Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt



Joel: Drop DT entries that are non-hardware-description for now as discussed in 
[1]



[1] https://patchwork.kernel.org/patch/2226761/



Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
Signed-off-by: Sebastian Andrzej Siewior 
---
Could someone please pick this up?



  arch/arm/boot/dts/am33xx.dtsi | 12 
  1 file changed, 12 insertions(+)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = <0x4820 0x1000>;
};

+   edma: edma@4900 {


   The node should be named "dma-controller", not "edma",according to ePAPR 
section 2.2.2:


http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700 Device Driver Support

2013-08-24 Thread Joe Perches
Some whitespace and neatening fixups.
Some conversions from 4 indent tabs to normal tabs

Signed-off-by: Joe Perches 
---
Just doing this instead of commenting about spacing
again.

 drivers/net/usb/sr9700.c | 127 +--
 1 file changed, 67 insertions(+), 60 deletions(-)

diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 27c86ec..4262b9d 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -29,7 +29,7 @@ static int sr_read(struct usbnet *dev, u8 reg, u16 length, 
void *data)
int err;
 
err = usbnet_read_cmd(dev, SR_RD_REGS, SR_REQ_RD_REG,
-   0, reg, data, length);
+ 0, reg, data, length);
if ((err != length) && (err >= 0))
err = -EINVAL;
return err;
@@ -40,7 +40,7 @@ static int sr_write(struct usbnet *dev, u8 reg, u16 length, 
void *data)
int err;
 
err = usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   0, reg, data, length);
+  0, reg, data, length);
if ((err >= 0) && (err < length))
err = -EINVAL;
return err;
@@ -54,19 +54,19 @@ static int sr_read_reg(struct usbnet *dev, u8 reg, u8 
*value)
 static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
 {
return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   value, reg, NULL, 0);
+   value, reg, NULL, 0);
 }
 
 static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
 {
usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   0, reg, data, length);
+  0, reg, data, length);
 }
 
 static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
 {
usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
-   value, reg, NULL, 0);
+  value, reg, NULL, 0);
 }
 
 static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
@@ -89,7 +89,7 @@ static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
 
if (i >= SR_SHARE_TIMEOUT) {
netdev_err(dev->net, "%s write timed out!\n",
-   phy ? "phy" : "eeprom");
+  phy ? "phy" : "eeprom");
ret = -EIO;
goto out;
}
@@ -98,7 +98,8 @@ out:
return ret;
 }
 
-static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg, __le16 
*value)
+static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 *value)
 {
int ret;
 
@@ -115,14 +116,15 @@ static int sr_share_read_word(struct usbnet *dev, int 
phy, u8 reg, __le16 *value
ret = sr_read(dev, EPDR, 2, value);
 
netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
-   phy, reg, *value, ret);
+  phy, reg, *value, ret);
 
 out:
mutex_unlock(>phy_mutex);
return ret;
 }
 
-static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg, __le16 
value)
+static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg,
+  __le16 value)
 {
int ret;
 
@@ -156,7 +158,8 @@ static int sr9700_get_eeprom_len(struct net_device *dev)
return SR_EEPROM_LEN;
 }
 
-static int sr9700_get_eeprom(struct net_device *net, struct ethtool_eeprom 
*eeprom, u8 *data)
+static int sr9700_get_eeprom(struct net_device *net,
+struct ethtool_eeprom *eeprom, u8 *data)
 {
struct usbnet *dev = netdev_priv(net);
__le16 *ebuf = (__le16 *)data;
@@ -168,7 +171,8 @@ static int sr9700_get_eeprom(struct net_device *net, struct 
ethtool_eeprom *eepr
return -EINVAL;
 
for (i = 0; i < eeprom->len / 2; i++)
-   ret = sr_read_eeprom_word(dev, eeprom->offset / 2 + i, 
[i]);
+   ret = sr_read_eeprom_word(dev, eeprom->offset / 2 + i,
+ [i]);
 
return ret;
 }
@@ -199,12 +203,13 @@ static int sr_mdio_read(struct net_device *netdev, int 
phy_id, int loc)
res = le16_to_cpu(res) & ~BMSR_LSTATUS;
 
netdev_dbg(dev->net, "sr_mdio_read() phy_id=0x%02x, loc=0x%02x, 
returns=0x%04x\n",
-   phy_id, loc, res);
+  phy_id, loc, res);
 
return res;
 }
 
-static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc, int 
val)
+static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc,
+ int val)
 {
struct usbnet *dev = netdev_priv(netdev);
__le16 res = cpu_to_le16(val);
@@ -215,7 +220,7 @@ static void sr_mdio_write(struct net_device *netdev, int 
phy_id, int loc, int va
   

Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

2013-08-24 Thread richard -rw- weinberger
On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
 wrote:
> Some platforms have MMIO regions that are shared across orthogonal
> subsystems. This commit implements a possible solution for the
> thread-safe access of such regions through a spinlock-protected API.
>
> Concurrent access is protected with a single spinlock for the
> entire MMIO address space. While this protects shared-registers,
> it also serializes access to unrelated/unshared registers.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  include/linux/io.h |  5 +
>  lib/Makefile   |  2 +-
>  lib/atomicio.c | 27 +++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 lib/atomicio.c
>
> diff --git a/include/linux/io.h b/include/linux/io.h
> index f4f42fa..c331dcb 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
>  #define arch_phys_wc_add arch_phys_wc_add
>  #endif
>
> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> +/* Atomic MMIO-wide IO modify */
> +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> +#endif
> +
>  #endif /* _LINUX_IO_H */
> diff --git a/lib/Makefile b/lib/Makefile
> index 7baccfd..695d6e2 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
>  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
>  proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
>  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> -earlycpio.o percpu-refcount.o
> +earlycpio.o percpu-refcount.o atomicio.o
>
>  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
>  lib-$(CONFIG_MMU) += ioremap.o
> diff --git a/lib/atomicio.c b/lib/atomicio.c
> new file mode 100644
> index 000..1750f9d
> --- /dev/null
> +++ b/lib/atomicio.c
> @@ -0,0 +1,27 @@
> +#include 
> +#include 
> +
> +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> +/*
> + * Generic atomic MMIO modify.
> + *
> + * Allows thread-safe access to registers shared by unrelated subsystems.
> + * The access is protected by a single MMIO-wide lock.
> + *
> + * Optimized variants can be implemented on a per-architecture basis.
> + */
> +static DEFINE_RAW_SPINLOCK(__io_lock);
> +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> +{
> +   unsigned long flags;
> +   u32 value;
> +
> +   raw_spin_lock_irqsave(&__io_lock, flags);
> +   value = readl(reg) & ~mask;
> +   value |= (set & mask);
> +   writel(value, reg);
> +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> +
> +}
> +EXPORT_SYMBOL(atomic_io_modify);

Why not the default case EXPORT_SYMBOL_GPL()?

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] clk: clock deregistration support

2013-08-24 Thread Sylwester Nawrocki
This patch series implements clock deregistration in the common clock
framework.  This is required for proper support of clock suppliers as
loadable modules.  Previous version of this series can be found at [1].

Comparing to v4 only a stray struct module forward declaration has been 
removed from patch 3/5. My apologies for spamming.

Changes since v3:
 - replaced WARN_ON() with WARN_ON_ONCE() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - reordered the patches so the race condition is fixed before it can
   actually cause any issues,
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put(),
 - added patch adding actual asignment of clk->owner; more details are
   discussed in that specific patch.

Changes since v1:
 - moved of_clk_{lock, unlock}, __of_clk_get_from_provider() function
   declaractions to a local header,
 - renamed clk_dummy_* to clk_nodrv_*.

[1] https://lkml.org/lkml/2013/8/24/43

Sylwester Nawrocki (5):
  clk: Provide not locked variant of of_clk_get_from_provider()
  clkdev: Fix race condition in clock lookup from device tree
  clk: Add common __clk_get(), __clk_put() implementations
  clk: Assign module owner of a clock being registered
  clk: Implement clk_unregister

 arch/arm/include/asm/clkdev.h  |2 +
 arch/blackfin/include/asm/clkdev.h |2 +
 arch/mips/include/asm/clkdev.h |2 +
 arch/sh/include/asm/clkdev.h   |2 +
 drivers/clk/clk.c  |  187 +--
 drivers/clk/clk.h  |   16 +++
 drivers/clk/clkdev.c   |   12 ++-
 include/linux/clk-private.h|5 +
 include/linux/clkdev.h |5 +
 9 files changed, 220 insertions(+), 13 deletions(-)
 create mode 100644 drivers/clk/clk.h

-- 
1.7.4.1

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


[PATCH v5 5/5] clk: Implement clk_unregister

2013-08-24 Thread Sylwester Nawrocki
clk_unregister() is currently not implemented and it is required when
a clock provider module needs to be unloaded.

Normally the clock supplier module is prevented to be unloaded by
taking reference on the module in clk_get().

For cases when the clock supplier module deinitializes despite the
consumers of its clocks holding a reference on the module, e.g. when
the driver is unbound through "unbind" sysfs attribute, there are
empty clock ops added. These ops are assigned temporarily to struct
clk and used until all consumers release the clock, to avoid invoking
callbacks from the module which just got removed.

Signed-off-by: Jiada Wang 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v4:
 - none.

Changes since v3:
 - Use WARN_ON_ONCE() rather than WARN_ON() in clk_nodrv_disable_unprepare()
   callback.

Changes since v2:
 - none.

Changes since RFC v1:
 - renamed clk_dummy_* to clk_nodrv_*.
---
 drivers/clk/clk.c   |  123 +-
 include/linux/clk-private.h |2 +
 2 files changed, 122 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cf5765a..df41052 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -344,6 +344,21 @@ out:
return ret;
 }
 
+ /**
+ * clk_debug_unregister - remove a clk node from the debugfs clk tree
+ * @clk: the clk being removed from the debugfs clk tree
+ *
+ * Dynamically removes a clk and all it's children clk nodes from the
+ * debugfs clk tree if clk->dentry points to debugfs created by
+ * clk_debug_register in __clk_init.
+ *
+ * Caller must hold prepare_lock.
+ */
+static void clk_debug_unregister(struct clk *clk)
+{
+   debugfs_remove_recursive(clk->dentry);
+}
+
 /**
  * clk_debug_reparent - reparent clk node in the debugfs clk tree
  * @clk: the clk being reparented
@@ -434,6 +449,9 @@ static inline int clk_debug_register(struct clk *clk) { 
return 0; }
 static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
 {
 }
+static inline void clk_debug_unregister(struct clk *clk)
+{
+}
 #endif
 
 /* caller must hold prepare_lock */
@@ -1764,6 +1782,7 @@ int __clk_init(struct device *dev, struct clk *clk)
 
clk_debug_register(clk);
 
+   kref_init(>ref);
 out:
clk_prepare_unlock();
 
@@ -1899,13 +1918,106 @@ fail_out:
 }
 EXPORT_SYMBOL_GPL(clk_register);
 
+/*
+ * Free memory allocated for a clock.
+ * Caller must hold prepare_lock.
+ */
+static void __clk_release(struct kref *ref)
+{
+   struct clk *clk = container_of(ref, struct clk, ref);
+   int i = clk->num_parents;
+
+   kfree(clk->parents);
+   while (--i >= 0)
+   kfree(clk->parent_names[i]);
+
+   kfree(clk->parent_names);
+   kfree(clk->name);
+   kfree(clk);
+}
+
+/*
+ * Empty clk_ops for unregistered clocks. These are used temporarily
+ * after clk_unregister() was called on a clock and until last clock
+ * consumer calls clk_put() and the struct clk object is freed.
+ */
+static int clk_nodrv_prepare_enable(struct clk_hw *hw)
+{
+   return -ENXIO;
+}
+
+static void clk_nodrv_disable_unprepare(struct clk_hw *hw)
+{
+   WARN_ON_ONCE(1);
+}
+
+static int clk_nodrv_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   return -ENXIO;
+}
+
+static int clk_nodrv_set_parent(struct clk_hw *hw, u8 index)
+{
+   return -ENXIO;
+}
+
+static const struct clk_ops clk_nodrv_ops = {
+   .enable = clk_nodrv_prepare_enable,
+   .disable= clk_nodrv_disable_unprepare,
+   .prepare= clk_nodrv_prepare_enable,
+   .unprepare  = clk_nodrv_disable_unprepare,
+   .set_rate   = clk_nodrv_set_rate,
+   .set_parent = clk_nodrv_set_parent,
+};
+
 /**
  * clk_unregister - unregister a currently registered clock
  * @clk: clock to unregister
- *
- * Currently unimplemented.
  */
-void clk_unregister(struct clk *clk) {}
+void clk_unregister(struct clk *clk)
+{
+   unsigned long flags;
+
+   clk_prepare_lock();
+
+   if (!clk || IS_ERR(clk)) {
+   pr_err("%s: invalid clock: %p\n", __func__, clk);
+   goto out;
+   }
+
+   if (clk->ops == _nodrv_ops) {
+   pr_err("%s: unregistered clock: %s\n", __func__, clk->name);
+   goto out;
+   }
+   /*
+* Assign empty clock ops for consumers that might still hold
+* a reference to this clock.
+*/
+   flags = clk_enable_lock();
+   clk->ops = _nodrv_ops;
+   clk_enable_unlock(flags);
+
+   if (!hlist_empty(>children)) {
+   struct clk *child;
+
+   /* Reparent all children to the orphan list. */
+   hlist_for_each_entry(child, >children, child_node)
+   clk_set_parent(child, NULL);
+   }
+
+   clk_debug_unregister(clk);
+
+   hlist_del_init(>child_node);
+
+   if 

[PATCH v5 4/5] clk: Assign module owner of a clock being registered

2013-08-24 Thread Sylwester Nawrocki
Assign module owner of a driver of a device passed to _clk_register()
and __clk_register() functions so the module_{get,put} calls in
__clk_get(), __clk_put() can have required effect.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Initially I had an 'owner' field added to struct clk_init_data so it can
be set explicitly in clock providers.  But this required modifications
of all users of (devm_)clk_register() as struct clk_init_data instance
was in most cases an unitialized stack variable.  This would also require
adding yet another argument to various clk_register_* functions
registering the standard clocks.  So I went for assigning clk->owner from
dev->driver->owner.  The disadvantages are that dereferencing dev->driver
may be potentially unsafe when not holding struct device::mutex.  And
there might be cases where clk->owner will need to be NULL.  One option
is to set dev argument of clk_register_*() to NULL for that, but it
predates devm_*.

Presumably a requirement could be added that callers of clk_register*()
must ensure dev->driver won't change during a call to these functions ?
---
 drivers/clk/clk.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8ccc1cd..cf5765a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1799,6 +1799,10 @@ struct clk *__clk_register(struct device *dev, struct 
clk_hw *hw)
clk->flags = hw->init->flags;
clk->parent_names = hw->init->parent_names;
clk->num_parents = hw->init->num_parents;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
+   else
+   clk->owner = NULL;
 
ret = __clk_init(dev, clk);
if (ret)
@@ -1819,6 +1823,8 @@ static int _clk_register(struct device *dev, struct 
clk_hw *hw, struct clk *clk)
goto fail_name;
}
clk->ops = hw->init->ops;
+   if (dev && dev->driver)
+   clk->owner = dev->driver->owner;
clk->hw = hw;
clk->flags = hw->init->flags;
clk->num_parents = hw->init->num_parents;
-- 
1.7.4.1

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


[PATCH v5 2/5] clkdev: Fix race condition in clock lookup from device tree

2013-08-24 Thread Sylwester Nawrocki
There is currently a race condition in the device tree part of clk_get()
function, since the pointer returned from of_clk_get_by_name() may become
invalid before __clk_get() call. E.g. due to the clock provider driver
remove() callback being called in between of_clk_get_by_name() and
__clk_get().

Fix this by doing both the look up and __clk_get() operations with the
clock providers list mutex held. This ensures that the clock pointer
returned from __of_clk_get_from_provider() call and passed to __clk_get()
is valid, as long as the clock supplier module first removes its clock
provider instance and then does clk_unregister() on the corresponding
clocks.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Reviewed-by: Mike Turquette 
Acked-by: Russell King 
---
Changes since v2:
 - none.

Changes since v1:
 - include "clk.h".
---
 drivers/clk/clkdev.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..48f6721 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static LIST_HEAD(clocks);
 static DEFINE_MUTEX(clocks_mutex);
 
@@ -39,7 +41,13 @@ struct clk *of_clk_get(struct device_node *np, int index)
if (rc)
return ERR_PTR(rc);
 
-   clk = of_clk_get_from_provider();
+   of_clk_lock();
+   clk = __of_clk_get_from_provider();
+
+   if (!IS_ERR(clk) && !__clk_get(clk))
+   clk = ERR_PTR(-ENOENT);
+
+   of_clk_unlock();
of_node_put(clkspec.np);
return clk;
 }
@@ -157,7 +165,7 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
if (dev) {
clk = of_clk_get_by_name(dev->of_node, con_id);
-   if (!IS_ERR(clk) && __clk_get(clk))
+   if (!IS_ERR(clk))
return clk;
}
 
-- 
1.7.4.1

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


[PATCH v5 1/5] clk: Provide not locked variant of of_clk_get_from_provider()

2013-08-24 Thread Sylwester Nawrocki
Add helper functions for the of_clk_providers list locking and
an unlocked variant of of_clk_get_from_provider().
These functions are intended to be used in the clkdev to avoid
race condition in the device tree based clock look up in clk_get().

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Acked-by: Russell King 
---
Changes since v3:
 - none.

Changes since v2:
 - fixed typo in clk.h.

Changes since v1:
 - moved the function declaractions to a local header.
---
 drivers/clk/clk.c |   38 ++
 drivers/clk/clk.h |   16 
 2 files changed, 46 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/clk.h

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bc02037..f46444f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "clk.h"
+
 static DEFINE_SPINLOCK(enable_lock);
 static DEFINE_MUTEX(prepare_lock);
 
@@ -2097,7 +2099,18 @@ static const struct of_device_id __clk_of_table_sentinel
__used __section(__clk_of_table_end);
 
 static LIST_HEAD(of_clk_providers);
-static DEFINE_MUTEX(of_clk_lock);
+static DEFINE_MUTEX(of_clk_mutex);
+
+/* of_clk_provider list locking helpers */
+void of_clk_lock(void)
+{
+   mutex_lock(_clk_mutex);
+}
+
+void of_clk_unlock(void)
+{
+   mutex_unlock(_clk_mutex);
+}
 
 struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 void *data)
@@ -2141,9 +2154,9 @@ int of_clk_add_provider(struct device_node *np,
cp->data = data;
cp->get = clk_src_get;
 
-   mutex_lock(_clk_lock);
+   mutex_lock(_clk_mutex);
list_add(>link, _clk_providers);
-   mutex_unlock(_clk_lock);
+   mutex_unlock(_clk_mutex);
pr_debug("Added clock from %s\n", np->full_name);
 
return 0;
@@ -2158,7 +2171,7 @@ void of_clk_del_provider(struct device_node *np)
 {
struct of_clk_provider *cp;
 
-   mutex_lock(_clk_lock);
+   mutex_lock(_clk_mutex);
list_for_each_entry(cp, _clk_providers, link) {
if (cp->node == np) {
list_del(>link);
@@ -2167,24 +2180,33 @@ void of_clk_del_provider(struct device_node *np)
break;
}
}
-   mutex_unlock(_clk_lock);
+   mutex_unlock(_clk_mutex);
 }
 EXPORT_SYMBOL_GPL(of_clk_del_provider);
 
-struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec)
 {
struct of_clk_provider *provider;
struct clk *clk = ERR_PTR(-ENOENT);
 
/* Check if we have such a provider in our array */
-   mutex_lock(_clk_lock);
list_for_each_entry(provider, _clk_providers, link) {
if (provider->node == clkspec->np)
clk = provider->get(clkspec, provider->data);
if (!IS_ERR(clk))
break;
}
-   mutex_unlock(_clk_lock);
+
+   return clk;
+}
+
+struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+{
+   struct clk *clk;
+
+   mutex_lock(_clk_mutex);
+   clk = __of_clk_get_from_provider(clkspec);
+   mutex_unlock(_clk_mutex);
 
return clk;
 }
diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h
new file mode 100644
index 000..795cc9f
--- /dev/null
+++ b/drivers/clk/clk.h
@@ -0,0 +1,16 @@
+/*
+ * linux/drivers/clk/clk.h
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
+struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec);
+void of_clk_lock(void);
+void of_clk_unlock(void);
+#endif
-- 
1.7.4.1

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


[PATCH v5 3/5] clk: Add common __clk_get(), __clk_put() implementations

2013-08-24 Thread Sylwester Nawrocki
This patch adds common __clk_get(), __clk_put() clkdev helpers which
replace their platform specific counterparts when the common clock
API is enabled.

The owner module pointer field is added to struct clk so a reference
to the clock supplier module can be taken by the clock consumers.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
Changes since v4:
 - dropped unnecessary struct module forward declaration from
   clk-provider.h

Changes since v3:
 - dropped exporting of __clk_get(), __clk_put().

Changes since v2:
 - fixed handling of NULL clock pointers in __clk_get(), __clk_put();
---
 arch/arm/include/asm/clkdev.h  |2 ++
 arch/blackfin/include/asm/clkdev.h |2 ++
 arch/mips/include/asm/clkdev.h |2 ++
 arch/sh/include/asm/clkdev.h   |2 ++
 drivers/clk/clk.c  |   20 
 include/linux/clk-private.h|3 +++
 include/linux/clkdev.h |5 +
 7 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/clkdev.h b/arch/arm/include/asm/clkdev.h
index 80751c1..4e8a4b2 100644
--- a/arch/arm/include/asm/clkdev.h
+++ b/arch/arm/include/asm/clkdev.h
@@ -14,12 +14,14 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #ifdef CONFIG_HAVE_MACH_CLKDEV
 #include 
 #else
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
 #endif
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/blackfin/include/asm/clkdev.h 
b/arch/blackfin/include/asm/clkdev.h
index 9053bed..7ac2436 100644
--- a/arch/blackfin/include/asm/clkdev.h
+++ b/arch/blackfin/include/asm/clkdev.h
@@ -8,7 +8,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif
diff --git a/arch/mips/include/asm/clkdev.h b/arch/mips/include/asm/clkdev.h
index 2624754..1b3ad7b 100644
--- a/arch/mips/include/asm/clkdev.h
+++ b/arch/mips/include/asm/clkdev.h
@@ -14,8 +14,10 @@
 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_get(clk) ({ 1; })
 #define __clk_put(clk) do { } while (0)
+#endif
 
 static inline struct clk_lookup_alloc *__clkdev_alloc(size_t size)
 {
diff --git a/arch/sh/include/asm/clkdev.h b/arch/sh/include/asm/clkdev.h
index 6ba9186..c419014 100644
--- a/arch/sh/include/asm/clkdev.h
+++ b/arch/sh/include/asm/clkdev.h
@@ -25,7 +25,9 @@ static inline struct clk_lookup_alloc *__clkdev_alloc(size_t 
size)
return kzalloc(size, GFP_KERNEL);
 }
 
+#ifndef CONFIG_COMMON_CLK
 #define __clk_put(clk)
 #define __clk_get(clk) ({ 1; })
+#endif
 
 #endif /* __CLKDEV_H__ */
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f46444f..8ccc1cd 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1959,6 +1959,26 @@ void devm_clk_unregister(struct device *dev, struct clk 
*clk)
 }
 EXPORT_SYMBOL_GPL(devm_clk_unregister);
 
+/*
+ * clkdev helpers
+ */
+int __clk_get(struct clk *clk)
+{
+   if (clk && !try_module_get(clk->owner))
+   return 0;
+
+   return 1;
+}
+
+void __clk_put(struct clk *clk)
+{
+   if (WARN_ON_ONCE(IS_ERR(clk)))
+   return;
+
+   if (clk)
+   module_put(clk->owner);
+}
+
 /***clk rate change notifiers***/
 
 /**
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 8138c94..8cb1865 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -25,10 +25,13 @@
 
 #ifdef CONFIG_COMMON_CLK
 
+struct module;
+
 struct clk {
const char  *name;
const struct clk_ops*ops;
struct clk_hw   *hw;
+   struct module   *owner;
struct clk  *parent;
const char  **parent_names;
struct clk  **parents;
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index a6a6f60..94bad77 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -43,4 +43,9 @@ int clk_add_alias(const char *, const char *, char *, struct 
device *);
 int clk_register_clkdev(struct clk *, const char *, const char *, ...);
 int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
 
+#ifdef CONFIG_COMMON_CLK
+int __clk_get(struct clk *clk);
+void __clk_put(struct clk *clk);
+#endif
+
 #endif
-- 
1.7.4.1

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


[git pull] vfs and filesystem fixes

2013-08-24 Thread Al Viro
Hopefully linux.org.uk mail setup got fixed and this one won't bounce...
Assorted fixes from the last week or so; please pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (1):
  cope with potentially long ->d_dname() output for shmem/hugetlb

Dan Carpenter (3):
  efs: iget_locked() doesn't return an ERR_PTR()
  bfs: iget_locked() doesn't return an ERR_PTR
  VFS: collect_mounts() should return an ERR_PTR

Oleg Nesterov (1):
  proc: kill the extra proc_readfd_common()->dir_emit_dots()

Diffstat:
 fs/bfs/inode.c |2 +-
 fs/dcache.c|   11 +++
 fs/efs/inode.c |2 +-
 fs/hugetlbfs/inode.c   |8 +---
 fs/namespace.c |2 +-
 fs/proc/fd.c   |2 --
 include/linux/dcache.h |1 +
 mm/shmem.c |8 +---
 8 files changed, 17 insertions(+), 19 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ARM: dts: add AM33XX EDMA support

2013-08-24 Thread Joel Fernandes
Updating CC with Matt's current email address.

On 08/24/2013 01:02 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 08/23/2013 11:06 PM, Sebastian Andrzej Siewior wrote:
> 
>> From: Matt Porter 
> 
>> Adds AM33XX EDMA support to the am33xx.dtsi as documented in
>> Documentation/devicetree/bindings/dma/ti-edma.txt
> 
>> Joel: Drop DT entries that are non-hardware-description for now as discussed
>> in [1]
> 
>> [1] https://patchwork.kernel.org/patch/2226761/
> 
>> Signed-off-by: Matt Porter 
>> Signed-off-by: Joel A Fernandes 
>> Signed-off-by: Sebastian Andrzej Siewior 
>> ---
>> Could someone please pick this up?
> 
>>   arch/arm/boot/dts/am33xx.dtsi | 12 
>>   1 file changed, 12 insertions(+)
> 
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 38b446b..784f774 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -96,6 +96,18 @@
>>   reg = <0x4820 0x1000>;
>>   };
>>
>> +edma: edma@4900 {
> 
>The node should be named "dma-controller", not "edma",according to ePAPR
> section 2.2.2:
> 
> http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

So you mean something like the following?

edma: dma-controller@4900 {
  ...
}


Thanks,

-Joel

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


/proc/pid/fd && anon_inode_fops

2013-08-24 Thread Oleg Nesterov
Sorry for off-topic, I am just curios.

On 08/22, Willy Tarreau wrote:
>
> It's not only that, it also supports sockets and pipes that you can access
> via /proc/pid/fd and not via a real symlink which would try to open eg
> "pipe:[23456]" instead of the real file.

But sock_no_open() disallows this, and for good reason I guess.

I am wondering, perhaps anon_inode should do the same? I do not
see any problem, but it looks pointless and misleading to allow
to open a file you can do nothing with.

Or is there any reason why, say, open("anon_inode:[perf_event]")
should succeed?

Thanks,

Oleg.

--- x/fs/anon_inodes.c
+++ x/fs/anon_inodes.c
@@ -24,7 +24,15 @@
 
 static struct vfsmount *anon_inode_mnt __read_mostly;
 static struct inode *anon_inode_inode;
-static const struct file_operations anon_inode_fops;
+
+static int anon_open(struct inode *inode, struct file *file)
+{
+   return -ENXIO;
+}
+
+static const struct file_operations anon_inode_fops = {
+   .open = anon_open,
+};
 
 /*
  * anon_inodefs_dname() is called from d_path().

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

2013-08-24 Thread Stefan Richter
On Aug 21 Steven Rostedt wrote:
> I guess the other question to ask is, how long does it take for a
> problem to appear after hitting mainline? If a problem is found in -rc4
> before -rc5 comes out, then this would be sufficient. But if the
> problem from -rc4 isn't found till -rc6 then that tells us something
> too.

The estimate of one or two RC periods applies to hardware/ workloads which
everyone has or which wasn't supported by the previous release.  For less
widely used hardware/ workloads which has been supported for years already,
it's more like between 2.5 months ( = a mainline kernel release period)
and more than a year ( = two release periods of typical distributions).
-- 
Stefan Richter
-=-===-= =--- ==---
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation/trace: Correcting and extending tracepoint documentation

2013-08-24 Thread Mathieu Desnoyers
* Zoltan Kiss (zoltan.k...@citrix.com) wrote:
> The sample missed the moving of the header files into the events subdirectory.
> I've also extended it based on the existing headers, and mentioned the tiny
> but important role of CREATE_TRACE_POINTS.

Given that we expect tracepoints to be used though the TRACE_EVENT
wrapper, it makes sense indeed. A small nit below:

> 
> Signed-off-by: Zoltan Kiss 
> ---
>  Documentation/trace/tracepoints.txt |   19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/trace/tracepoints.txt 
> b/Documentation/trace/tracepoints.txt
> index da49437..e8e3c4b 100644
> --- a/Documentation/trace/tracepoints.txt
> +++ b/Documentation/trace/tracepoints.txt
> @@ -40,7 +40,13 @@ Two elements are required for tracepoints :
>  
>  In order to use tracepoints, you should include linux/tracepoint.h.
>  
> -In include/trace/subsys.h :
> +In include/trace/events/subsys.h :
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM subsys
> +
> +#if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SUBSYS_H
>  
>  #include 
>  
> @@ -48,10 +54,16 @@ DECLARE_TRACE(subsys_eventname,
>   TP_PROTO(int firstarg, struct task_struct *p),
>   TP_ARGS(firstarg, p));
>  
> +#endif /* _TRACE_SUBSYS_H */
> +
> +/* This part must be outside protection */
> +#include 
> +
>  In subsys/file.c (where the tracing statement must be added) :
>  
> -#include 
> +#include 
>  
> +#define CREATE_TRACE_POINTS
>  DEFINE_TRACE(subsys_eventname);
>  
>  void somefct(void)
> @@ -72,6 +84,9 @@ Where :
>  - TP_ARGS(firstarg, p) are the parameters names, same as found in the
>prototype.
>  
> +- if you use the header in multiple source files, #define CREATE_TRACE_POINTS
> +  should appear only in one source file

Missing dot at the end of the sentence above.

Other than that,

Acked-by: Mathieu Desnoyers 

Thanks!

Mathieu

> +
>  Connecting a function (probe) to a tracepoint is done by providing a
>  probe (function to call) for the specific tracepoint through
>  register_trace_subsys_eventname().  Removing a probe is done through
> -- 
> 1.7.9.5
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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/


[PATCH] gpiolib: Fix crash when exporting non-existant gpio

2013-08-24 Thread danielfsantos
I got this on an RPi and I can't find anything specific to that.
Besides, it's clearly wrong to try to access desc->chip when we have
just tested that it may be NULL at drivers/gpio/gpiolib.c:1409:

chip = desc->chip;
if (chip == NULL)
goto done;



done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
 desc_to_gpio(desc), label ? : "?", status);

To reproduce, just pick an invalid gpio nubmer and:

echo -n 248 > /sys/class/gpio/export

However, I wasn't able to reproduce it on my laptop, maybe because I
don't have any real gpio chips there, not sure.  More info on RPi bug
report: https://github.com/raspberrypi/linux/issues/364

[  222.961384] Unable to handle kernel NULL pointer dereference at
virtual address 0044
[  222.969486] pgd = d97d
[  222.972190] [0044] *pgd=1aaca831, *pte=, *ppte=
[  222.978483] Internal error: Oops: 17 [#1] PREEMPT ARM
---
 drivers/gpio/gpiolib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d6413b2..e547f75f8b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -136,7 +136,7 @@ static struct gpio_desc *gpio_to_desc(unsigned gpio)
  */
 static int desc_to_gpio(const struct gpio_desc *desc)
 {
-   return desc->chip->base + gpio_chip_hwgpio(desc);
+   return desc->chip ?  desc->chip->base + gpio_chip_hwgpio(desc) : -1;
 }
 
 
-- 
1.8.1.5

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


Re: [RFC PATCH 3/4] gcov: compile specific gcov implementation based on gcc version

2013-08-24 Thread Frantisek Hrbata
On Fri, Aug 23, 2013 at 05:15:19PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 10:39, Frantisek Hrbata wrote:
> > Compile the correct gcov implementation file for a specific gcc version. In
> > the future, if another file is added, the conditions will need to be somehow
> > adjusted to if-elif-else case, but at this point the simple cc-ifversion 
> > should
> > be enough.
> 
> Looks good, though I think this could be merged into the main 4.7 format 
> patch,
> since without it, the 4.7 code will never be reached.

Sure, I can merge these two patches.

> 
> Also it is my understanding that there are some distribution-specific versions
> of GCC that include the 4.7. gcov format code but report GCC version 4.6. With
> the auto-detection code implemented like this, gcov-kernel won't work 
> correctly.
> For that purpose I've implemented a configuration option to allow users to
> force a specific version of gcov format.

Ah, I was not aware of this inconsistency in versioning. This raises a question
if it would not be better to deal directly with version in the gcov_info
instead of these config options. This would of course mean some kind of gcov
operations callbacks per gcov version(you already mentioned the file
operations approach).

> 
> I'm attaching the corresponding patch below:
> 
> ---
> kernel: gcov: make data format configurable
> 
> Make the format of the generated gcov data configurable. This may be
> required for example for pre-4.7 GCCs that contain the 4.7 gcov data
> format changes.
> 
> Signed-off-by: Peter Oberparleiter 
> ---
>  kernel/gcov/Kconfig  |   30 ++
>  kernel/gcov/Makefile |   21 +++--
>  2 files changed, 49 insertions(+), 2 deletions(-)
> 
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -46,4 +46,34 @@ config GCOV_PROFILE_ALL
>   larger and run slower. Also be sure to exclude files from profiling
>   which are not linked to the kernel image to prevent linker errors.
> 
> +choice
> + prompt "Specify GCOV format"
> + depends on GCOV_KERNEL
> + default GCOV_FORMAT_AUTODETECT
> + ---help---
> + The gcov format is usually determined by the GCC version, but there are
> + exceptions where format changes are integrated in lower-version GCCs.
> + In such a case use this option to adjust the format used in the kernel
> + accordingly.
> +
> + If unsure, choose "Autodetect".
> +
> +config GCOV_FORMAT_AUTODETECT
> + bool "Autodetect"
> + ---help---
> + Select this option to use the format that corresponds to your GCC
> + version.
> +
> +config GCOV_FORMAT_3_4
> + bool "GCC 3.4 format"
> + ---help---
> + Select this option to use the format defined by GCC 3.4.
> +
> +config GCOV_FORMAT_4_7
> + bool "GCC 4.7 format"
> + ---help---
> + Select this option to use the format defined by GCC 4.7.
> +
> +endchoice
> +
>  endmenu
> --- a/kernel/gcov/Makefile
> +++ b/kernel/gcov/Makefile
> @@ -1,5 +1,22 @@
>  ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"'
> 
> +# if-lt
> +# Usage VAR := $(call if-lt, $(a), $(b))
> +# Returns 1 if (a < b)
> +if-lt = $(shell [ $(1) -lt $(2) ] && echo 1)
> +
> +ifeq ($(CONFIG_GCOV_FORMAT_3_4),y)
> +  cc-ver := 0304
> +else ifeq ($(CONFIG_GCOV_FORMAT_4_7),y)
> +  cc-ver := 0407
> +else
> +  cc-ver := $(call cc-version)
> +endif
> +
>  obj-$(CONFIG_GCOV_KERNEL) := base.o fs.o
> -obj-$(CONFIG_GCOV_KERNEL) += $(call cc-ifversion, -lt, 0407, gcc_3_4.o)
> -obj-$(CONFIG_GCOV_KERNEL) += $(call cc-ifversion, -ge, 0407, gcc_4_7.o)
> +
> +ifeq ($(call if-lt, $(cc-ver), 0407),1)
> +  obj-$(CONFIG_GCOV_KERNEL) += gcc_3_4.o
> +else
> +  obj-$(CONFIG_GCOV_KERNEL) += gcc_4_7.o
> +endif
> 
> 
> -- 
> Peter Oberparleiter
> Linux on System z Development - IBM Germany
> 

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


[PATCH] net/cadence/macb: fix kernel Oops if no PHY were discovered during probe

2013-08-24 Thread Boris BREZILLON
Test the presence of a PHY device before printing attached PHY
informations.

Signed-off-by: Boris BREZILLON 
---
 drivers/net/ethernet/cadence/macb.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index e866608..fd3b67f 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1868,8 +1868,10 @@ static int __init macb_probe(struct platform_device 
*pdev)
dev->irq, dev->dev_addr);
 
phydev = bp->phy_dev;
-   netdev_info(dev, "attached PHY driver [%s] (mii_bus:phy_addr=%s, 
irq=%d)\n",
-   phydev->drv->name, dev_name(>dev), phydev->irq);
+   if (phydev)
+   netdev_info(dev, "attached PHY driver [%s] 
(mii_bus:phy_addr=%s, irq=%d)\n",
+   phydev->drv->name, dev_name(>dev),
+   phydev->irq);
 
return 0;
 
-- 
1.7.9.5

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


Re: [PATCH tip/core/rcu 1/5] rcu: Add duplicate-callback tests to rcutorture

2013-08-24 Thread Mathieu Desnoyers
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
[...]
> The result is as follows.  Better?

Hi Paul,

Pitching in late in the thread, so that I can get a share of the fun ;-)

>   Thanx, Paul
> 
> #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> static void rcu_torture_leak_cb(struct rcu_head *rhp)
> {
> }
> 
> static void rcu_torture_err_cb(struct rcu_head *rhp)
> {
>   /*
>* This -might- happen due to race conditions, but is unlikely.
>* The scenario that leads to this happening is that the
>* first of the pair of duplicate callbacks is queued,
>* someone else starts a grace period that includes that
>* callback, then the second of the pair must wait for the
>* next grace period.  Unlikely, but can happen.  If it
>* does happen, the debug-objects subsystem won't have splatted.
>*/
>   pr_alert("rcutorture: duplicated callback was invoked.\n");
> }
> #endif /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> 

Hrm. Putting an #ifdef within a function when not utterly needed is
usually a bad idea. How about:

/*
 * Verify that double-free causes debug-objects to complain, but only
 * if CONFIG_DEBUG_OBJECTS_RCU_HEAD=y.  Otherwise, say that the test
 * cannot be carried out.
 */
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
static void rcu_test_debug_objects(void)
{
struct rcu_head rh1;
struct rcu_head rh2;
 
init_rcu_head_on_stack();
init_rcu_head_on_stack();
pr_alert("rcutorture: WARN: Duplicate call_rcu() test starting.\n");
preempt_disable(); /* Prevent preemption from interrupting test. */
rcu_read_lock(); /* Make it impossible to finish a grace period. */
call_rcu(, rcu_torture_leak_cb); /* Start grace period. */
local_irq_disable(); /* Make it harder to start a new grace period. */
call_rcu(, rcu_torture_leak_cb);
call_rcu(, rcu_torture_err_cb); /* Duplicate callback. */
local_irq_enable();
rcu_read_unlock();
preempt_enable();
rcu_barrier();
pr_alert("rcutorture: WARN: Duplicate call_rcu() test complete.\n");
destroy_rcu_head_on_stack();
destroy_rcu_head_on_stack();
}
#else /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
static void rcu_test_debug_objects(void)
{
pr_alert("rcutorture: !CONFIG_DEBUG_OBJECTS_RCU_HEAD, not testing 
duplicate call_rcu()\n");
}
#endif /* #else #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */


More comments inlined in the code below,

> /*
>  * Verify that double-free causes debug-objects to complain, but only
>  * if CONFIG_DEBUG_OBJECTS_RCU_HEAD=y.  Otherwise, say that the test
>  * cannot be carried out.
>  */
> static void rcu_test_debug_objects(void)
> {
> #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
>   struct rcu_head rh1;
>   struct rcu_head rh2;
> 
>   init_rcu_head_on_stack();
>   init_rcu_head_on_stack();
>   pr_alert("rcutorture: WARN: Duplicate call_rcu() test starting.\n");
>   preempt_disable(); /* Prevent preemption from interrupting test. */
>   rcu_read_lock(); /* Make it impossible to finish a grace period. */
>   call_rcu(, rcu_torture_leak_cb); /* Start grace period. */

Are we really "starting" a grace period ? If rcu_test_debug_objects() is
executed after some callbacks are already queued, are we, by definition,
"starting" the grace period ?

Also, I find it weird to have, in that order:

1) preempt_disable()
2) rcu_read_lock()
3) local_irq_disable()

I would rather expect:

1) rcu_read_lock()
2) preempt_disable()
3) local_irq_disable()

So they come in increasing order of impact on the system: with
non-preemptable RCU, the read-lock and preempt disable mean the same
thing, however, with preemptable RCU, the impact of preempt disable
seems larger than the impact of RCU read lock: preemption is still
enabled when within a RCU critical section. Both will work, but I find
this call order slightly weird.

Also, if your goal is to increase the chances that call_rcu() enqueues
both callbacks into the same grace period, you might want to issue a
rcu_barrier() early in this function, so that call_rcu() has even more
chances to enqueue the callbacks into the same grace period.

However, if you care about testing enqueue into same _and_ different
grace periods, you might want to turn this single-shot test into a
stress-test by calling it repeatedly.

Thanks!

Mathieu

>   local_irq_disable(); /* Make it harder to start a new grace period. */
>   call_rcu(, rcu_torture_leak_cb);
>   call_rcu(, rcu_torture_err_cb); /* Duplicate callback. */
>   local_irq_enable();
>   rcu_read_unlock();
>   preempt_enable();
>   rcu_barrier();
>   pr_alert("rcutorture: WARN: Duplicate call_rcu() test complete.\n");
>   destroy_rcu_head_on_stack();
>   destroy_rcu_head_on_stack();
> #else /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
>   pr_alert("rcutorture: 

Re: [PATCH] ARM: dts: add AM33XX EDMA support

2013-08-24 Thread Sergei Shtylyov

Hello.

On 08/24/2013 10:33 PM, Joel Fernandes wrote:


Updating CC with Matt's current email address.



From: Matt Porter 



Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt



Joel: Drop DT entries that are non-hardware-description for now as discussed
in [1]



[1] https://patchwork.kernel.org/patch/2226761/



Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
Signed-off-by: Sebastian Andrzej Siewior 
---
Could someone please pick this up?



   arch/arm/boot/dts/am33xx.dtsi | 12 
   1 file changed, 12 insertions(+)



diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
   reg = <0x4820 0x1000>;
   };

+edma: edma@4900 {



The node should be named "dma-controller", not "edma",according to ePAPR
section 2.2.2:



http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf



So you mean something like the following?



edma: dma-controller@4900 {
   ...
}


   Yes, exactly.


Thanks,



-Joel


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/4] gcov: compile specific gcov implementation based on gcc version

2013-08-24 Thread Frantisek Hrbata
On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote:
> On 23.08.2013 17:15, Peter Oberparleiter wrote:
> > On 23.08.2013 10:39, Frantisek Hrbata wrote:
> >> Compile the correct gcov implementation file for a specific gcc version. In
> >> the future, if another file is added, the conditions will need to be 
> >> somehow
> >> adjusted to if-elif-else case, but at this point the simple cc-ifversion 
> >> should
> >> be enough.
> 
> As promised, I'm also adding the patch that makes the format-specific part
> of gcov-kernel a loadable kernel module:
> 
> ---
> kernel: gcov: make format-specific code loadable
> 
> Turn the format-specific part of gcov-kernel into a loadable kernel
> module. This enables the use of gcov-kernel with kernel modules
> that were compiled with a version of GCC that produces a different
> gcov format when compared to the version of GCC that was used to
> compile the kernel.

If I understand it correctly, this would mean that you will be able to use only
one implementation of gcov format at the time. Meaning you will be able to get
coverage data for module, but not for kernel if it was compiled with different
gcc(gcda format). This is probably ok if you work only on your module, but I'm
not sure this is generally the right approach. In this case I would probably
rather see some support for more gcov formats at the same time(e.g. set of
callback operations per gcov version). Again I'm probably missing something, but
I still cannot see reason why to add such feature. If you want gcov support just
compile your kernel and modules with the same gcc version(gcda format). But if
this is really needed maybe it would be better to consider some parallel support
for more gcov formats based on the gcov_info version.

Would it be possible to add support for the modified gcc 4.7 gcov format and
deal with this later? I can incorporate your changes: iter to use buffer,
.init_array for modules and possibility to explicitly select the gcda format.
In this case we will have at least the basic support in kernel. This is just me
thinking out loud.

Many thanks Peter!

> 
> Signed-off-by: Peter Oberparleiter 
> ---
>  kernel/gcov/Kconfig  |   19 +--
>  kernel/gcov/Makefile |7 ---
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -29,8 +29,23 @@ config GCOV_KERNEL
>   and:
>   GCOV_PROFILE := n
> 
> - Note that the debugfs filesystem has to be mounted to access
> - profiling data.
> + Note that GCOV_KERNEL_FS has to specified as well and the debugfs
> + filesystem has to be mounted to access profiling data.
> +
> +config GCOV_KERNEL_FS
> + tristate "Provide gcov data files in debugfs"
> + depends on GCOV_KERNEL
> + default y
> + ---help---
> + Make profiling data available in debugfs at /sys/kernel/debug/gcov.
> +
> + Say M if you want to enable collecting coverage data for kernel modules
> + which are compiled using a gcc version different from the one that
> + was used to compile the kernel. In that case, re-compile the gcov
> + kernel module with corresponding format support and load that module
> + instead.
> +
> + If unsure, say Y.
> 
>  config GCOV_PROFILE_ALL
>   bool "Profile entire Kernel"
> --- a/kernel/gcov/Makefile
> +++ b/kernel/gcov/Makefile
> @@ -13,10 +13,11 @@ else
>cc-ver := $(call cc-version)
>  endif
> 
> -obj-$(CONFIG_GCOV_KERNEL) := base.o fs.o
> +obj-$(CONFIG_GCOV_KERNEL) += base.o
> +obj-$(CONFIG_GCOV_KERNEL_FS) += gcov.o
> 
>  ifeq ($(call if-lt, $(cc-ver), 0407),1)
> -  obj-$(CONFIG_GCOV_KERNEL) += gcc_3_4.o
> +  gcov-objs += fs.o gcc_3_4.o
>  else
> -  obj-$(CONFIG_GCOV_KERNEL) += gcc_4_7.o
> +  gcov-objs += fs.o gcc_4_7.o
>  endif
> 
> -- 
> Peter Oberparleiter
> Linux on System z Development - IBM Germany
> 

-- 
Frantisek Hrbata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpiolib: Fix crash when exporting non-existant gpio

2013-08-24 Thread Guenter Roeck

On 08/24/2013 11:48 AM, danielfsan...@att.net wrote:

I got this on an RPi and I can't find anything specific to that.
Besides, it's clearly wrong to try to access desc->chip when we have
just tested that it may be NULL at drivers/gpio/gpiolib.c:1409:

chip = desc->chip;
if (chip == NULL)
goto done;



done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
 desc_to_gpio(desc), label ? : "?", status);

To reproduce, just pick an invalid gpio nubmer and:

echo -n 248 > /sys/class/gpio/export

However, I wasn't able to reproduce it on my laptop, maybe because I
don't have any real gpio chips there, not sure.  More info on RPi bug
report: https://github.com/raspberrypi/linux/issues/364

[  222.961384] Unable to handle kernel NULL pointer dereference at
virtual address 0044
[  222.969486] pgd = d97d
[  222.972190] [0044] *pgd=1aaca831, *pte=, *ppte=
[  222.978483] Internal error: Oops: 17 [#1] PREEMPT ARM
---
  drivers/gpio/gpiolib.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d6413b2..e547f75f8b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -136,7 +136,7 @@ static struct gpio_desc *gpio_to_desc(unsigned gpio)
   */
  static int desc_to_gpio(const struct gpio_desc *desc)
  {
-   return desc->chip->base + gpio_chip_hwgpio(desc);
+   return desc->chip ?  desc->chip->base + gpio_chip_hwgpio(desc) : -1;
  }



Looking into calling code, desc_to_gpio() is clearly not supposed to return an 
error,
and it will result in odd behavior if it returns -1. For example, the resulting 
debug
message of "gpio--1 (...) status ..." is not very useful.

It would make more sense to fix the calling code. You could for example
validate in affected functions if the gpio pin exists by not only
checking for desc but also for desc->chip. Another option might be
to have gpio_to_desc() return NULL if desc->chip is NULL.

Guenter


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


Re: [PATCH v4 1/4] lib: Introduce atomic MMIO modify

2013-08-24 Thread Ezequiel Garcia
On Sat, Aug 24, 2013 at 08:27:10PM +0200, richard -rw- weinberger wrote:
> On Sat, Aug 24, 2013 at 5:35 PM, Ezequiel Garcia
>  wrote:
> > Some platforms have MMIO regions that are shared across orthogonal
> > subsystems. This commit implements a possible solution for the
> > thread-safe access of such regions through a spinlock-protected API.
> >
> > Concurrent access is protected with a single spinlock for the
> > entire MMIO address space. While this protects shared-registers,
> > it also serializes access to unrelated/unshared registers.
> >
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  include/linux/io.h |  5 +
> >  lib/Makefile   |  2 +-
> >  lib/atomicio.c | 27 +++
> >  3 files changed, 33 insertions(+), 1 deletion(-)
> >  create mode 100644 lib/atomicio.c
> >
> > diff --git a/include/linux/io.h b/include/linux/io.h
> > index f4f42fa..c331dcb 100644
> > --- a/include/linux/io.h
> > +++ b/include/linux/io.h
> > @@ -101,4 +101,9 @@ static inline void arch_phys_wc_del(int handle)
> >  #define arch_phys_wc_add arch_phys_wc_add
> >  #endif
> >
> > +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> > +/* Atomic MMIO-wide IO modify */
> > +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> > +#endif
> > +
> >  #endif /* _LINUX_IO_H */
> > diff --git a/lib/Makefile b/lib/Makefile
> > index 7baccfd..695d6e2 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
> >  sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
> >  proportions.o flex_proportions.o prio_heap.o ratelimit.o 
> > show_mem.o \
> >  is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> > -earlycpio.o percpu-refcount.o
> > +earlycpio.o percpu-refcount.o atomicio.o
> >
> >  obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
> >  lib-$(CONFIG_MMU) += ioremap.o
> > diff --git a/lib/atomicio.c b/lib/atomicio.c
> > new file mode 100644
> > index 000..1750f9d
> > --- /dev/null
> > +++ b/lib/atomicio.c
> > @@ -0,0 +1,27 @@
> > +#include 
> > +#include 
> > +
> > +#ifndef __HAVE_ARCH_ATOMIC_IO_MODIFY
> > +/*
> > + * Generic atomic MMIO modify.
> > + *
> > + * Allows thread-safe access to registers shared by unrelated subsystems.
> > + * The access is protected by a single MMIO-wide lock.
> > + *
> > + * Optimized variants can be implemented on a per-architecture basis.
> > + */
> > +static DEFINE_RAW_SPINLOCK(__io_lock);
> > +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> > +{
> > +   unsigned long flags;
> > +   u32 value;
> > +
> > +   raw_spin_lock_irqsave(&__io_lock, flags);
> > +   value = readl(reg) & ~mask;
> > +   value |= (set & mask);
> > +   writel(value, reg);
> > +   raw_spin_unlock_irqrestore(&__io_lock, flags);
> > +
> > +}
> > +EXPORT_SYMBOL(atomic_io_modify);
> 
> Why not the default case EXPORT_SYMBOL_GPL()?
> 

Because I copy-pasted the export from some other lib/.. :-)

Mind explaining me the difference, why you say _GPL it's the default,
and why EXPORT_SYMBOL is more frequently used in lib/ ?

$ git grep EXPORT_SYMBOL lib/ | wc -l
598
$ git grep EXPORT_SYMBOL_GPL lib/ | wc -l
117

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.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: Unusually high system CPU usage with recent kernels

2013-08-24 Thread Tibor Billes
From: Paul E. McKenney Sent: 08/22/13 12:09 AM
> On Wed, Aug 21, 2013 at 11:05:51PM +0200, Tibor Billes wrote:
> > > From: Paul E. McKenney Sent: 08/21/13 09:12 PM
> > > On Wed, Aug 21, 2013 at 08:14:46PM +0200, Tibor Billes wrote:
> > > > > From: Paul E. McKenney Sent: 08/20/13 11:43 PM
> > > > > On Tue, Aug 20, 2013 at 10:52:26PM +0200, Tibor Billes wrote:
> > > > > > > From: Paul E. McKenney Sent: 08/20/13 04:53 PM
> > > > > > > On Tue, Aug 20, 2013 at 08:01:28AM +0200, Tibor Billes wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I was using the 3.9.7 stable release and tried to upgrade to 
> > > > > > > > the 3.10.x series.
> > > > > > > > The 3.10.x series was showing unusually high (>75%) system CPU 
> > > > > > > > usage in some
> > > > > > > > situations, making things really slow. The latest stable I 
> > > > > > > > tried is 3.10.7.
> > > > > > > > I also tried 3.11-rc5, they both show this behaviour. This 
> > > > > > > > behaviour doesn't
> > > > > > > > show up when the system is idling, only when doing some CPU 
> > > > > > > > intensive work,
> > > > > > > > like compiling with multiple threads. Compiling with only one 
> > > > > > > > thread seems not
> > > > > > > > to trigger this behaviour.
> > > > > > > > 
> > > > > > > > To be more precise I did a `perf record -a` while compiling a 
> > > > > > > > large C++ program
> > > > > > > > with scons using 4 threads, the result is appended at the end 
> > > > > > > > of this email.
> > > > > > > 
> > > > > > > New one on me! You are running a mainstream system (x86_64), so I 
> > > > > > > am
> > > > > > > surprised no one else noticed.
> > > > > > > 
> > > > > > > Could you please send along your .config file?
> > > > > > 
> > > > > > Here it is
> > > > > 
> > > > > Interesting. I don't see RCU stuff all that high on the list, but
> > > > > the items I do see lead me to suspect RCU_FAST_NO_HZ, which has some
> > > > > relevance to the otherwise inexplicable group of commits you located
> > > > > with your bisection. Could you please rerun with 
> > > > > CONFIG_RCU_FAST_NO_HZ=n?
> > > > > 
> > > > > If that helps, there are some things I could try.
> > > > 
> > > > It did help. I didn't notice anything unusual when running with 
> > > > CONFIG_RCU_FAST_NO_HZ=n.
> > > 
> > > Interesting. Thank you for trying this -- and we at least have a
> > > short-term workaround for this problem. I will put a patch together
> > > for further investigation.
> > 
> > I don't specifically need this config option so I'm fine without it in
> > the long term, but I guess it's not supposed to behave like that.
> 
> OK, good, we have a long-term workload for your specific case,
> even better. ;-)
> 
> But yes, there are situations where RCU_FAST_NO_HZ needs to work
> a bit better. I hope you will bear with me with a bit more
> testing...
>
> > > In the meantime, could you please tell me how you were measuring
> > > performance for your kernel builds? Wall-clock time required to complete
> > > one build? Number of builds completed per unit time? Something else?
> > 
> > Actually, I wasn't all this sophisticated. I have a system monitor
> > applet on my top panel (using MATE, Linux Mint), four little graphs,
> > one of which shows CPU usage. Different colors indicate different kind
> > of CPU usage. Blue shows user space usage, red shows system usage, and
> > two more for nice and iowait. During a normal compile it's almost
> > completely filled with blue user space CPU usage, only the top few
> > pixels show some iowait and system usage. With CONFIG_RCU_FAST_NO_HZ
> > set, about 3/4 of the graph was red system CPU usage, the rest was
> > blue. So I just looked for a pile of red on my graphs when I tested
> > different kernel builds. But also compile speed was horrible I couldn't
> > wait for the build to finish. Even the UI got unresponsive.
> 
> We have been having problems with CPU accounting, but this one looks
> quite real.
> 
> > Now I did some measuring. In the normal case a compile finished in 36
> > seconds, compiled 315 object files. Here are some output lines from
> > dstat -tasm --vm during compile:
> > system total-cpu-usage -dsk/total- -net/total- ---paging-- 
> > ---system-- swap--- --memory-usage- -virtual-memory
> >     time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | 
> > int   csw | used  free| used  buff  cach  free|majpf minpf alloc  free
> > 21-08 21:48:05| 91   8   2   0   0   0|   0  5852k|   0     0 |   0     0 
> > |1413  1772 |   0  7934M| 581M 58.0M  602M 6553M|   0    71k   46k   54k
> > 21-08 21:48:06| 93   6   1   0   0   0|   0  2064k| 137B  131B|   0     0 
> > |1356  1650 |   0  7934M| 649M 58.0M  604M 6483M|   0    72k   47k   28k
> > 21-08 21:48:07| 86  11   4   0   0   0|   0  5872k|   0     0 |   0     0 
> > |2000  2991 |   0  7934M| 577M 58.0M  627M 6531M|   0    99k   67k   79k
> > 21-08 21:48:08| 87   9   3   0   0   0|   0  2840k|   0     0 |   0     0 

[PATCH 1/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag

2013-08-24 Thread Yann Droneaud
KVM uses anon_inode_get() to allocate file descriptors as part
of some of its ioctls. But those ioctls are lacking a flag argument
allowing userspace to choose options for the newly opened file descriptor.

In such case it's advised to use O_CLOEXEC by default so that
userspace is allowed to choose, without race, if the file descriptor
is going to be inherited across exec().

This patch set O_CLOEXEC flag on all file descriptors created
with anon_inode_getfd() to not leak file descriptors across exec().

Signed-off-by: Yann Droneaud 
Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com
---
 virt/kvm/kvm_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 89f74d1..d65cc0c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1896,7 +1896,7 @@ static struct file_operations kvm_vcpu_fops = {
  */
 static int create_vcpu_fd(struct kvm_vcpu *vcpu)
 {
-   return anon_inode_getfd("kvm-vcpu", _vcpu_fops, vcpu, O_RDWR);
+   return anon_inode_getfd("kvm-vcpu", _vcpu_fops, vcpu, O_RDWR | 
O_CLOEXEC);
 }
 
 /*
@@ -2306,7 +2306,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
return ret;
}
 
-   ret = anon_inode_getfd(ops->name, _device_fops, dev, O_RDWR);
+   ret = anon_inode_getfd(ops->name, _device_fops, dev, O_RDWR | 
O_CLOEXEC);
if (ret < 0) {
ops->destroy(dev);
return ret;
@@ -2590,7 +2590,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
return r;
}
 #endif
-   r = anon_inode_getfd("kvm-vm", _vm_fops, kvm, O_RDWR);
+   r = anon_inode_getfd("kvm-vm", _vm_fops, kvm, O_RDWR | O_CLOEXEC);
if (r < 0)
kvm_put_kvm(kvm);
 
-- 
1.8.3.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/


<    1   2   3   >