Re: [PATCH] Omnikey Cardman 4000: pull in ioctl.h in user header
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
-- 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
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
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
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
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
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
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 ]
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
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
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
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
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()
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
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?
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 ]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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()
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()
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
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
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
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
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()
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
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
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
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
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
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.
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"
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? -
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
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
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
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
Хороший способ спасти глазки
Re: [PATCH] amd64_edac: Correct erratum 505 range
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
* 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
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
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
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
* 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
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
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
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
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
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
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/