Re: [PATCH v3] drivers: cma: represent physical addresses as phys_addr_t
Hello,
On 12/5/2012 3:29 PM, Vitaly Andrianov wrote:
This commit changes the CMA early initialization code to use phys_addr_t
for representing physical addresses instead of unsigned long.
Without this change, among other things, dma_declare_contiguous() simply
discards any memory regions whose address is not representable as unsigned
long.
This is a problem on 32-bit PAE machines where unsigned long is 32-bit
but physical address space is larger.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
Applied to my dma-maping-next branch, thanks for your work!
---
drivers/base/dma-contiguous.c | 24 ++--
include/linux/dma-contiguous.h |4 ++--
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9a14694..9b841e2 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -60,8 +60,8 @@ struct cma *dma_contiguous_default_area;
* Users, who want to set the size of global CMA area for their system
* should use cma= kernel parameter.
*/
-static const unsigned long size_bytes = CMA_SIZE_MBYTES * SZ_1M;
-static long size_cmdline = -1;
+static const phys_addr_t size_bytes = CMA_SIZE_MBYTES * SZ_1M;
+static phys_addr_t size_cmdline = -1;
static int __init early_cma(char *p)
{
@@ -73,7 +73,7 @@ early_param("cma", early_cma);
#ifdef CONFIG_CMA_SIZE_PERCENTAGE
-static unsigned long __init __maybe_unused cma_early_percent_memory(void)
+static phys_addr_t __init __maybe_unused cma_early_percent_memory(void)
{
struct memblock_region *reg;
unsigned long total_pages = 0;
@@ -91,7 +91,7 @@ static unsigned long __init __maybe_unused
cma_early_percent_memory(void)
#else
-static inline __maybe_unused unsigned long cma_early_percent_memory(void)
+static inline __maybe_unused phys_addr_t cma_early_percent_memory(void)
{
return 0;
}
@@ -109,7 +109,7 @@ static inline __maybe_unused unsigned long
cma_early_percent_memory(void)
*/
void __init dma_contiguous_reserve(phys_addr_t limit)
{
- unsigned long selected_size = 0;
+ phys_addr_t selected_size = 0;
pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
@@ -129,7 +129,7 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
if (selected_size) {
pr_debug("%s: reserving %ld MiB for global area\n", __func__,
-selected_size / SZ_1M);
+(unsigned long)selected_size / SZ_1M);
dma_declare_contiguous(NULL, selected_size, 0, limit);
}
@@ -230,11 +230,11 @@ core_initcall(cma_init_reserved_areas);
* called by board specific code when early allocator (memblock or bootmem)
* is still activate.
*/
-int __init dma_declare_contiguous(struct device *dev, unsigned long size,
+int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
phys_addr_t base, phys_addr_t limit)
{
struct cma_reserved *r = _reserved[cma_reserved_count];
- unsigned long alignment;
+ phys_addr_t alignment;
pr_debug("%s(size %lx, base %08lx, limit %08lx)\n", __func__,
(unsigned long)size, (unsigned long)base,
@@ -271,10 +271,6 @@ int __init dma_declare_contiguous(struct device *dev,
unsigned long size,
if (!addr) {
base = -ENOMEM;
goto err;
- } else if (addr + size > ~(unsigned long)0) {
- memblock_free(addr, size);
- base = -EINVAL;
- goto err;
} else {
base = addr;
}
@@ -288,14 +284,14 @@ int __init dma_declare_contiguous(struct device *dev,
unsigned long size,
r->size = size;
r->dev = dev;
cma_reserved_count++;
- pr_info("CMA: reserved %ld MiB at %08lx\n", size / SZ_1M,
+ pr_info("CMA: reserved %ld MiB at %08lx\n", (unsigned long)size / SZ_1M,
(unsigned long)base);
/* Architecture specific contiguous memory fixup. */
dma_contiguous_early_fixup(base, size);
return 0;
err:
- pr_err("CMA: failed to reserve %ld MiB\n", size / SZ_1M);
+ pr_err("CMA: failed to reserve %ld MiB\n", (unsigned long)size / SZ_1M);
return base;
}
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 2f303e4..01b5c84 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -68,7 +68,7 @@ struct device;
extern struct cma *dma_contiguous_default_area;
void dma_contiguous_reserve(phys_addr_t addr_limit);
-int dma_declare_contiguous(struct device *dev, unsigned long size,
+int dma_declare_contiguous(struct device *dev, phys_addr_t size,
phys_addr_t base, phys_addr_t limit);
struct page *dma_alloc_from_contiguous(struct
Re: [PATCH 0/3] pwm: lpc32xx - Various small fixes
On Wed, Nov 14, 2012 at 12:58:12PM +0100, Alban Bedel wrote: > A few fixes for the LPC32 PWM driver: > > * [PATCH 1/3] pwm: lpc32xx - Fix the PWM polarity > * [PATCH 2/3] pwm: lpc32xx - Properly disable the clock on device remove > * [PATCH 3/3] pwm: lpc32xx - Set the chip base for dynamic allocation All three patches applied, with the minor fixes that Roland and I requested. Thierry pgpybnC6li1mn.pgp Description: PGP signature
8250 UART doesn't work
Hi, list
Does anyone here familiar to the serial 8250 driver?
I enabled two uart ports in my board definition, but the ports doesn't
appear after I loaded the kernel (3.4.19). I discovered, it failed at
the UART port auto configuration stage, the exact function is
autoconfig(...) in drivers/tty/serial/8250.c.
...
if (!(port->flags & UPF_BUGGY_UART)) {
scratch = serial_in(up, UART_IER);
serial_out(up, UART_IER, 0);
#ifdef __i386__
outb(0xff, 0x080);
#endif
/*
* Mask out IER[7:4] bits for test as some UARTs (e.g. TL
* 16C754B) allow only to modify them if an EFR bit is set.
*/
scratch2 = serial_in(up, UART_IER) & 0x0f;
serial_out(up, UART_IER, 0x0F);
#ifdef __i386__
outb(0, 0x080);
#endif
scratch3 = serial_in(up, UART_IER) & 0x0f;
serial_out(up, UART_IER, scratch);
if (scratch2 != 0 || scratch3 != 0x0F) {
/*
* We failed; there's nothing here
*/
DEBUG_AUTOCONF("IER test failed (%02x, %02x) ",
scratch2, scratch3);
goto out;
}
}
By enabling the debug output, I found it failed because values in scratch2 and
scratch3 are all zeros.
In my board definition, what I configured are something like:
#define SERIAL_BASE (0xe140)
#define SERIAL_FLAGS (UPF_BOOT_AUTOCONF | UPF_IOREMAP | UPF_SHARE_IRQ)
#define SERIAL_CLK (14745600)
static struct plat_serial8250_port lgf2410_urts_data[] = {
[0] = {
.mapbase= SERIAL_BASE + 0x00,
.irq= 16,
.flags = SERIAL_FLAGS,
.iotype = UPIO_MEM,
.regshift = 0,
.uartclk= SERIAL_CLK,
},
[1] = {
.mapbase= SERIAL_BASE + 0x10,
.irq= 17,
.flags = SERIAL_FLAGS,
.iotype = UPIO_MEM,
.regshift = 0,
.uartclk= SERIAL_CLK,
},
};
static struct platform_device lgf2410_urts = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev= {
.platform_data = _urts_data,
},
};
I think the mapbase addresses are corrected. Since I copied these addresse from
a old kernel log output from a 2.6.16 linux. For the old 2.6.16 kernel, which
run the exact same board, I have no information how it was configured.
Below is the 2.6.16 kernel output, it successfully detected the UART
ports:
serial8250: tts0 at MMIO 0xe140 (irq = 16) is a 16550A
serial8250: tts1 at MMIO 0xe148 (irq = 16) is a 16550A
serial8250: tts2 at MMIO 0xe1400010 (irq = 17) is a 16550A
serial8250: tts3 at MMIO 0xe1400018 (irq = 17) is a 16550A
Now I expect the same result from my self tailored 3.4.19 kernel.
Hope I can get your kind support! Thanks.
--
woody
I can't go back to yesterday - because I was a different person then.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pwm: i.MX: eliminate build warning
On Wed, Dec 05, 2012 at 04:34:41PM +0100, Lothar Waßmann wrote: > compiling the i.MX pwm driver produces the following warning: > |drivers/pwm/pwm-imx.c: In function 'imx_pwm_probe': > |drivers/pwm/pwm-imx.c:281:7: warning: assignment discards qualifiers from > pointer target type > > Apply a 'const' attribute to the affected variable declaration. > > Signed-off-by: Lothar Waßmann Applied, thanks. Thierry pgpCHil5IIaYc.pgp Description: PGP signature
Re: [PATCH v5 3/3] input: Cypress PS/2 Trackpad link into psmouse-base
Hi Kamal,
On Wed, Dec 05, 2012 at 04:16:16PM -0800, Kamal Mostafa wrote:
> From: Dudley Du
>
> Original code contributed by Dudley Du (Cypress Semiconductor Corporation),
> modified by Kamal Mostafa.
>
> BugLink: http://launchpad.net/bugs/978807
Please fold it into the cypress_ps2 patch, they do not make sense
without each other.
>
> Signed-off-by: Dudley Du
> Signed-off-by: Kamal Mostafa
> Signed-off-by: Mario Limonciello
> Signed-off-by: Tim Gardner
> ---
> drivers/input/mouse/Kconfig| 10 ++
> drivers/input/mouse/Makefile |1 +
> drivers/input/mouse/psmouse-base.c | 32
> drivers/input/mouse/psmouse.h |1 +
> 4 files changed, 44 insertions(+)
>
> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
> index cd6268c..88954dd 100644
> --- a/drivers/input/mouse/Kconfig
> +++ b/drivers/input/mouse/Kconfig
> @@ -68,6 +68,16 @@ config MOUSE_PS2_SYNAPTICS
>
> If unsure, say Y.
>
> +config MOUSE_PS2_CYPRESS
> + bool "Cypress PS/2 mouse protocol extension" if EXPERT
> + default y
> + depends on MOUSE_PS2
> + help
> + Say Y here if you have a Cypress PS/2 Trackpad connected to
> + your system.
> +
> + If unsure, say Y.
> +
> config MOUSE_PS2_LIFEBOOK
> bool "Fujitsu Lifebook PS/2 mouse protocol extension" if EXPERT
> default y
> diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
> index 46ba755..323e352 100644
> --- a/drivers/input/mouse/Makefile
> +++ b/drivers/input/mouse/Makefile
> @@ -32,3 +32,4 @@ psmouse-$(CONFIG_MOUSE_PS2_LIFEBOOK)+= lifebook.o
> psmouse-$(CONFIG_MOUSE_PS2_SENTELIC) += sentelic.o
> psmouse-$(CONFIG_MOUSE_PS2_TRACKPOINT) += trackpoint.o
> psmouse-$(CONFIG_MOUSE_PS2_TOUCHKIT) += touchkit_ps2.o
> +psmouse-$(CONFIG_MOUSE_PS2_CYPRESS) += cypress_ps2.o
> diff --git a/drivers/input/mouse/psmouse-base.c
> b/drivers/input/mouse/psmouse-base.c
> index 22fe254..cff065f 100644
> --- a/drivers/input/mouse/psmouse-base.c
> +++ b/drivers/input/mouse/psmouse-base.c
> @@ -34,6 +34,7 @@
> #include "touchkit_ps2.h"
> #include "elantech.h"
> #include "sentelic.h"
> +#include "cypress_ps2.h"
>
> #define DRIVER_DESC "PS/2 mouse driver"
>
> @@ -759,6 +760,28 @@ static int psmouse_extensions(struct psmouse *psmouse,
> }
>
> /*
> + * Try Cypress Trackpad.
> + * Must try it before Finger Sensing Pad because Finger Sensing Pad probe
> + * upsets some modules of Cypress Trackpads.
> + */
> + if (max_proto > PSMOUSE_IMEX &&
> + cypress_detect(psmouse, set_properties) == 0) {
> + if (cypress_supported()) {
> + if (cypress_init(psmouse) == 0)
> + return PSMOUSE_CYPRESS;
> +
> + /*
> + * Finger Sensing Pad probe upsets some modules of
> + * Cypress Trackpad, must avoid Finger Sensing Pad
> + * probe if Cypress Trackpad device detected.
> + */
> + return PSMOUSE_PS2;
> + }
> +
> + max_proto = PSMOUSE_IMEX;
> + }
> +
> +/*
> * Try ALPS TouchPad
> */
> if (max_proto > PSMOUSE_IMEX) {
> @@ -896,6 +919,15 @@ static const struct psmouse_protocol psmouse_protocols[]
> = {
> .alias = "thinkps",
> .detect = thinking_detect,
> },
> +#ifdef CONFIG_MOUSE_PS2_CYPRESS
> + {
> + .type = PSMOUSE_CYPRESS,
> + .name = "CyPS/2",
> + .alias = "cypress",
> + .detect = cypress_detect,
> + .init = cypress_init,
> + },
> +#endif
> {
> .type = PSMOUSE_GENPS,
> .name = "GenPS/2",
> diff --git a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h
> index fe1df23..2f0b39d 100644
> --- a/drivers/input/mouse/psmouse.h
> +++ b/drivers/input/mouse/psmouse.h
> @@ -95,6 +95,7 @@ enum psmouse_type {
> PSMOUSE_ELANTECH,
> PSMOUSE_FSP,
> PSMOUSE_SYNAPTICS_RELATIVE,
> + PSMOUSE_CYPRESS,
> PSMOUSE_AUTO/* This one should always be last */
> };
>
> --
> 1.7.10.4
>
--
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 v5 1/3] input: increase struct ps2dev cmdbuf[] to 8 bytes
Hi Kamal,
On Wed, Dec 05, 2012 at 04:16:14PM -0800, Kamal Mostafa wrote:
> Cypress PS/2 Trackpad (drivers/input/mouse/cypress_ps2.c) needs
> this larger cmdbuf[] to handle 8-byte packet responses.
>
> Signed-off-by: Kamal Mostafa
I will apply this patch so you do not need to resend it with cypress_ps2
patches.
Thanks!
> ---
> include/linux/libps2.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/libps2.h b/include/linux/libps2.h
> index 79603a6..4ad06e8 100644
> --- a/include/linux/libps2.h
> +++ b/include/linux/libps2.h
> @@ -36,7 +36,7 @@ struct ps2dev {
> wait_queue_head_t wait;
>
> unsigned long flags;
> - unsigned char cmdbuf[6];
> + unsigned char cmdbuf[8];
> unsigned char cmdcnt;
> unsigned char nak;
> };
> --
> 1.7.10.4
>
--
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/
[PATCH v2] of: Output devicetree alias names in uevent
In some situations, userspace may want to resolve a
device by function and logical number (ie, "serial0")
rather than by the base address or full device path. Being
able to resolve a device by alias frees userspace from the
burden of otherwise having to maintain a mapping between
device addresses and their logical assignments on each
platform when multiple instances of the same hardware block
are present in the system.
Although the uevent device attribute contains devicetree
compatible information and the full device path, the uevent
does not list the alises that may have been defined for the
device.
Signed-off-by: Stepan Moskovchenko
---
v2: Create of_private.h and move struct alias_prop there
Add alias uevent variables from of_device_uevent
Use app->alias instead of app->stem / app->id directly
Expose alias_lookup and of_alias_mutex
drivers/of/base.c | 23 +++
drivers/of/device.c | 17 +
drivers/of/of_private.h | 33 +
3 files changed, 53 insertions(+), 20 deletions(-)
create mode 100644 drivers/of/of_private.h
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5806449..715aef2 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -24,32 +24,15 @@
#include
#include
-/**
- * struct alias_prop - Alias property in 'aliases' node
- * @link: List node to link the structure in aliases_lookup list
- * @alias: Alias property name
- * @np:Pointer to device_node that the alias stands for
- * @id:Index value from end of alias name
- * @stem: Alias string without the index
- *
- * The structure represents one alias property of 'aliases' node as
- * an entry in aliases_lookup list.
- */
-struct alias_prop {
- struct list_head link;
- const char *alias;
- struct device_node *np;
- int id;
- char stem[0];
-};
+#include "of_private.h"
-static LIST_HEAD(aliases_lookup);
+LIST_HEAD(aliases_lookup);
struct device_node *allnodes;
struct device_node *of_chosen;
struct device_node *of_aliases;
-static DEFINE_MUTEX(of_aliases_mutex);
+DEFINE_MUTEX(of_aliases_mutex);
/* use when traversing tree through the allnext, child, sibling,
* or parent members of struct device_node.
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 4c74e4f..b8d31db 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -8,6 +8,7 @@
#include
#include
+#include "of_private.h"
/**
* of_match_device - Tell if a struct device matches an of_device_id list
@@ -131,6 +132,7 @@ ssize_t of_device_get_modalias(struct device *dev, char
*str, ssize_t len)
void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
const char *compat;
+ struct alias_prop *app;
int seen = 0, cplen, sl;
if ((!dev) || (!dev->of_node))
@@ -153,6 +155,21 @@ void of_device_uevent(struct device *dev, struct
kobj_uevent_env *env)
seen++;
}
add_uevent_var(env, "OF_COMPATIBLE_N=%d", seen);
+
+ seen = 0;
+ mutex_lock(_aliases_mutex);
+ list_for_each_entry(app, _lookup, link) {
+ if (dev->of_node == app->np) {
+ add_uevent_var(env, "OF_ALIAS_%d=%s", seen,
+ app->alias);
+ seen++;
+ }
+ }
+
+ if (seen)
+ add_uevent_var(env, "OF_ALIAS_N=%d", seen);
+
+ mutex_unlock(_aliases_mutex);
}
int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
new file mode 100644
index 000..031608f
--- /dev/null
+++ b/drivers/of/of_private.h
@@ -0,0 +1,33 @@
+/* Copyright (c) 2012, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/**
+ * struct alias_prop - Alias property in 'aliases' node
+ * @link: List node to link the structure in aliases_lookup list
+ * @alias: Alias property name
+ * @np:Pointer to device_node that the alias stands for
+ * @id:Index value from end of alias name
+ * @stem: Alias string without the index
+ *
+ * The structure represents one alias property of 'aliases' node as
+ * an entry in aliases_lookup list.
+ */
+struct alias_prop {
+ struct list_head link;
+ const char *alias;
+ struct device_node *np;
+ int id;
+ char stem[0];
+};
+
+extern struct mutex of_aliases_mutex;
+extern struct list_head
Re: [PATCH v2 1/1] Input: add driver for Cypress APA I2C Trackpad
Hi Benson, On Wed, Dec 05, 2012 at 04:48:19PM -0800, Benson Leung wrote: > This patch introduces a driver for Cypress All Points Addressable > I2C Trackpad, including the ones in 2012 Samsung Chromebooks. > > This device is compatible with MT protocol type B, providing identifiable > contacts. > > Signed-off-by: Dudley Du > Signed-off-by: Daniel Kurtz > Signed-off-by: Benson Leung > --- > Version history : > v2 : * Removed firmware update. > * Removed sysfs properties related to firmware update and power mode. > * Folded cyapa_detect into cyapa_probe. > * Added support for middle and right mechanical buttons, if they exist. > * Rearranged disable_irq/enable_irq in suspend and resume to prevent > a power mode change from colliding with a read of tracking data. > * Made cyapa_get_state more reliable. > * Use IRQF_ONESHOT for threaded irq > * Simplified cyapa_set_power_mode. > * Removed extra kernel-doc style comments > * Removed dev_dbg messages. > * Cleaned up unused includes. > * Cleaned up unused #defines > v1 : Initial First of all - this version is excellent compared to the previous ones posted. I have just a few quesutions (and of course I'd like Henrik to look over MT handlingi and Jean for I2C bits). > --- > drivers/input/mouse/Kconfig | 12 + > drivers/input/mouse/Makefile |1 + > drivers/input/mouse/cyapa.c | 838 > ++ > 3 files changed, 851 insertions(+), 0 deletions(-) > create mode 100644 drivers/input/mouse/cyapa.c > > diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig > index cd6268c..23db30a 100644 > --- a/drivers/input/mouse/Kconfig > +++ b/drivers/input/mouse/Kconfig > @@ -193,6 +193,18 @@ config MOUSE_BCM5974 > To compile this driver as a module, choose M here: the > module will be called bcm5974. > > +config MOUSE_CYAPA > + tristate "Cypress APA I2C Trackpad support" > + depends on I2C > + help > + This driver adds support for Cypress All Points Addressable (APA) > + I2C Trackpads, including the ones used in 2012 Samsung Chromebooks. > + > + Say Y here if you have a Cypress APA I2C Trackpad. > + > + To compile this driver as a module, choose M here: the module will be > + called cyapa. > + > config MOUSE_INPORT > tristate "InPort/MS/ATIXL busmouse" > depends on ISA > diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile > index 46ba755..10b4773 100644 > --- a/drivers/input/mouse/Makefile > +++ b/drivers/input/mouse/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o > obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o > obj-$(CONFIG_MOUSE_ATARI)+= atarimouse.o > obj-$(CONFIG_MOUSE_BCM5974) += bcm5974.o > +obj-$(CONFIG_MOUSE_CYAPA)+= cyapa.o > obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o > obj-$(CONFIG_MOUSE_INPORT) += inport.o > obj-$(CONFIG_MOUSE_LOGIBM) += logibm.o > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c > new file mode 100644 > index 000..08cf1ce > --- /dev/null > +++ b/drivers/input/mouse/cyapa.c > @@ -0,0 +1,838 @@ > +/* > + * Cypress APA trackpad with I2C interface > + * > + * Author: Dudley Du > + * Further cleanup and restructuring by: > + * Daniel Kurtz > + * Benson Leung > + * > + * Copyright (C) 2011-2012 Cypress Semiconductor, Inc. > + * Copyright (C) 2011-2012 Google, Inc. > + * > + * This file is subject to the terms and conditions of the GNU General Public > + * License. See the file COPYING in the main directory of this archive for > + * more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* APA trackpad firmware generation */ > +#define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */ > + > +#define CYAPA_NAME "Cypress APA Trackpad (cyapa)" > + > +/* commands for read/write registers of Cypress trackpad */ > +#define CYAPA_CMD_SOFT_RESET 0x00 > +#define CYAPA_CMD_POWER_MODE 0x01 > +#define CYAPA_CMD_DEV_STATUS 0x02 > +#define CYAPA_CMD_GROUP_DATA 0x03 > +#define CYAPA_CMD_GROUP_CMD0x04 > +#define CYAPA_CMD_GROUP_QUERY 0x05 > +#define CYAPA_CMD_BL_STATUS0x06 > +#define CYAPA_CMD_BL_HEAD 0x07 > +#define CYAPA_CMD_BL_CMD 0x08 > +#define CYAPA_CMD_BL_DATA 0x09 > +#define CYAPA_CMD_BL_ALL 0x0a > +#define CYAPA_CMD_BLK_PRODUCT_ID 0x0b > +#define CYAPA_CMD_BLK_HEAD 0x0c > + > +/* report data start reg offset address. */ > +#define DATA_REG_START_OFFSET 0x > + > +#define BL_HEAD_OFFSET 0x00 > +#define BL_DATA_OFFSET 0x10 > + > +/* > + * Operational Device Status Register > + * > + * bit 7: Valid interrupt source > + * bit 6 - 4: Reserved > + * bit 3 - 2: Power status > + * bit 1 - 0: Device status > + */ > +#define
Re: [PATCH 1/2] mtd: mxc_nand: fix unbalanced clk_disable() in error path
On Thu, Dec 06, 2012 at 08:42:27AM +0100, Lothar Waßmann wrote: > If nand_scan_ident() or nand_scan_tail() fails, the NAND chip may have > been deselected and the clock already disabled. Thus, check 'clk_act' > in the error path to decide whether the clock still needs to be > disabled. > > This fixes a: > |WARNING: at drivers/clk/clk.c:472 __clk_disable+0x3c/0x78() > > Signed-off-by: Lothar Waßmann Both: Acked-by: Sascha Hauer Sascha > --- > drivers/mtd/nand/mxc_nand.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c > index d316324..d965809 100644 > --- a/drivers/mtd/nand/mxc_nand.c > +++ b/drivers/mtd/nand/mxc_nand.c > @@ -1556,7 +1556,8 @@ static int mxcnd_probe(struct platform_device *pdev) > return 0; > > escan: > - clk_disable_unprepare(host->clk); > + if (host->clk_act) > + clk_disable_unprepare(host->clk); > > return err; > } > -- > 1.7.2.5 > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] gpiolib: introduce descriptor-based GPIO interface
With the current API, GPIOs are manipulated through an integer which
represents their unique number across the system. This poses problems in
terms of portability, scalability and flexibility: for instance, the
number of valid GPIOs for a given system is fixed at system time, and a
large array of that size is statically allocated to hold the GPIO
descriptors. Worse, GPIOs can be used without being properly allocated.
In order to improve the situation, the integer namespace must first get
away. This patch introduces an alternative GPIO API that uses opaque
handlers and refactor gpiolib's internals to work with these handlers
instead of GPIO numbers. The former integer-based API is still available
as a light wrapper around this new API.
This first step will then us to build more improvements for gpiolib,
like proper GPIO lookup functions per device and provider, and getting
rid of the static GPIO array and the ARCH_NR_GPIO configuration option.
Signed-off-by: Alexandre Courbot
---
drivers/gpio/gpiolib.c| 302 ++
include/asm-generic/gpio.h| 74 ---
include/linux/gpio/consumer.h | 45 +++
3 files changed, 261 insertions(+), 160 deletions(-)
create mode 100644 include/linux/gpio/consumer.h
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1c8d9e3..bf32511 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -83,6 +83,32 @@ static inline void desc_set_label(struct gpio_desc *d, const
char *label)
#endif
}
+/**
+ * Convert a GPIO descriptor to the integer namespace.
+ * This should disappear in the future but is needed since we still
+ * use GPIO numbers for error messages and sysfs nodes
+ */
+static inline int desc_to_gpio(struct gpio_desc *desc)
+{
+ return desc - _desc[0];
+}
+
+/**
+ * Return the GPIO number of the passed descriptor relative to its chip
+ */
+int gpio_chip_offset(struct gpio_desc *desc)
+{
+ return (desc - _desc[0]) - desc->chip->base;
+}
+
+/**
+ * Convert a GPIO number to its descriptor
+ */
+struct gpio_desc *gpio_to_desc(unsigned gpio)
+{
+ return _desc[gpio];
+}
+
/* Warn when drivers omit gpio_request() calls -- legal but ill-advised
* when setting direction, and otherwise illegal. Until board setup code
* and drivers use explicit requests everywhere (which won't happen when
@@ -94,10 +120,10 @@ static inline void desc_set_label(struct gpio_desc *d,
const char *label)
* only "legal" in the sense that (old) code using it won't break yet,
* but instead only triggers a WARN() stack dump.
*/
-static int gpio_ensure_requested(struct gpio_desc *desc, unsigned offset)
+static int gpio_ensure_requested(struct gpio_desc *desc)
{
const struct gpio_chip *chip = desc->chip;
- const int gpio = chip->base + offset;
+ const int gpio = desc_to_gpio(desc);
if (WARN(test_and_set_bit(FLAG_REQUESTED, >flags) == 0,
"autorequest GPIO-%d\n", gpio)) {
@@ -116,9 +142,9 @@ static int gpio_ensure_requested(struct gpio_desc *desc,
unsigned offset)
}
/* caller holds gpio_lock *OR* gpio is marked as requested */
-struct gpio_chip *gpio_to_chip(unsigned gpio)
+struct gpio_chip *gpiod_to_chip(struct gpio_desc *desc)
{
- return gpio_desc[gpio].chip;
+ return desc->chip;
}
/* dynamic allocation of GPIOs, e.g. on a hotplugged device */
@@ -684,10 +710,9 @@ static struct class gpio_class = {
.class_attrs = gpio_class_attrs,
};
-
/**
- * gpio_export - export a GPIO through sysfs
- * @gpio: gpio to make available, already requested
+ * gpiod_export - export a GPIO through sysfs
+ * @desc: descriptor of gpio to make available, already requested
* @direction_may_change: true if userspace may change gpio direction
* Context: arch_initcall or later
*
@@ -700,12 +725,17 @@ static struct class gpio_class = {
*
* Returns zero on success, else an error.
*/
-int gpio_export(unsigned gpio, bool direction_may_change)
+int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
{
unsigned long flags;
- struct gpio_desc*desc;
int status = -EINVAL;
const char *ioname = NULL;
+ int gpio;
+
+ if (!desc)
+ goto done;
+
+ mutex_lock(_lock);
/* can't export until sysfs is available ... */
if (!gpio_class.p) {
@@ -713,13 +743,7 @@ int gpio_export(unsigned gpio, bool direction_may_change)
return -ENOENT;
}
- if (!gpio_is_valid(gpio))
- goto done;
-
- mutex_lock(_lock);
-
spin_lock_irqsave(_lock, flags);
- desc = _desc[gpio];
if (test_bit(FLAG_REQUESTED, >flags)
&& !test_bit(FLAG_EXPORT, >flags)) {
status = 0;
@@ -729,6 +753,7 @@ int gpio_export(unsigned gpio, bool direction_may_change)
}
spin_unlock_irqrestore(_lock, flags);
+ gpio
[RFC] gpiolib: introduce descriptor-based GPIO interface
Just a RFC to check if the direction seems good before going onward with more serious work. This patch introduces a set of gpiod_* functions that work like their gpio_* counterparts, but use opaque descriptors instead of integers. The current integer-based GPIO namespace is bad because it allows GPIOs to be used without being properly allocated, and poses portability concerns with the maximum number of GPIOs of the system being a compile-time constant. Some implementation details could also be improved by an opaque handler, e.g. the GPIO descriptors could be moved from the current static array to a more flexible list of GPIO chips containing their own descriptors. With this patch GPIO handles can only be obtained by calling gpio_to_desc(), which converts a valid GPIO number to its descriptor - proper lookup functions that totally get rid of GPIO numbers are the next step if this first patch is received positively. This is only a first step towards a bigger gpiolib rework. Getting rid of the integer handles for GPIOs will allow us to continue on with the following: * Proper GPIO lookup functions a la regulator, pwm, etc. * Getting rid of ARCH_NR_GPIO, * Tearing out asm-generic/gpio.h into consumer/driver include files, * ... This API is only available if gpiolib is compiled in. One could however easily implement a set of gpiod_* functions that would wrap around the old interface if that was deemed necessary. Comments and thoughts on potential issues are welcome, at this stage it is very possible that I missed a few issues that will arise in later stages of this project. Alexandre Courbot (1): gpiolib: introduce descriptor-based GPIO interface drivers/gpio/gpiolib.c| 302 ++ include/asm-generic/gpio.h| 74 --- include/linux/gpio/consumer.h | 45 +++ 3 files changed, 261 insertions(+), 160 deletions(-) create mode 100644 include/linux/gpio/consumer.h -- 1.8.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 2/2] mtd: mxc_nand: reorder part_probes to let cmdline override other sources
The cmdline is the easiest to change source of information. Thus
let it take precedence over 'RedBoot' and 'ofpart'. This makes the
mxc_nand driver to be in sync with all other NAND drivers that support
'cmdlinepart' partition parsing.
Also change 'const char *' to 'const char const *' as advised by checkpatch.pl
Signed-off-by: Lothar Waßmann
---
drivers/mtd/nand/mxc_nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index d316324..fb98775 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -266,7 +266,8 @@ static struct nand_ecclayout nandv2_hw_eccoob_4k = {
}
};
-static const char *part_probes[] = { "RedBoot", "cmdlinepart", "ofpart", NULL
};
+static const char const *part_probes[] = {
+ "cmdlinepart", "RedBoot", "ofpart", NULL };
static void memcpy32_fromio(void *trg, const void __iomem *src, size_t size)
{
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mtd: mxc_nand: fix unbalanced clk_disable() in error path
If nand_scan_ident() or nand_scan_tail() fails, the NAND chip may have been deselected and the clock already disabled. Thus, check 'clk_act' in the error path to decide whether the clock still needs to be disabled. This fixes a: |WARNING: at drivers/clk/clk.c:472 __clk_disable+0x3c/0x78() Signed-off-by: Lothar Waßmann --- drivers/mtd/nand/mxc_nand.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c index d316324..d965809 100644 --- a/drivers/mtd/nand/mxc_nand.c +++ b/drivers/mtd/nand/mxc_nand.c @@ -1556,7 +1556,8 @@ static int mxcnd_probe(struct platform_device *pdev) return 0; escan: - clk_disable_unprepare(host->clk); + if (host->clk_act) + clk_disable_unprepare(host->clk); return err; } -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: i.MX: eliminate build warning
On Wed, Dec 05, 2012 at 04:34:41PM +0100, Lothar Waßmann wrote:
> compiling the i.MX pwm driver produces the following warning:
> |drivers/pwm/pwm-imx.c: In function 'imx_pwm_probe':
> |drivers/pwm/pwm-imx.c:281:7: warning: assignment discards qualifiers from
> pointer target type
>
> Apply a 'const' attribute to the affected variable declaration.
>
> Signed-off-by: Lothar Waßmann
Acked-by: Sascha Hauer
Sascha
> ---
> drivers/pwm/pwm-imx.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> index 8f26e9f..65a86bd 100644
> --- a/drivers/pwm/pwm-imx.c
> +++ b/drivers/pwm/pwm-imx.c
> @@ -235,7 +235,7 @@ static int imx_pwm_probe(struct platform_device *pdev)
> {
> const struct of_device_id *of_id =
> of_match_device(imx_pwm_dt_ids, >dev);
> - struct imx_pwm_data *data;
> + const struct imx_pwm_data *data;
> struct imx_chip *imx;
> struct resource *r;
> int ret = 0;
> --
> 1.7.2.5
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/8] fat: restructure export_operations
2012/12/5, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>>> I can understand what is doing. I'm asking why there is difference.
>>>
>>> 1) generic_fh_to_dentry() allows (*_PARENT && fh_len == 2).
>>> 2) fat_fh_to_dentry_nostale() doesn't allows (*_PARENT && fh_len == 3).
>>>
>>> Why does logic has difference?
>>
>> When we consider the generic routine of encode_fh() and the structure
>> ‘fid’
>>
>> struct fid {
>> struct {
>> u32 ino;
>> u32 gen;
>> u32 parent_ino;
>> u32 parent_gen;
>> } i32;
>> };
>>
>> fh_len= 2(without parent)
>> fh_len=4(with parent)
>>
>> Condition checking in export_encode_fh()
>> {
>>
>>if (parent && (len < 4)) {
>> *max_len = 4;
>> return FILEID_INVALID;
>> } else if (len < 2) {
>> *max_len = 2;
>> return FILEID_INVALID;
>> }
>> ...
>> len = 2;
>> ...
>> if (parent) {
>> ..
>> len = 4;
>> type = FILEID_INO32_GEN_PARENT;
>> }
>> …
>> }
>>
>> The logic does take care of altering the length for the ‘2’ cases
>> with/without parent.
>> So, while encoding -> the care has been taken for length checking but
>> while decoding(generic_fh_to_dentry) the length check is not put in
>> place.
>> I think it should be done in the generic routine also.
>>
>> It should be:
>> if ((fh_len != 2 && fh_len != 4) ||
>> (fh_type != FILEID_INO32_GEN && fh_type !=
>> FILEID_INO32_GEN_PARENT))
>> return NULL;
>>
>> Please share your opinion.
>
> I know encode_fh(). But NFS is network protocol, and network can input
> any data, and I guess the userland interface (open_by_handle()?) can be
> any too.
>
> And generic_fh_to_dentry()'s input verify choose to check the minimum
> length only. But your logic choose the exact length.
>
> I think the both is sane and correct. But I wonder why did you changed it.
There was no particular reason for us to put those conditions. It is
just we knew what fh lengths we have chosen for the 2 cases
WITH/WITHOUT parent.
i.e., we checked with encoded length.
Now, when I check the export functions of other filesystems(btrfs,
nilfs2, udf). They also adopt the same method of checking the exact
length and type.
If there is any particular reason, we will look into that and can also
updated on that.
Thanks.
> --
> OGAWA Hirofumi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6 v9] gpio: Add userland device interface to block GPIO
On 12/05/2012 11:20 PM, Roland Stigge wrote:
> Hi Wolfgang,
>
> On 05/12/12 20:01, Wolfgang Grandegger wrote:
>>> + for (i = 0; i < block->ngpio; i++) {
>>> + status = gpio_request(block->gpio[i], "gpioblock dev");
>>
>> You could use the name of the GPIO block.
>
> OK.
>
>>> + if (status)
>>> + goto err1;
>>> +
>>> + irq = gpio_to_irq(block->gpio[i]);
>>> + if (irq >= 0 &&
>>> + !test_bit(FLAG_IS_OUT, _desc[block->gpio[i]].flags) &&
>>> + !gpio_block_is_irq_duplicate(block, i)) {
>>> + status = request_irq(irq, gpio_block_irq_handler,
>>> +IRQF_TRIGGER_FALLING,
>>> +block->name, block);
>>> + if (status)
>>> + goto err2;
>>> +
>>> + block->irq_controlled = true;
>>> + }
>>> + }
>>
>> There is no need to request IRQs if "O_NONBLOCK" is specified.
>
> Sure? Regarding this, I found: "The poll() function shall not be
> affected by the O_NONBLOCK flag." [1]
Ah, didn't know that.
>> I observed that the read returns once immediately (without blocking)
>> after reboot. I did not look into that yet.
>
> Didn't happen to me. Can you tell how this can be reproduced?
I think there is an interrupt pending for some reason. It might not be
the case with your setup.
Feel free to add my:
"Tested by: Wolfgang Grandegger ".
Will do some more tests when time permits, especially with mixed GPIO
input and output.
Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: MMU: optimize for set_spte
On Tue, Dec 04, 2012 at 07:17:11AM +0800, Xiao Guangrong wrote:
> There are two cases we need to adjust page size in set_spte:
> 1): the one is other vcpu creates new sp in the window between mapping_level()
> and acquiring mmu-lock.
> 2): the another case is the new sp is created by itself (page-fault path) when
> guest uses the target gfn as its page table.
>
> In current code, set_spte drop the spte and emulate the access for these case,
> it works not good:
> - for the case 1, it may destroy the mapping established by other vcpu, and
> do expensive instruction emulation.
> - for the case 2, it may emulate the access even if the guest is accessing
> the page which not used as page table. There is a example, 0~2M is used as
> huge page in guest, in this huge page, only page 3 used as page table, then
> guest read/writes on other pages can cause instruction emulation.
>
> Both of these cases can be fixed by allowing guest to retry the access, it
> will refault, then we can establish the mapping by using small page
>
> Signed-off-by: Xiao Guangrong
Applied to queue. Thanks.
> ---
> arch/x86/kvm/mmu.c | 16
> 1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index b875a9e..01d7c2a 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -2382,12 +2382,20 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
> || (!vcpu->arch.mmu.direct_map && write_fault
> && !is_write_protection(vcpu) && !user_fault)) {
>
> + /*
> + * There are two cases:
> + * - the one is other vcpu creates new sp in the window
> + * between mapping_level() and acquiring mmu-lock.
> + * - the another case is the new sp is created by itself
> + * (page-fault path) when guest uses the target gfn as
> + * its page table.
> + * Both of these cases can be fixed by allowing guest to
> + * retry the access, it will refault, then we can establish
> + * the mapping by using small page.
> + */
> if (level > PT_PAGE_TABLE_LEVEL &&
> - has_wrprotected_page(vcpu->kvm, gfn, level)) {
> - ret = 1;
> - drop_spte(vcpu->kvm, sptep);
> + has_wrprotected_page(vcpu->kvm, gfn, level))
> goto done;
> - }
>
> spte |= PT_WRITABLE_MASK | SPTE_MMU_WRITEABLE;
>
> --
> 1.7.7.6
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PULL] (Was Re: [PATCH 3.7-rc8] lib/Makefile: Fix oid_registry build dependency)
Tim Gardner writes: > It is $(obj)/oid_registry.o that is dependent on $(obj)/oid_registry_data.c. > The object file cannot be built until $(obj)/oid_registry_data.c has been > generated. > > A periodic and hard to reproduce parallel build failure is due to > this incorrect lib/Makefile dependency. The compile error is completely > disingenuous. > > GEN lib/oid_registry_data.c > Compiling 49 OIDs > CC lib/oid_registry.o > gcc: error: lib/oid_registry.c: No such file or directory > gcc: fatal error: no input files > compilation terminated. > make[3]: *** [lib/oid_registry.o] Error 4 I can't reproduce it either. It's completely weird; nothing ever removes lib/oid_registry.c, so either gcc is giving the wrong message or it's a weird fs with a very odd race. But your version is definitely more correct than the previous one, so... Linus, please pull my 'more-fixes' branch: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git more-fixes Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] staging/rtl8192u: indent with tabs, not spaces
On Wed, Dec 05, 2012 at 09:40:20PM +0100, Sebastian Hahn wrote: > Converted staging/rtl8187se to use tabs instead of spaces for > indentation to fix the checkpatch error "code indent should use tabs > where possible". > > Signed-off-by: Sebastian Hahn > --- > drivers/staging/rtl8192u/ieee80211/ieee80211.h | 14 +- > drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 370 > ++-- > .../staging/rtl8192u/ieee80211/ieee80211_softmac.c |4 +- > drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 14 +- > drivers/staging/rtl8192u/ieee80211/rtl_crypto.h| 84 ++--- > drivers/staging/rtl8192u/r8180_93cx6.c |2 +- > drivers/staging/rtl8192u/r8180_93cx6.c.bak | 146 You merged a .c.bak file into the kernel. > drivers/staging/rtl8192u/r8180_pm.h|2 +- > drivers/staging/rtl8192u/r8192U.h | 198 +-- > drivers/staging/rtl8192u/r8192U_core.c | 42 +-- > 10 files changed, 511 insertions(+), 365 deletions(-) regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Regulator suspend state dt question
Hi Mark, On Thu, Dec 6, 2012 at 11:58 AM, Mark Brown wrote: > On Thu, Dec 06, 2012 at 11:55:11AM +0530, Abhilash Kesavan wrote: > >> As of now there is no support in the regulator core to specify the suspend >> state >> (mode, enabled/disabled) using dt. I can add new properties specifying >> the intial_state, >> mode, enable/disable but I am not too sure if it is appropriate to add >> such bindings to >> the device tree as they are not actually describing the hardware. > > Well, it does depend on the hardware a bit - some hardware is hard wired > to only have one possible suspend state due to power up requirements. > But for a lot of hardware it's flexible... So, adding such new properties to the drivers/regulator/of_regulator.c file would not be acceptable right ? > >> Is calling regulator_suspend_prepare from a machine specific file an option ? > > This is not really relevant, it's an orthogonal thing about when we > trigger the state transition in the regulator. OK > > It's not clear what a good solution is here, sorry. Would it be acceptable that I add a new optional "op_mode" property for max77686 ? If the property is found in dt then assign the value to max77686->opmode[i] else use enable_mask. I'll be doing this in probe for all the regulators. Thanks for your help. Abhilash -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC 2/2] kvm: Handle yield_to failure return code for potential undercommit case
On 12/04/2012 01:26 AM, Marcelo Tosatti wrote: On Wed, Nov 28, 2012 at 10:40:56AM +0530, Raghavendra K T wrote: On 11/28/2012 06:42 AM, Marcelo Tosatti wrote: Don't understand the reasoning behind why 3 is a good choice. Here is where I came from. (explaining from scratch for completeness, forgive me :)) In moderate overcommits, we can falsely exit from ple handler even when we have preempted task of same VM waiting on other cpus. To reduce this problem, we try few times before exiting. The problem boils down to: what is the probability that we exit ple handler even when we have more than 1 task in other cpus. Theoretical worst case should be around 1.5x overcommit (As also pointed by Andrew Theurer). [But practical worstcase may be around 2x,3x overcommits as indicated by the results for the patch series] So if p is the probability of finding rq length one on a particular cpu, and if we do n tries, then probability of exiting ple handler is: p^(n+1) [ because we would have come across one source with rq length 1 and n target cpu rqs with length 1 ] so num tries: probability of aborting ple handler (1.5x overcommit) 1 1/4 2 1/8 3 1/16 We can increase this probability with more tries, but the problem is the overhead. Also, If we have tried three times that means we would have iterated over 3 good eligible vcpus along with many non-eligible candidates. In worst case if we iterate all the vcpus, we reduce 1x performance and overcommit performance get hit. [ as in results ]. I have tried num_tries = 1,2,3 and n already ( not 4 yet). So I concluded 3 is enough. Infact I have also run kernbench and hackbench which are giving 5-20% improvement. [ As a side note , I also thought how about having num_tries = f(n) = ceil ( log(num_online_cpus)/2 ) But I thought calculation is too much overhead and also there is no point in probably making it dependent on online cpus ] Please let me know if you are happy with this rationale/ or correct me if you foresee some problem. (Infact Avi, Rik's concern about false exiting made me arrive at 'try' logic which I did not have earlier). I am currently trying out the result for 1.5x overcommit will post the result. Raghavendra Makes sense to me. Thanks. Marcelo, Do you think this can be considered for next merge window? or you are expecting anything else on this patchset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: weakness of runnable load tracking?
Hi Alex, > Hi Paul & Ingo: > > In a short word of this issue: burst forking/waking tasks have no time > accumulate the load contribute, their runnable load are taken as zero. On performing certain experiments on the way PJT's metric calculates the load,I observed a few things.Based on these observations let me see if i can address the issue of why PJT's metric is calculating the load of bursty tasks as 0. When we speak about a burst waking task(I will not go into forking here),we should also speak about its duty cycle-it burst wakes for 1ms for a 10ms duty cycle or burst wakes 9s out of a 10s duty cycle-both being 10% tasks wrt their duty cycles.Lets see how load is calculated by PJT's metric in each of the above cases. -- | | | | __| | A B 1ms <-> 10ms <> Example 1 When the task wakes up at A,it is not yet runnable,and an update of the task load takes place.Its runtime so far is 0,and its existing time is 10ms.Hence the load is 0/10*1024.Since a scheduler tick happens at B( a scheduler tick happens for every 1ms,10ms or 4ms.Let us assume 1ms),an update of the load takes place.PJT's metric divides the time elapsed into 1ms windows.There is just 1ms window,and hence the runtime is 1ms and the load is 1ms/10ms*1024. *If the time elapsed between A and B were to be < 1ms,then PJT's metric will not capture it*. And under these circumstances the load remains 0/10ms*1024=0.This is the situation you are pointing out.Let us assume that these cycle continues throughout the lifetime of the load,then the load remains at 0.The question is if such tasks which run for periods<1ms is ok to be termed as 0 workloads.If it is fine,then what PJT's metric is doing is right.Maybe we should ignore such workloads because they hardly contribute to the load.Otherwise we will need to reduce the window of load update to < 1ms to capture such loads. Just for some additional info so that we know what happens to different kinds of loads with PJT's metric,consider the below situation: -- | | | | | | A B 1s <--> <---> 10s <> Example 2 Here at A,the task wakes,just like in Example1 and the load is termed 0. In between A and B for every scheduler tick if we consider the load to get updated,then the load slowly increases from 0 to 1024 at B.It is 1024 here,although this is also a 10% task,whereas in Example1 the load is 102.4 - a 10% task.So what is fishy? In my opinion,PJT's metric gives the tasks some time to prove their activeness after they wake up.In Example2 the task has stayed awake too long-1s; irrespective of what % of the total run time it is.Therefore it calculates the load to be big enough to balance. In the example that you have quoted,the tasks may not have run long enough to consider them as candidates for load balance. So,essentially what PJT's metric is doing is characterising a task by the amount it has run so far. > that make select_task_rq do a wrong decision on which group is idlest. > > There is still 3 kinds of solution is helpful for this issue. > > a, set a unzero minimum value for the long time sleeping task. but it > seems unfair for other tasks these just sleep a short while. > > b, just use runnable load contrib in load balance. Still using > nr_running to judge idlest group in select_task_rq_fair. but that may > cause a bit more migrations in future load balance. > > c, consider both runnable load and nr_running in the group: like in the > searching domain, the nr_running number increased a certain number, like > double of the domain span, in a certain time. we will think it's a burst > forking/waking happened, then just count the nr_running as the idlest > group criteria. > > IMHO, I like the 3rd one a bit more. as to the certain time to judge if > a burst happened, since we will calculate the runnable avg at very tick, > so if increased nr_running is beyond sd->span_weight in 2 ticks, means > burst happening. What's your opinion of this? > > Any comments are appreciated! So Pjt's metric rightly seems to be capturing the load of these bursty tasks but you are right in pointing out that when too many such loads queue up on the cpu,this metric will consider the load on the cpu as 0,which might not be such a good idea. It is true that we need to bring in nr_running somewhere.Let me now go through your suggestions on where to include nr_running and get back on this.I had planned on including nr_running while selecting the busy group in update_sd_lb_stats,but select_task_rq_fair is yet another place to do this, thats right.Good that this issue was brought up :) > Regards! > Alex >> >> >
Re: [RFC PATCH 0/8][Sorted-buddy] mm: Linux VM Infrastructure to support Memory Power Management
Hi Jianguo, On 12/04/2012 04:21 PM, wujianguo wrote: > Hi Srivatsa, > > I applied this patchset, and run genload(from LTP) test: numactl --membind=1 > ./genload -m 100, > then got a "general protection fault", and system was going to reboot. > > If I revert [RFC PATCH 7/8], and run this test again, genload will be killed > due to OOM, > but the system is OK, no coredump. > Sorry for the delay in replying. Thanks a lot for testing and for the bug-report! I could recreate the issue in one of my machines using the LTP test you mentioned. I'll try to dig and find out what is going wrong. Regards, Srivatsa S. Bhat > ps: node1 has 8G memory. > > [ 3647.020666] general protection fault: [#1] SMP > [ 3647.026232] Modules linked in: edd cpufreq_conservative cpufreq_userspace > cpu > freq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm > crc32c_ > intel ixgbe ipv6 i7core_edac igb iTCO_wdt i2c_i801 iTCO_vendor_support > ioatdma e > dac_core tpm_tis joydev lpc_ich i2c_core microcode mfd_core rtc_cmos pcspkr > sr_m > od tpm sg dca hid_generic mdio tpm_bios cdrom button ext3 jbd mbcache usbhid > hid > uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys > hw > mon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic > ata_ > piix libata megaraid_sas scsi_mod > [ 3647.084565] CPU 19 > [ 3647.086709] Pid: 33708, comm: genload Not tainted 3.7.0-rc7-mem-region+ > #11 Q > CI QSSC-S4R/QSSC-S4R > [ 3647.096799] RIP: 0010:[] [] > add_to_freel > ist+0x8c/0x100 > [ 3647.106125] RSP: :880a7f6c3e58 EFLAGS: 00010086 > [ 3647.112042] RAX: dead00200200 RBX: 0001 RCX: > > > [ 3647.119990] RDX: ea001211a3a0 RSI: ea001211ffa0 RDI: > 0001 > > [ 3647.127936] RBP: 880a7f6c3e58 R08: 88067ff6d240 R09: > 88067ff6b180 > > [ 3647.135884] R10: 0002 R11: 0001 R12: > 07fe > > [ 3647.143831] R13: 0001 R14: 0001 R15: > ea001211ff80 > > [ 3647.151778] FS: 7f0b2a674700() GS:880a7f6c() > knlGS:0 > 000 > [ 3647.160790] CS: 0010 DS: ES: CR0: 8005003b > [ 3647.167188] CR2: 7f0b1a00 CR3: 000484723000 CR4: > 07e0 > > [ 3647.175136] DR0: DR1: DR2: > > > [ 3647.183083] DR3: DR6: 0ff0 DR7: > 0400 > > [ 3647.191030] Process genload (pid: 33708, threadinfo 8806852bc000, task > ff > ff880688288000) > [ 3647.200428] Stack: > [ 3647.202667] 880a7f6c3f08 8110e9c0 88067ff66100 > 0 > 7fe > [ 3647.210954] 880a7f6d5bb0 0030 2030 > 88067ff66 > 168 > [ 3647.219244] 0002 880a7f6d5b78 000e88288000 > 88067ff66 > 100 > [ 3647.227530] Call Trace: > [ 3647.230252] > [ 3647.232394] [] free_pcppages_bulk+0x350/0x450 > [ 3647.239297] [] ? drain_pages+0xd0/0xd0 > [ 3647.245313] [] drain_pages+0xc3/0xd0 > [ 3647.251135] [] drain_local_pages+0x16/0x20 > [ 3647.257540] [] > generic_smp_call_function_interrupt+0xae/0x > 260 > [ 3647.265783] [] smp_call_function_interrupt+0x27/0x40 > [ 3647.273156] [] call_function_interrupt+0x72/0x80 > [ 3647.280136] > [ 3647.282278] [] ? mutex_spin_on_owner+0x76/0xa0 > [ 3647.289292] [] __mutex_lock_slowpath+0x66/0x180 > [ 3647.296181] [] ? try_to_unmap_one+0x277/0x440 > [ 3647.302872] [] mutex_lock+0x23/0x40 > [ 3647.308595] [] rmap_walk+0x137/0x240 > [ 3647.314417] [] ? get_page+0x40/0x40 > [ 3647.320133] [] move_to_new_page+0xb6/0x110 > [ 3647.326526] [] __unmap_and_move+0x192/0x230 > [ 3647.333023] [] unmap_and_move+0x122/0x140 > [ 3647.339328] [] migrate_pages+0x99/0x150 > [ 3647.345433] [] ? isolate_freepages+0x220/0x220 > [ 3647.352220] [] compact_zone+0x2f2/0x5d0 > [ 3647.358332] [] try_to_compact_pages+0x180/0x240 > [ 3647.365218] [] __alloc_pages_direct_compact+0x97/0x200 > [ 3647.372780] [] ? on_each_cpu_mask+0x63/0xb0 > [ 3647.379279] [] __alloc_pages_slowpath+0x4ff/0x780 > [ 3647.386349] [] __alloc_pages_nodemask+0x121/0x180 > [ 3647.393430] [] alloc_pages_vma+0xd6/0x170 > [ 3647.399737] [] do_huge_pmd_anonymous_page+0x148/0x210 > [ 3647.407203] [] handle_mm_fault+0x33b/0x340 > [ 3647.413609] [] __do_page_fault+0x2a3/0x4e0 > [ 3647.420017] [] ? trace_hardirqs_off_thunk+0x3a/0x6c > [ 3647.427290] [] do_page_fault+0xe/0x10 > [ 3647.433208] [] page_fault+0x28/0x30 > [ 3647.438921] Code: 8d 78 01 48 89 f8 48 c1 e0 04 49 8d 04 00 48 8b 50 08 48 > 83 > 40 10 01 48 85 d2 74 1b 48 8b 42 08 48 89 72 08 48 89 16 48 89 46 08 <48> 89 > 30 > c9 c3 0f 1f 80 00 00 00 00 4d 3b 00 74 4b 83 e9 01 79 > [ 3647.460607] RIP [] add_to_freelist+0x8c/0x100 > [ 3647.467308] RSP > [0.00] Linux version 3.7.0-rc7-mem-region+ (root@linux-intel) (gcc > versi > on 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) )
[PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
Create a 'debounce' attribute if debounce is supported by the gpio
chip and a gpio pin is exported.
Signed-off-by: Guenter Roeck
---
drivers/gpio/gpiolib.c | 59
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a971e3d..13ee9a7 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -67,6 +67,7 @@ struct gpio_desc {
#ifdef CONFIG_DEBUG_FS
const char *label;
#endif
+ unsigneddebounce;
};
static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
@@ -215,6 +216,10 @@ static DEFINE_MUTEX(sysfs_lock);
* * is read/write as zero/nonzero
* * also affects existing and subsequent "falling" and "rising"
*/edge configuration
+ * /debounce
+ * * configures debounce time in uS
+ * * available only if debounce is supported by the chip
+ * * is read/write; 0 to disable or debounce time
*/
static ssize_t gpio_direction_show(struct device *dev,
@@ -320,6 +325,55 @@ static ssize_t gpio_value_store(struct device *dev,
static const DEVICE_ATTR(value, 0644,
gpio_value_show, gpio_value_store);
+static ssize_t gpio_debounce_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t status;
+
+ mutex_lock(_lock);
+
+ if (!test_bit(FLAG_EXPORT, >flags))
+ status = -EIO;
+ else
+ status = sprintf(buf, "%u\n", desc->debounce);
+
+ mutex_unlock(_lock);
+ return status;
+}
+
+static ssize_t gpio_debounce_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ unsignedgpio = desc - gpio_desc;
+ ssize_t status;
+
+ mutex_lock(_lock);
+
+ if (!test_bit(FLAG_EXPORT, >flags))
+ status = -EIO;
+ else if (test_bit(FLAG_IS_OUT, >flags))
+ status = -EPERM;
+ else {
+ longvalue;
+
+ status = kstrtoul(buf, 0, );
+ if (status == 0) {
+ status = gpio_set_debounce(gpio, value);
+ if (status == 0)
+ status = size;
+ }
+ }
+
+ mutex_unlock(_lock);
+ return status;
+}
+
+static const DEVICE_ATTR(debounce, 0644,
+gpio_debounce_show, gpio_debounce_store);
+
static irqreturn_t gpio_sysfs_irq(int irq, void *priv)
{
struct sysfs_dirent *value_sd = priv;
@@ -741,6 +795,10 @@ int gpio_export(unsigned gpio, bool direction_may_change)
status = device_create_file(dev,
_attr_direction);
+ if (!status && desc->chip->set_debounce)
+ status = device_create_file(dev,
+ _attr_debounce);
+
if (!status && gpio_to_irq(gpio) >= 0
&& (direction_may_change
|| !test_bit(FLAG_IS_OUT,
@@ -1507,6 +1565,7 @@ int gpio_set_debounce(unsigned gpio, unsigned debounce)
might_sleep_if(chip->can_sleep);
+ desc->debounce = debounce;
return chip->set_debounce(chip, gpio, debounce);
fail:
--
1.7.5.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: Regulator suspend state dt question
On Thu, Dec 06, 2012 at 11:55:11AM +0530, Abhilash Kesavan wrote: > As of now there is no support in the regulator core to specify the suspend > state > (mode, enabled/disabled) using dt. I can add new properties specifying > the intial_state, > mode, enable/disable but I am not too sure if it is appropriate to add > such bindings to > the device tree as they are not actually describing the hardware. Well, it does depend on the hardware a bit - some hardware is hard wired to only have one possible suspend state due to power up requirements. But for a lot of hardware it's flexible... > Is calling regulator_suspend_prepare from a machine specific file an option ? This is not really relevant, it's an orthogonal thing about when we trigger the state transition in the regulator. It's not clear what a good solution is here, sorry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET cgroup/for-3.8] cpuset: decouple cpuset locking from cgroup core
On 2012/12/4 0:53, Tejun Heo wrote: > Hello, Michal. > > On Mon, Dec 03, 2012 at 04:22:05PM +0100, Michal Hocko wrote: >> I have glanced through the series and spotten nothing obviously wrong. I >> do not feel I could give my r-b because I am not familiar with cpusets >> internals enough and some patches looks quite scary (like #8). >> Anyway the resulting outcome seems nice. > > Thanks a lot for looking at it and, yeah, it's a bit scary. Li, Paul, > can you guys please review the series? > We shoudn't haste to target this for 3.8, given that we're in late -rc and Michal felt some patches scary and they hasn't got enough review. I'll squeeze time to review them, but currently I've been backlogged with internal work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: gpio-regulator: Add ifdef CONFIG_OF guard for regulator_gpio_of_match
On Tue, Dec 04, 2012 at 10:32:05AM +0800, Axel Lin wrote: > Use of_match_ptr and add ifdef CONFIG_OF guard for regulator_gpio_of_match. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v1] regulator: new driver for LP8755
>
>From: Kim, Milo
>Sent: Thursday, December 06, 2012 2:34 PM
>To: Daniel Jeong
>Cc: Jeong, Daniel; linux-ker...@ver.kernel.org; Girdwood, Liam; Mark Brown
>Subject: RE: [PATCH v1] regulator: new driver for LP8755
>
>Hi Daniel,
>
>> This driver is a general version for lp8755 regulator driver of TI.
>>
>> LP8755 :
>> The LP8755 is a high performance power management unit.It contains six
>> step-down DC-DC converters which can can be filexibly bundled together
>> in multiphase converters as required by application.
>> www.ti.com
>>
>> Signed-off-by: Daniel Jeong
>
>I've added few comments on your code.
>(return code, error handling and regulator notification events) Other things
>look good to me.
>
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 67d47b59..63e37ff 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -257,6 +257,15 @@ config REGULATOR_LP872X
>> help
>>This driver supports LP8720/LP8725 PMIC
>>
>> +config REGULATOR_LP8755
>> +tristate "TI LP8755 Hihg Performance PMU driver"
>
>Typo, 'High'.
Oops. Thank you for your comments.
>
>> +struct lp8755_chip {
>> +struct device *dev;
>> +struct regmap *regmap;
>> +struct lp8755_platform_data *pdata;
>> +
>> +int irq;
>> +unsigned int irqmask;
>> +
>> +int num_reg;
>
>Can 'num_reg' be removed if unnecessary?
>
You're right. It should be dropped. Thank you.
>> +static unsigned int lp8755_buck_get_mode(struct regulator_dev *rdev)
>> +{
>> +int ret;
>> +unsigned int regval;
>> +enum lp8755_bucks id = rdev_get_id(rdev);
>> +struct lp8755_chip *pchip = rdev_get_drvdata(rdev);
>> +
>> +ret = lp8755_read(pchip, 0x06, );
>> +if (ret < 0)
>> +goto err_i2c;
>> +/* mode fast means forced pwm mode */
>> +if (regval & (0x01 << id))
>> +return REGULATOR_MODE_FAST;
>> +
>> +ret = lp8755_read(pchip, 0x10, );
>> +if (ret < 0)
>> +goto err_i2c;
>> +/* mode normal means automatic pwm/pfm mode */
>> +if ((regval & 0x01) == 0)
>> +return REGULATOR_MODE_NORMAL;
>> +
>> +ret = lp8755_read(pchip, 0x08 + id, );
>> +if (ret < 0)
>> +goto err_i2c;
>> +/* mode idle means automatic pwm/pfm/lppfm mode */
>> +if (regval & 0x20)
>> +return REGULATOR_MODE_IDLE;
>> +
>> +err_i2c:
>> +dev_err(pchip->dev, "i2c acceess error %s\n", __func__);
>> +return ret;
>
>Return 0 is better because the return type of _get_mode is unsigned int.
>
>> +
>> +/* interrupts */
>> +enum lp8755_irq {
>> +LP8755_IRQ_OCP = 0,
>> +LP8755_IRQ_OVP,
>> +LP8755_IRQ_B0,
>> +LP8755_IRQ_B1,
>> +LP8755_IRQ_B2,
>> +LP8755_IRQ_B3,
>> +LP8755_IRQ_B4,
>> +LP8755_IRQ_B5,
>> +LP8755_IRQ_MAX,
>> +};
>
>Can 'lp8755_irq' be removed if unnecessary?
You're right. It should be dropped. Thank you.
>
>> +static int lp8755_int_config(struct lp8755_chip *pchip) {
>> +int ret;
>> +unsigned int regval;
>> +
>> +if (pchip->irq == 0) {
>> +dev_warn(pchip->dev, "not use interrupt : %s\n", __func__);
>> +return 0;
>> +}
>> +
>> +ret = lp8755_read(pchip, 0x0F, );
>> +if (ret < 0)
>> +goto err_i2c;
>> +pchip->irqmask = regval;
>> +ret = request_threaded_irq(pchip->irq, NULL, lp8755_irq_handler,
>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> + "lp8755-irq", pchip);
>> +if (ret)
>> +return -1;
>
>Return 'ret', not '-1'.
>
>> +err_irq:
>> +dev_err(>dev, "fail to irq config\n");
>> +
>> +for (icnt = 0; icnt < mphase_buck[pchip->mphase].nreg; icnt++)
>> +regulator_unregister(pchip->rdev[icnt]);
>> +
>> +err_regulator:
>> +dev_err(>dev, "fail to initialize regulators\n");
>> +/* output disable */
>> +for (icnt = 0; icnt < 0x06; icnt++)
>> +lp8755_write(pchip, icnt, 0x80);
>
>I'm curious the reason why the value is different from handling in _remove().
>In _remove(), 0x0 ~ 0x5 registers are cleared.
>
> for (icnt = 0; icnt < 0x06; icnt++)
> lp8755_write(pchip, icnt, 0x00);
> However, these registers are
> updated to 0x80 when lp8755_regulator_int() gets failed.
>
> for (icnt = 0; icnt < 0x06; icnt++)
> lp8755_write(pchip, icnt, 0x80);
> I'm not sure this point is
> meaningful. Could you check this?
>
>> diff --git a/include/linux/platform_data/lp8755.h
>> b/include/linux/platform_data/lp8755.h
>> new file mode 100644
>> index 000..a7fd077
>> --- /dev/null
>> +++ b/include/linux/platform_data/lp8755.h
>> @@ -0,0 +1,71 @@
>> +/*
>> + * LP8755 High Performance Power Management Unit Driver:System
>> Interface Driver
>> + *
>> + * Copyright (C) 2012 Texas Instruments
>> + *
>> + * Author: Daniel(Geon Si) Jeong
>> + *
Re: [RFT][PATCH 1/2] regulator: palmas: Return raw register values as the selectors in [get|set]_voltage_sel
On Thu, Nov 29, 2012 at 09:59:16AM +0800, Axel Lin wrote: > Don't adjust the selector in [get|set]_voltage_sel, fix it in list_voltage() > instead. Applied both, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use PCI ROMs from EFI boot services
On Wed, Dec 05, 2012 at 05:21:44PM -0800, H. Peter Anvin wrote: > On 12/05/2012 05:13 PM, Matthew Garrett wrote: > >Yeah, it needs to be hidden from root - but ideally we'd be passing it to > >the second kernel if we kexec. Alternative would be for it to be capability > >bounded to a trusted signed kexec binary if we implement Vivek's IMA-based > >approach. > > > > Either way a security flag in the type field makes sense. I've no objection to that, although I'm not sure there's any real reason to expose an incomplete setup_data to userspace. Any scenario in which kexec can't read the full data is one where kexec won't be able to call sys_kexec() anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] regulators: add regulator_can_change_voltage() function
On Tue, Dec 04, 2012 at 03:01:01PM +0100, Marek Szyprowski wrote: > Introduce a regulator_can_change_voltage() function for the subsytems or > drivers which might check if applying voltage change is possible and use > special workaround code when the driver is used with fixed regulators or > regulators with disabled ability to change the voltage. Applied, thanks. I've put it on a topic branch and will push a signed tag called can-change-voltage or similar as soon as I can, feel free to merge elsewhere (ideally the signed tag). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: need help on a DEADLOCK problem related to function try_one_irq()
Hello Thomas, Stoney, Warner -
Thanks for your patience. :) The patch from Thomas works here, too.
I can add that when I made the patch that became 52553ddffad76cc, I
didn't understand why we needed to run the handler again, in that
test:
(action->handler(irq, action->dev_id) == IRQ_HANDLED)
But without it, irqfixup and irqpoll weren't working. And I can't
pretend I have a clear idea of what all this code should like, anyway,
myself. I and others had bisected the breaking of irqpoll/fixup to
commit fa27271bc8d. I was testing the parts of that small patch, like
puzzle pieces. That was one the one that worked for me and everyone
else, until now. I thought we might have a discussion about it, but
that didn't happen. The first time I submitted it, I hadn't heard
back. Then another user bugged Linus about the regression. I piped
up that I had submitted a patch. Users tested it successfully, and it
went in.
So, let me try to confirm some things now, so I can learn as I go. To
spell out what's in the new patch:
The later line,
action = desc->action;
should have been this all along?
action = action->next;
And with that fixed, the other test can go. Which is good, now,
because it was creating locking problems for you.
Ok, thanks for bearing with me. I'll repeat the test here, some
more, but they've generally behaved consistently and probably will
keep showing the same.
I might as well add that I would happily ship one of these computers,
with a reliably spurious interrupt, to Thomas in Germany. if that
would help for testing.
Thanks all -
Ed
On Mon, Nov 26, 2012 at 3:09 AM, Wang, Warner wrote:
> Hi Thomas and Edward,
>
> This patch works fine for our problems, but I'm not sure if it works for the
> recent submit "genirq: fix regression in irqfixup, irqpoll"
> "52553ddffad76ccf192d4dd9ce88d5818f57f62a", which submitted by Edward Donovan.
>
> Edward can you help verify it on your environment?
>
>
> Thanks,
> -Warner
>
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: 2012年11月23日 PM 5:09
> To: Wang, Warner
> Cc: Wang, Song-Bo (Stoney)
> Subject: Re: need help on a DEADLOCK problem related to function try_one_irq()
>
> On Thu, 22 Nov 2012, Thomas Gleixner wrote:
>
>> Warner,
>>
>> On Thu, 22 Nov 2012, Wang, Warner wrote:
>>
>> please send such bug reports to the kernel mailinglist in the future.
>>
>> > We met a problem on some of our x86 server and after a few weeks
>> > trace-down effort, we believe the problem is in the file
>> > "linux/kernel/irq/spurious.c". We created a patch but we are not
>> > 100% sure if it is correct or complete. That is why we want to
>> > consult you.
>>
>> You spotted the problem right, but I'm not sure at the first glance,
>> whether this is correct. I need to go back into history and figure out
>> why we added that call in the first place. It looks fundamentally
>> wrong.
>>
>> Thanks for analyzing it. I'll keep you posted on my findings.
>
> Can you try the patch below ?
>
> Thanks,
>
> tglx
>
> ---
> kernel/irq/spurious.c |8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> Index: tip/kernel/irq/spurious.c
> ===
> --- tip.orig/kernel/irq/spurious.c
> +++ tip/kernel/irq/spurious.c
> @@ -80,13 +80,11 @@ static int try_one_irq(int irq, struct i
>
> /*
> * All handlers must agree on IRQF_SHARED, so we test just the
> -* first. Check for action->next as well.
> +* first.
> */
> action = desc->action;
> if (!action || !(action->flags & IRQF_SHARED) ||
> - (action->flags & __IRQF_TIMER) ||
> - (action->handler(irq, action->dev_id) == IRQ_HANDLED) ||
> - !action->next)
> + (action->flags & __IRQF_TIMER))
> goto out;
>
> /* Already running on another processor */ @@ -104,7 +102,7 @@ static
> int try_one_irq(int irq, struct i
> do {
> if (handle_irq_event(desc) == IRQ_HANDLED)
> ret = IRQ_HANDLED;
> - action = desc->action;
> + action = action->next;
> } while ((desc->istate & IRQS_PENDING) && action);
> desc->istate &= ~IRQS_POLL_INPROGRESS;
> out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL] More module signing fixes.
Linus Torvalds writes: > On Tue, Dec 4, 2012 at 5:45 PM, Rusty Russell wrote: >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git > > Nothing there. Forgot to push? Forgot to send me the proper tag/branch name? How did I manage to get git request-pull to screw that up? Weird. This time seems to be the right branch: fixes. Thanks, Rusty. The following changes since commit df2fc246c8ee8b6067af1fa55d3bc23107457f61: Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux (2012-12-04 09:32:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git fixes for you to fetch changes up to f3537f91f9be2ce5fcbaa1aa6d787ad0436daec6: ASN.1: Fix an indefinite length skip error (2012-12-05 11:27:39 +1030) David Howells (2): MODSIGN: Don't use enum-type bitfields in module signature info block ASN.1: Fix an indefinite length skip error kernel/module_signing.c | 14 +++--- lib/asn1_decoder.c |2 +- 2 files changed, 8 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: weakness of runnable load tracking?
On Thu, 2012-12-06 at 11:13 +0800, Alex Shi wrote: > On 12/05/2012 11:19 PM, Alex Shi wrote: > > Hi Paul: > > > > Runnable load tracking patch set introduce a good way to tracking each > > entity/rq's running time. > > But when I try to enable it in load balance, I found burst forking > > many new tasks will make just few cpu heavy while other cpu has no > > much task assigned. That is due to the new forked task's > > load_avg_contrib is zero after just created. then no matter how many > > tasks assigned to a CPU can not increase the cfs_rq->runnable_load_avg > > or rq->avg.load_avg_contrib if this cpu idle. > > Actually, if just for new task issue, we can set new task's initial > > load_avg same as load_weight. but if we want to burst wake up many > > long time sleeping tasks, it has the same issue here since their were > > decayed to zero. So what solution I can thought is recording the se's > > load_avg_contrib just before dequeue, and don't decay the value, when > > it was waken up, add this value to new cfs_rq. but if so, the runnable > > load tracking is total meaningless. > > So do you have some idea of burst wakeup balancing with runnable load > > tracking? > > Hi Paul & Ingo: > > In a short word of this issue: burst forking/waking tasks have no time > accumulate the load contribute, their runnable load are taken as zero. > that make select_task_rq do a wrong decision on which group is idlest. As you pointed out above, new tasks can (and imho should) be born with full weight. Tasks _may_ become thin, but they're all born hungry. > There is still 3 kinds of solution is helpful for this issue. > > a, set a unzero minimum value for the long time sleeping task. but it > seems unfair for other tasks these just sleep a short while. > > b, just use runnable load contrib in load balance. Still using > nr_running to judge idlest group in select_task_rq_fair. but that may > cause a bit more migrations in future load balance. > > c, consider both runnable load and nr_running in the group: like in the > searching domain, the nr_running number increased a certain number, like > double of the domain span, in a certain time. we will think it's a burst > forking/waking happened, then just count the nr_running as the idlest > group criteria. > > IMHO, I like the 3rd one a bit more. as to the certain time to judge if > a burst happened, since we will calculate the runnable avg at very tick, > so if increased nr_running is beyond sd->span_weight in 2 ticks, means > burst happening. What's your opinion of this? > > Any comments are appreciated! IMHO, for fork and bursty wake balancing, the only thing meaningful is the here and now state of runqueues tasks are being dumped into. Just because tasks are historically short running, you don't necessarily want to take a gaggle and wedge them into a too small group just to even out load averages. If there was a hole available that you passed up by using average load, you lose utilization. I can see how this load tracking stuff can average out to a win on a ~heavily loaded box, but bursty stuff I don't see how it can do anything but harm, so imho, the user should choose which is best for his box, instantaneous or history. WRT burst detection: any window you define can be longer than the burst. $.02 -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 v1 resend] regulator: new driver for LP8755
>From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] >Sent: Thursday, December 06, 2012 2:34 PM >To: Daniel Jeong >Cc: Girdwood, Liam; Jeong, Daniel; linux-kernel@vger.kernel.org >Subject: Re: [PATCH v1 resend] regulator: new driver for LP8755 >On Thu, Dec 06, 2012 at 02:07:43PM +0900, Daniel Jeong wrote: >> This driver is a general version for lp8755 regulator driver of TI. >> >> LP8755 : >> The LP8755 is a high performance power management unit.It contains six >> step-down DC-DC converters which can can be filexibly bundled together >> in multiphase converters as required by application. >> www.ti.com >You've resent this after about 24 hours, please allow sane times for a >response. Sorry. I mis-typed the email address so we couldn't find it at lkml. So I sent it again but it's same patch file(source doesn't changed). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote: > Looks good to me. Probably 3.9 material though. > Acked-by: Grant Likely Hrm, I'd be inclined to apply it now - it's isolated enough that it can be reverted if it explodes and we have the -rc cycle to notice any problems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: tps80031: Add terminating entry for tps80031_id_table
On Wednesday 05 December 2012 06:29 PM, Axel Lin wrote: The i2c_device_id table is supposed to be zero-terminated. Signed-off-by: Axel Lin Acked-by: Laxman Dewangan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: tps80031: MFD_TPS80031 needs to select REGMAP_IRQ
On Wednesday 05 December 2012 06:49 PM, Axel Lin wrote: This driver uses regmap_irq APIs, thus need to select REGMAP_IRQ. IRQ_DOMAIN will be selected if select REGMAP_IRQ, thus remove it here. This fixes below build errors: drivers/built-in.o: In function `tps80031_remove': drivers/mfd/tps80031.c:534: undefined reference to `regmap_del_irq_chip' drivers/built-in.o: In function `tps80031_irq_init': drivers/mfd/tps80031.c:305: undefined reference to `regmap_add_irq_chip' drivers/built-in.o: In function `tps80031_probe': drivers/mfd/tps80031.c:496: undefined reference to `regmap_irq_get_domain' drivers/mfd/tps80031.c:512: undefined reference to `regmap_del_irq_chip' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin Acked-by: Laxman Dewangan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 resend] regulator: new driver for LP8755
On Thu, Dec 06, 2012 at 02:07:43PM +0900, Daniel Jeong wrote: > This driver is a general version for lp8755 regulator driver of TI. > > LP8755 : > The LP8755 is a high performance power management unit.It contains > six step-down DC-DC converters which can can be filexibly bundled > together in multiphase converters as required by application. > www.ti.com You've resent this after about 24 hours, please allow sane times for a response. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: line6: delete an unused function
On Wed, Dec 5, 2012 at 7:43 PM, Dan Carpenter wrote: > line6_send_sysex_message_async() isn't called from anywhere. > > Signed-off-by: Dan Carpenter Reviewed-by: Stefan Hajnoczi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 resend] regulator: new driver for LP8755
This driver is a general version for lp8755 regulator driver of TI.
LP8755 :
The LP8755 is a high performance power management unit.It contains
six step-down DC-DC converters which can can be filexibly bundled
together in multiphase converters as required by application.
www.ti.com
Signed-off-by: Daniel Jeong
---
drivers/regulator/Kconfig|9 +
drivers/regulator/Makefile |1 +
drivers/regulator/lp8755.c | 586 ++
include/linux/platform_data/lp8755.h | 71
4 files changed, 667 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/lp8755.c
create mode 100644 include/linux/platform_data/lp8755.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 67d47b59..63e37ff 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -257,6 +257,15 @@ config REGULATOR_LP872X
help
This driver supports LP8720/LP8725 PMIC
+config REGULATOR_LP8755
+ tristate "TI LP8755 Hihg Performance PMU driver"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ This driver supports LP8755 High Performance PMU driver. This
+ chip contains six step-down DC/DC converters which can support
+ 9 mode multiphase configuration.
+
config REGULATOR_LP8788
bool "TI LP8788 Power Regulators"
depends on MFD_LP8788
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e431eed..bf346b7 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
+obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
obj-$(CONFIG_REGULATOR_MAX8649)+= max8649.o
obj-$(CONFIG_REGULATOR_MAX8660) += max8660.o
diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
new file mode 100644
index 000..0dfb2a8
--- /dev/null
+++ b/drivers/regulator/lp8755.c
@@ -0,0 +1,586 @@
+/*
+ * LP8755 High Performance Power Management Unit : System Interface Driver
+ * (based on rev. 0.26)
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Daniel(Geon Si) Jeong
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LP8755_REG_BUCK0 0x00
+#define LP8755_REG_BUCK1 0x03
+#define LP8755_REG_BUCK2 0x04
+#define LP8755_REG_BUCK3 0x01
+#define LP8755_REG_BUCK4 0x05
+#define LP8755_REG_BUCK5 0x02
+#define LP8755_REG_MAX 0xFF
+
+#define LP8755_BUCK_EN_M BIT(7)
+#define LP8755_BUCK_LINEAR_OUT_MAX 0x76
+#define LP8755_BUCK_VOUT_M 0x7F
+
+enum bucks {
+ BUCK0 = 0,
+ BUCK1,
+ BUCK2,
+ BUCK3,
+ BUCK4,
+ BUCK5,
+};
+
+struct lp8755_mphase {
+ int nreg;
+ int buck_num[LP8755_BUCK_MAX];
+};
+
+struct lp8755_chip {
+ struct device *dev;
+ struct regmap *regmap;
+ struct lp8755_platform_data *pdata;
+
+ int irq;
+ unsigned int irqmask;
+
+ int num_reg;
+ int mphase;
+ struct regulator_dev *rdev[LP8755_BUCK_MAX];
+};
+
+/**
+ *lp8755_read : read a single register value from lp8755.
+ */
+static int lp8755_read(struct lp8755_chip *pchip, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_read(pchip->regmap, reg, val);
+}
+
+/**
+ *lp8755_write : write a single register value to lp8755.
+ */
+static int lp8755_write(struct lp8755_chip *pchip, unsigned int reg,
+ unsigned int val)
+{
+ return regmap_write(pchip->regmap, reg, val);
+}
+
+/**
+ *lp8755_update_bits : set the values of bit fields in lp8755 register.
+ */
+static int lp8755_update_bits(struct lp8755_chip *pchip, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ return regmap_update_bits(pchip->regmap, reg, mask, val);
+}
+
+static int lp8755_buck_enable_time(struct regulator_dev *rdev)
+{
+ int ret;
+ unsigned int regval;
+ enum lp8755_bucks id = rdev_get_id(rdev);
+ struct lp8755_chip *pchip = rdev_get_drvdata(rdev);
+
+ ret = lp8755_read(pchip, 0x12 + id, );
+ if (ret < 0) {
+ dev_err(pchip->dev, "i2c acceess error %s\n", __func__);
+ return ret;
+ }
+ return (regval & 0xff) * 100;
+}
+
+static int lp8755_buck_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+ int ret;
+ unsigned int regbval = 0x0;
+ enum lp8755_bucks id = rdev_get_id(rdev);
+ struct lp8755_chip *pchip =
Re: [PATCH RFC v2] media: v4l2-ctrl: Add gain controls
Hi Hans, On Wed, Dec 5, 2012 at 5:38 PM, Hans Verkuil wrote: > (resend without HTML formatting) > > On Wed 5 December 2012 12:49:29 Prabhakar Lad wrote: >> From: Lad, Prabhakar >> >> add support for per color component digital/analog gain controls >> and also their corresponding offset. > > Some obvious questions below... > >> >> Signed-off-by: Lad, Prabhakar >> Cc: Sakari Ailus >> Cc: Laurent Pinchart >> Cc: Kyungmin Park >> Cc: Guennadi Liakhovetski >> Cc: Sylwester Nawrocki >> Cc: Hans Verkuil >> Cc: Hans de Goede >> Cc: Chris MacGregor >> Cc: Rob Landley >> Cc: Jeongtae Park >> Cc: Mauro Carvalho Chehab >> --- >> Changes for v2: >> 1: Fixed review comments pointed by Laurent. >> 2: Rebased on latest tree. >> >> Documentation/DocBook/media/v4l/controls.xml | 54 >> ++ >> drivers/media/v4l2-core/v4l2-ctrls.c | 11 + >> include/uapi/linux/v4l2-controls.h | 11 + >> 3 files changed, 76 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml >> index 7fe5be1..847a9bb 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -4543,6 +4543,60 @@ interface and may change in the future. >> specific test patterns can be used to test if a device is working >> properly. >> >> + >> + V4L2_CID_GAIN_RED >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GAIN_GREEN_RED >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GAIN_GREEN_BLUE >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GAIN_BLUE >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GAIN_GREEN >> + integer >> + >> + >> + Some capture/sensor devices have >> + the capability to set per color component digital/analog gain >> values. >> + >> + >> + > spanname="id">V4L2_CID_GAIN_OFFSET >> + integer >> + >> + >> + > spanname="id">V4L2_CID_BLUE_OFFSET >> + integer >> + >> + >> + > spanname="id">V4L2_CID_RED_OFFSET >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GREEN_OFFSET >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GREEN_RED_OFFSET >> + integer >> + >> + >> + > spanname="id">V4L2_CID_GREEN_BLUE_OFFSET >> + integer >> + >> + >> + Some capture/sensor devices have the >> + capability to set per color component digital/analog gain offset >> values. >> + V4L2_CID_GAIN_OFFSET is the global gain offset and the rest are per >> + color component gain offsets. > > If I set both V4L2_CID_GAIN_RED and V4L2_CID_RED_OFFSET, how are they supposed > to interact? Or are they mutually exclusive? > > And if I set both V4L2_CID_GAIN_OFFSET and V4L2_CID_RED_OFFSET, how are they > supposed > to interact? > > This questions should be answered in the documentation... > I haven’t worked on the hardware which supports both, What is the general behaviour when the hardware supports both per color component and global and both of them are set ? That could be helpful for me to document. Regards, --Prabhakar Lad > Regards, > > Hans > >> + >> >> >> >> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c >> b/drivers/media/v4l2-core/v4l2-ctrls.c >> index f6ee201..05e3708 100644 >> --- a/drivers/media/v4l2-core/v4l2-ctrls.c >> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c >> @@ -790,6 +790,17 @@ const char *v4l2_ctrl_get_name(u32 id) >> case V4L2_CID_LINK_FREQ:return "Link Frequency"; >> case V4L2_CID_PIXEL_RATE: return "Pixel Rate"; >> case V4L2_CID_TEST_PATTERN: return "Test Pattern"; >> + case V4L2_CID_GAIN_RED: return "Gain Red"; >> + case V4L2_CID_GAIN_GREEN_RED: return "Gain Green Red"; >> + case V4L2_CID_GAIN_GREEN_BLUE: return "Gain Green Blue"; >> + case V4L2_CID_GAIN_BLUE:return "Gain Blue"; >> + case V4L2_CID_GAIN_GREEN: return "Gain Green"; >> + case V4L2_CID_GAIN_OFFSET: return "Gain Offset"; >> + case V4L2_CID_BLUE_OFFSET: return "Gain Blue Offset"; >> + case V4L2_CID_RED_OFFSET: return "Gain Red Offset"; >> + case V4L2_CID_GREEN_OFFSET: return "Gain Green Offset"; >> + case V4L2_CID_GREEN_RED_OFFSET: return "Gain Green Red Offset"; >> + case V4L2_CID_GREEN_BLUE_OFFSET:return "Gain Green Blue >> Offset"; >> >> /* DV controls */ >> case V4L2_CID_DV_CLASS: return "Digital Video >> Controls"; >> diff --git
[PATCH] regmap: Cache register and value sizes for debugfs
No point in calculating them every time.
Signed-off-by: Mark Brown
---
drivers/base/regmap/internal.h |4
drivers/base/regmap/regmap-debugfs.c | 24 ++--
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 288e135..7cf8c64 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -48,6 +48,10 @@ struct regmap {
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
const char *debugfs_name;
+
+ unsigned int debugfs_reg_len;
+ unsigned int debugfs_val_len;
+ unsigned int debugfs_tot_len;
#endif
unsigned int max_register;
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index f4b9dd0..00fbd58 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -60,7 +60,6 @@ static ssize_t regmap_read_debugfs(struct regmap *map,
unsigned int from,
unsigned int to, char __user *user_buf,
size_t count, loff_t *ppos)
{
- int reg_len, val_len, tot_len;
size_t buf_pos = 0;
loff_t p = 0;
ssize_t ret;
@@ -76,9 +75,13 @@ static ssize_t regmap_read_debugfs(struct regmap *map,
unsigned int from,
return -ENOMEM;
/* Calculate the length of a fixed format */
- reg_len = regmap_calc_reg_len(map->max_register, buf, count);
- val_len = 2 * map->format.val_bytes;
- tot_len = reg_len + val_len + 3; /* : \n */
+ if (!map->debugfs_tot_len) {
+ map->debugfs_reg_len = regmap_calc_reg_len(map->max_register,
+ buf, count);
+ map->debugfs_val_len = 2 * map->format.val_bytes;
+ map->debugfs_tot_len = map->debugfs_reg_len +
+ map->debugfs_val_len + 3; /* : \n */
+ }
for (i = from; i <= to; i += map->reg_stride) {
if (!regmap_readable(map, i))
@@ -90,26 +93,27 @@ static ssize_t regmap_read_debugfs(struct regmap *map,
unsigned int from,
/* If we're in the region the user is trying to read */
if (p >= *ppos) {
/* ...but not beyond it */
- if (buf_pos >= count - 1 - tot_len)
+ if (buf_pos >= count - 1 - map->debugfs_tot_len)
break;
/* Format the register */
snprintf(buf + buf_pos, count - buf_pos, "%.*x: ",
-reg_len, i - from);
- buf_pos += reg_len + 2;
+map->debugfs_reg_len, i - from);
+ buf_pos += map->debugfs_reg_len + 2;
/* Format the value, write all X if we can't read */
ret = regmap_read(map, i, );
if (ret == 0)
snprintf(buf + buf_pos, count - buf_pos,
-"%.*x", val_len, val);
+"%.*x", map->debugfs_val_len, val);
else
- memset(buf + buf_pos, 'X', val_len);
+ memset(buf + buf_pos, 'X',
+ map->debugfs_val_len);
buf_pos += 2 * map->format.val_bytes;
buf[buf_pos++] = '\n';
}
- p += tot_len;
+ p += map->debugfs_tot_len;
}
ret = buf_pos;
--
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: [RFC PATCH v2 02/10] CPU hotplug: Provide APIs for "full" atomic readers to prevent CPU offline
On 12/06/2012 02:27 AM, Tejun Heo wrote: > Hello, > > On Thu, Dec 06, 2012 at 02:01:35AM +0530, Srivatsa S. Bhat wrote: >> Yes, that _sounds_ sufficient, but IMHO it won't be, in practice. The >> *number* of call-sites that you need to convert from preempt_disable/enable >> to get/put_online_cpus_atomic() won't be too many, however the *frequency* >> of usage of those call-sites can potentially be very high. > > I don't think that will be the case and, even if it is, doing it this > way would make it difficult to tell. The right thing to do is > replacing stop_machine with finer grained percpu locking first. > Refining it further should happen iff that isn't enough and there > isn't an simpler solution. So, let's please do the simple conversion > first. > Hmm, OK, that sounds like a good plan. So I'll drop the "light" and "full" variants for now and work on providing a straight-forward get/put_online_cpus_atomic() APIs. Thank you! Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V1 1/2] Xen acpi memory hotplug driver
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 126d8ce..abd0396 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -206,4 +206,15 @@ config XEN_MCE_LOG Allow kernel fetching MCE error from Xen platform and converting it into Linux mcelog format for mcelog tools +config XEN_ACPI_MEMORY_HOTPLUG + bool "Xen ACPI memory hotplug" >>> >>> There should be a way to make this a module. >> >> I have some concerns to make it a module: >> 1. xen and native memhotplug driver both work as module, while we >> need early load xen driver. >> 2. if possible, a xen stub driver may solve load sequence issue, but >> it may involve other issues * if xen driver load then unload, >> native driver may have chance to load successfully; > > The stub driver would still "occupy" the ACPI bus for the memory > hotplug PnP, so I think this would not be a problem. > I'm not quite clear your mean here, do you mean it has 1. xen_stub driver + xen_memhoplug driver, then xen_strub driver unload and entirely replaced by xen_memhotplug driver, or 2. xen_stub driver (w/ stub ops) + xen_memhotplug ops (not driver), then xen_stub driver keep occupying but its stub ops later replaced by xen_memhotplug ops? If in way #1, it has risk that native driver may load (if xen driver unload). If in way #2, xen_memhotplug ops lose the chance to probe/add/bind existed memory devices (since it's done when driver registerred). >> * if xen driver load --> unload --> load again, then it will lose >> hotplug notification during unload period; > > Sure. But I think we can do it with this driver? After all the > function of > it is to just tell the firmware to turn on/off sockets - and if we > miss > one notification we won't take advantage of the power savings - but we > can do that later on. > Not only inform firmware. Hotplug notify callback will invoke acpi_bus_add -> ... -> implicitly invoke drv->ops.add method to add the hotadded memory device. > >> * if xen driver load --> unload --> load again, then it will >> re-add all memory devices, but the handle for 'booting memory >> device' and 'hotplug memory device' are different while we have no >> way to distinguish these 2 kind of devices. > > Wouldn't the stub driver hold onto that? > Same question as comment #1. Do you mean it has a xen_stub driver (w/ stub ops) and a xen_memhotplug ops? >> >> IMHO I think to make xen hotplug logic as module may involves >> unexpected result. Is there any obvious advantages of doing so? >> after all we have provided config choice to user. Thoughts? > > Yes, it becomes a module - which is what we want. > What I meant here is, module will bring some unexpected issues for xen hotplug. We can provide user 'bool' config choice, let them decide to build-in or not, but not 'tristate' choice. Thanks Jinsong-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] device_cgroup: keep track of local group settings
Quoting Aristeu Rozanski (a...@redhat.com): > On Mon, Dec 03, 2012 at 06:01:25PM +, Serge E. Hallyn wrote: > > First, generally, I don't think 'allows' added to parent should be > > automatically propagated to descendents. > > that's what I think too and what I tried to do > > > In devcgroup_update_access: (around line 625) > > there is a period of time where cgroup members have > > default allow without the parent's exceptions. > > true, will fix that one and look for more cases > > > propagate_behavior (line 505): > > 1. doesn't follow the same ordering as devcgroup_update_access(), in > > particular cleaning exceptions before setting behavior. > > I see, will update that > > > 2. When changing a parent from deny to allow, I don't think children > > should be updated. > > I disagree on this one. since there'll be local preferences, it'll try > to revalidate them everytime there's a change. so, for example, an > exception that might not be possible now, will be possible when its > parent changes in a way that allows that. My concern is just practical - if I've started a bunch of containers, and another admin decides to make a change to the root devices cgroup, I don't want the container's device accesses now changing. Maybe that's better solved by having all of userspace sit in /system while containers and vms sit under /lxc and /libvirt... -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/6] kvm: Re-introduce memslots->nmemslots
On Wed, 2012-12-05 at 23:45 -0200, Marcelo Tosatti wrote:
> On Wed, Dec 05, 2012 at 04:02:53PM -0700, Alex Williamson wrote:
> > On Wed, 2012-12-05 at 19:26 -0200, Marcelo Tosatti wrote:
> > > On Mon, Dec 03, 2012 at 04:39:36PM -0700, Alex Williamson wrote:
> > > > struct kvm_memory_slot is currently 52 bytes (LP64), not counting the
> > > > arch data. On x86 this means the memslot array to support a tiny 32+3
> > > > entries (user+private) is over 2k. We'd like to support more slots
> > > > so that we can support more assigned devices, but it doesn't make
> > > > sense to penalize everyone by using a statically allocated array.
> > > > This allows us to start introducing a grow-able array.
> > > >
> > > > Signed-off-by: Alex Williamson
> > > > ---
> > > > arch/ia64/kvm/kvm-ia64.c |2 +-
> > > > arch/powerpc/kvm/book3s_hv.c |2 +-
> > > > arch/x86/kvm/vmx.c |1 +
> > > > arch/x86/kvm/x86.c |4 +++-
> > > > include/linux/kvm_host.h |9 ++---
> > > > virt/kvm/kvm_main.c | 10 ++
> > > > 6 files changed, 18 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
> > > > index 012e5dd..96401b5 100644
> > > > --- a/arch/ia64/kvm/kvm-ia64.c
> > > > +++ b/arch/ia64/kvm/kvm-ia64.c
> > > > @@ -1836,7 +1836,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> > > >
> > > > memslot = id_to_memslot(kvm->memslots, log->slot);
> > > > r = -ENOENT;
> > > > - if (!memslot->dirty_bitmap)
> > > > + if (!memslots || !memslot->dirty_bitmap)
> > > > goto out;
> > > >
> > > > kvm_ia64_sync_dirty_log(kvm, memslot);
> > > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > > > index 56067db..0417190 100644
> > > > --- a/arch/powerpc/kvm/book3s_hv.c
> > > > +++ b/arch/powerpc/kvm/book3s_hv.c
> > > > @@ -1267,7 +1267,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> > > > struct kvm_dirty_log *log)
> > > >
> > > > memslot = id_to_memslot(kvm->memslots, log->slot);
> > > > r = -ENOENT;
> > > > - if (!memslot->dirty_bitmap)
> > > > + if (!memslot || !memslot->dirty_bitmap)
> > > > goto out;
> > > >
> > > > n = kvm_dirty_bitmap_bytes(memslot);
> > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > > index 2bb9157..07fdd90 100644
> > > > --- a/arch/x86/kvm/vmx.c
> > > > +++ b/arch/x86/kvm/vmx.c
> > > > @@ -2751,6 +2751,7 @@ static gva_t rmode_tss_base(struct kvm *kvm)
> > > >
> > > > slots = kvm_memslots(kvm);
> > > > slot = id_to_memslot(slots, KVM_PRIVATE_MEM_SLOTS);
> > > > + BUG_ON(!slot);
> > > > base_gfn = slot->base_gfn + slot->npages - 3;
> > > >
> > > > return base_gfn << PAGE_SHIFT;
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 8765485..53fe9b2 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -3139,9 +3139,11 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> > > > struct kvm_dirty_log *log)
> > > > goto out;
> > > >
> > > > memslot = id_to_memslot(kvm->memslots, log->slot);
> > > > + r = -ENOENT;
> > > > + if (!memslot)
> > > > + goto out;
> > > >
> > > > dirty_bitmap = memslot->dirty_bitmap;
> > > > - r = -ENOENT;
> > > > if (!dirty_bitmap)
> > > > goto out;
> > > >
> > > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > > > index 7b3d5c4..1955a4e 100644
> > > > --- a/include/linux/kvm_host.h
> > > > +++ b/include/linux/kvm_host.h
> > > > @@ -313,6 +313,7 @@ struct kvm_irq_routing_table {};
> > > > * to get the memslot by its id.
> > > > */
> > > > struct kvm_memslots {
> > > > + int nmemslots;
> > > > u64 generation;
> > > > struct kvm_memory_slot memslots[KVM_MEM_SLOTS_NUM];
> > > > };
> > > > @@ -397,7 +398,7 @@ static inline struct kvm_vcpu *kvm_get_vcpu(struct
> > > > kvm *kvm, int i)
> > > >
> > > > #define kvm_for_each_memslot(memslot, slots) \
> > > > for (memslot = >memslots[0]; \
> > > > - memslot < slots->memslots + KVM_MEM_SLOTS_NUM &&
> > > > memslot->npages;\
> > > > + memslot < slots->memslots + slots->nmemslots &&
> > > > memslot->npages;\
> > > > memslot++)
> > > >
> > > > int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id);
> > > > @@ -424,10 +425,12 @@ static inline struct kvm_memslots
> > > > *kvm_memslots(struct kvm *kvm)
> > > > static inline struct kvm_memory_slot *
> > > > id_to_memslot(struct kvm_memslots *slots, int id)
> > > > {
> > > > - int index = slots->memslots[id].id_to_index;
> > > > struct kvm_memory_slot *slot;
> > > >
> > > > - slot = >memslots[index];
> > > > + if (id >= slots->nmemslots)
> > > > +
Re: [PATCH] gpio: add TS-5500 DIO headers support
Hi Linus,
I rewrote some parts according to your comments, but I still have some
concerns.
On Fri, 2012-10-12 at 22:53 +0200, Linus Walleij wrote:
> >> (...)
> >> > +static int ts5500_gpio_to_irq(struct gpio_chip *chip, unsigned
> offset)
> >> > +{
> >> > + const struct ts5500_dio line = ts5500_dios[offset];
> >> > +
> >> > + /* Only a few lines are IRQ-capable */
> >> > + if (line.irq != NO_IRQ)
> >> > + return line.irq;
> >> > +
> >> > + /* This allows to bridge a line with the IRQ line of the
> same header */
> >> > + if (dio1_irq && offset < 13)
> >> > + return ts5500_dios[13].irq;
> >> > + if (dio2_irq && offset > 13 && offset < 26)
> >> > + return ts5500_dios[26].irq;
> >> > + if (lcd_irq && offset > 26 && offset < 37)
> >> > + return ts5500_dios[37].irq;
> >>
> >> Don't do this. Please use irqdomain for converting physical
> >> IRQ numbers to Linux IRQ numbers. (Consult other GPIO
> >> drivers for examples.)
> >>
> >> These magic constants (13, 26, 37) are scary too.
> >>
> >> You should not try to handle each block as a single
> >> IRQ, instead instatiate a struct irq_chip in the driver
> >> and let that use irqdomain do demux the IRQ and
> >> register a range of Linux IRQ numbers, on per pin,
> >> so the GPIO driver will handle the physical IRQ line,
> >> then dispatch to a fan-out handler, so drivers that need
> >> IRQs from the GPIO chip just register IRQ handlers like
> >> anyone else.
> >
> > Do you mean that I should not return the same IRQ line for the same
> > header, but virtual ones? I'll try to find a good example for that.
>
> Basically Linux IRQs (also sometimes called virtual IRQs) are
> separate from the physical IRQ numbers of the system.
>
> i.e. what you see in /proc/interrupts has no relation to the physical
> interrupt lines.
>
> Keep in mind that we're trying to disallow IRQ 0 altogether and some
> platforms use that physical line for stuff.
>
> So we need to use irqdomain to just grab an IRQ number to reference
> the physical line. And we often do that for the IRQ controller.
>
> The fact that sometimes the physical line number and the Linux
> IRQ number correspond is just misleading...
>
> In this case, since you have individual IRQs you want to check
> for different lines, register something with e.g.
> irq_domain_add_simple() to handle all these lines as IRQs.
>
> It's a bit complex but pays off: all of a sudden you get statistics
> in /proc/interrupts for exactly which GPIO IRQs were fired,
> for example, and they get names if you provide that.
>
> Look at the other GPIO drivers for many good examples of
> how to do this. gpio-em.c is one example.
I looked at some drivers and if I'm not mistaken, this case is
different. Technologic Systems platforms (such as the TS-5500) have
several pin blocks. Each block has input-only, input-output or
output-only pins. Only one pin per block is connected to an interrupt
line. But sadly, these interrupt-connected lines are input only.
Here are the details about the TS-5500 pin block "DIO1":
http://wiki.embeddedarm.com/wiki/TS-5500#DIO1_Header
Some GPIO devices need a bidirectional data line which can trigger an
IRQ. In this case, we use a bidirectional pin for data, that we strap to
the IRQ-able pin.
Basically, our setup looks like that:
+---+ in-only+IRQ
| D |-+ data ++
| I | in/out pin |---| GPIO |
| O |-+ clk | device |
| 1 |-|(SHT15) |
+---+ in/out pin ++
That's why I previously used a dio1_irq platform data field, to return
the interrupt connected to the IRQ-able pin for any GPIO on DIO1, in the
gpio_to_irq() implementation.
A Linux IRQ per pin doesn't seem to be possible because the
irq_create_mapping() documentation says that "Only one mapping per
hardware interrupt is permitted." Should I still implement the
irq_chip/irqdomain for a single IRQ per block? For each pin?
What do you think about this implementation?
Yours,
Vivien
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON
From: Marko Katic Changing backlight intensity on an Akita (Sharp Zaurus C-1000) triggers WARN_ON message: WARNING: at drivers/gpio/gpiolib.c:1672 __gpio_set_value+0x38/0xa4() Modules linked in: Backtrace: [] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c) r6:c0158fc8 r5:0009 r4: r3:c03d4f70 [] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x54/0x6c) [] (warn_slowpath_common+0x0/0x6c) from [] (warn_slowpath_null+0x24/0x2c) r8:c38d5c00 r7:c03f82c0 r6: r5:00d0 r4:c384e4fc r3:0009 [] (warn_slowpath_null+0x0/0x2c) from [] (__gpio_set_value+0x38/0xa4) [] (__gpio_set_value+0x0/0xa4) from [] (corgi_bl_set_intensity+0x44/0x74) r7:c3933418 r6:c3933400 r5:c392cdf0 r4:002f [] (corgi_bl_set_intensity+0x0/0x74) from [] (corgi_bl_update_status+0x5c/0x64) r5:c03d31f0 r4:c3933400 [] (corgi_bl_update_status+0x0/0x64) from [] (corgi_lcd_probe+0x1a8/0x258) r4:c392cdf0 r3:c0169bc0 [] (corgi_lcd_probe+0x0/0x258) from [] (spi_drv_probe+0x20/0x24) r8:0052 r7:c0192d9c r6:c03da6e8 r5:c38d5c34 r4:c38d5c00 [] (spi_drv_probe+0x0/0x24) from [] (driver_probe_device+0xb0/0x208) [] (driver_probe_device+0x0/0x208) from [] (__driver_attach+0x70/0x94) r6:c03da6e8 r5:c38d5c34 r4:c38d5c00 r3: [] (__driver_attach+0x0/0x94) from [] (bus_for_each_dev+0x54/0x90) r6:c03da6e8 r5:c3827e80 r4: r3: [] (bus_for_each_dev+0x0/0x90) from [] (driver_attach+0x20/0x28) r7: r6:c03e29ec r5:c3932980 r4:c03da6e8 [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xd4/0x22c) [] (bus_add_driver+0x0/0x22c) from [] (driver_register+0xa4/0x134) r8:0052 r7:c03ea900 r6:c03c32ac r5:c03bdfc8 r4:c03da6e8 [] (driver_register+0x0/0x134) from [] (spi_register_driver+0x4c/0x60) [] (spi_register_driver+0x0/0x60) from [] (corgi_lcd_driver_init+0x14/0x1c) [] (corgi_lcd_driver_init+0x0/0x1c) from [] (do_one_initcall+0x9c/0x174) [] (do_one_initcall+0x0/0x174) from [] (kernel_init+0xf4/0x2a8) [] (kernel_init+0x0/0x2a8) from [] (ret_from_fork+0x14/0x24) ---[ end trace a863a63f242ee38c ]--- Akita machines have backlight controls hooked to a gpio expander chip, max7310 using i2c transfers which can sleep. In this case, pca953x_gpio_set_value() can be called to control gpio, and pca953x_setup_gpio() sets can_sleep flag. Therefore, gpio_set_value_cansleep() should be used in order to avoid WARN_ON on akita machines. Akita is the only exception in this case since other users of corgi_lcd access backlight gpio controls through a different gpio expander which does not set the can_sleep flag. Signed-off-by: Marko Katic Signed-off-by: Jingoo Han --- Change since v4: - use only gpio_set_value_cansleep() drivers/video/backlight/corgi_lcd.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c index e2e1b62..e323fcb 100644 --- a/drivers/video/backlight/corgi_lcd.c +++ b/drivers/video/backlight/corgi_lcd.c @@ -409,10 +409,10 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd, int intensity) cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted; if (gpio_is_valid(lcd->gpio_backlight_cont)) - gpio_set_value(lcd->gpio_backlight_cont, cont); + gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont); if (gpio_is_valid(lcd->gpio_backlight_on)) - gpio_set_value(lcd->gpio_backlight_on, intensity); + gpio_set_value_cansleep(lcd->gpio_backlight_on, intensity); if (lcd->kick_battery) lcd->kick_battery(); -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 resend hot_track 00/16] vfs: hot data tracking
HI, guys THe perf testing is done separately with fs_mark, fio, ffsb and compilebench in one kvm guest. Below is the performance testing report for hot tracking, and no obvious perf downgrade is found. Note: original kernel means its source code is not changed; kernel with enabled hot tracking means its source code is with hot tracking patchset. The test env is set up as below: root@debian-i386:/home/zwu# uname -a Linux debian-i386 3.7.0-rc8+ #266 SMP Tue Dec 4 12:17:55 CST 2012 x86_64 GNU/Linux root@debian-i386:/home/zwu# mkfs.xfs -f -l size=1310b,sunit=8 /home/zwu/bdev.img meta-data=/home/zwu/bdev.img isize=256agcount=4, agsize=128000 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=512000, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=1310, version=2 = sectsz=512 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 1.) original kernel root@debian-i386:/home/zwu# mount -o loop,logbsize=256k /home/zwu/bdev.img /mnt/scratch [ 1197.421616] XFS (loop0): Mounting Filesystem [ 1197.567399] XFS (loop0): Ending clean mount root@debian-i386:/home/zwu# mount /dev/sda1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) none on /selinux type selinuxfs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) /dev/loop0 on /mnt/scratch type xfs (rw,logbsize=256k) root@debian-i386:/home/zwu# free -m total used free sharedbuffers cached Mem: 112109 2 0 4 53 -/+ buffers/cache: 51 60 Swap: 713 29684 2.) kernel with enabled hot tracking root@debian-i386:/home/zwu# mount -o hot_track,loop,logbsize=256k /home/zwu/bdev.img /mnt/scratch [ 364.648470] XFS (loop0): Mounting Filesystem [ 364.910035] XFS (loop0): Ending clean mount [ 364.921063] VFS: Turning on hot data tracking root@debian-i386:/home/zwu# mount /dev/sda1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) none on /selinux type selinuxfs (rw,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) /dev/loop0 on /mnt/scratch type xfs (rw,hot_track,logbsize=256k) root@debian-i386:/home/zwu# free -m total used free sharedbuffers cached Mem: 112107 4 0 2 34 -/+ buffers/cache: 70 41 Swap: 713 2711 1. fs_mark test 1.) orginal kernel # ./fs_mark -D 100 -S0 -n 1000 -s 1 -L 30 -d /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/2 -d /mnt/scratch/3 -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d /mnt/scratch/7 # Version 3.3, 8 thread(s) starting at Wed Dec 5 03:20:58 2012 # Sync method: NO SYNC: Test does not issue sync() or fsync() calls. # Directories: Time based hash between directories across 100 subdirectories with 180 seconds per subdirectory. # File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name) # Files info: size 1 bytes, written with an IO size of 16384 bytes per write # App overhead is time in microseconds spent in the test not doing file writing related system calls. FSUse%Count SizeFiles/sec App Overhead 2 80001375.6 27175895 3160001375.6 27478079 4240001346.0 27819607 4320001316.9 25863385 541335.2 25460605 6480001312.3 25889196 7560001327.3 25000611 8640001304.4 28126698 9720001361.7 26652172 981370.1 27075875 10880001347.8 31093106 11960001387.1 26877324 12 1040001
Re: [PATCH 019/270] jbd: Fix assertion failure in commit code due to lacking transaction credits
On Wed, Dec 05, 2012 at 01:02:41PM +0100, Jan Kara wrote: > On Mon 26-11-12 14:55:09, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > Note that this fix causes another problem which is fixed by > 25389bb207987b5774182f763b9fb65ff08761c8 upstream. > Honza Thanks, I'm going to queue this one for next 3.5.y.z release. > > > > > -- > > > > From: Jan Kara > > > > commit 09e05d4805e6c524c1af74e524e5d0528bb3fef3 upstream. > > -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: weakness of runnable load tracking?
On 12/05/2012 11:19 PM, Alex Shi wrote: > Hi Paul: > > Runnable load tracking patch set introduce a good way to tracking each > entity/rq's running time. > But when I try to enable it in load balance, I found burst forking > many new tasks will make just few cpu heavy while other cpu has no > much task assigned. That is due to the new forked task's > load_avg_contrib is zero after just created. then no matter how many > tasks assigned to a CPU can not increase the cfs_rq->runnable_load_avg > or rq->avg.load_avg_contrib if this cpu idle. > Actually, if just for new task issue, we can set new task's initial > load_avg same as load_weight. but if we want to burst wake up many > long time sleeping tasks, it has the same issue here since their were > decayed to zero. So what solution I can thought is recording the se's > load_avg_contrib just before dequeue, and don't decay the value, when > it was waken up, add this value to new cfs_rq. but if so, the runnable > load tracking is total meaningless. > So do you have some idea of burst wakeup balancing with runnable load > tracking? Hi Paul & Ingo: In a short word of this issue: burst forking/waking tasks have no time accumulate the load contribute, their runnable load are taken as zero. that make select_task_rq do a wrong decision on which group is idlest. There is still 3 kinds of solution is helpful for this issue. a, set a unzero minimum value for the long time sleeping task. but it seems unfair for other tasks these just sleep a short while. b, just use runnable load contrib in load balance. Still using nr_running to judge idlest group in select_task_rq_fair. but that may cause a bit more migrations in future load balance. c, consider both runnable load and nr_running in the group: like in the searching domain, the nr_running number increased a certain number, like double of the domain span, in a certain time. we will think it's a burst forking/waking happened, then just count the nr_running as the idlest group criteria. IMHO, I like the 3rd one a bit more. as to the certain time to judge if a burst happened, since we will calculate the runnable avg at very tick, so if increased nr_running is beyond sd->span_weight in 2 ticks, means burst happening. What's your opinion of this? Any comments are appreciated! Regards! Alex > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: kexec and struct boot_params
On Wed, Dec 5, 2012 at 5:57 PM, H. Peter Anvin wrote:
> Hi Eric,
>
> Could you give a list of struct boot_params field which are initialized
> properly by kexec? I think we need to do the sentinel hack, and want to
> know what to whitelist.
the one with *
? means set only when lfb_depth > 8
also
0xa2 to 0x1df is not set
struct x86_linux_param_header {
uint8_t orig_x;/* 0x00 */ *
uint8_t orig_y;/* 0x01 */ *
uint16_t ext_mem_k; /* 0x02 -- EXT_MEM_K sits here
*/ *
uint16_t orig_video_page; /* 0x04 */ *
uint8_t orig_video_mode; /* 0x06 */ *
uint8_t orig_video_cols; /* 0x07 */ *
uint16_t unused2; /* 0x08 */
uint16_t orig_video_ega_bx; /* 0x0a */ *
uint16_t unused3; /* 0x0c */
uint8_t orig_video_lines; /* 0x0e */ *
uint8_t orig_video_isVGA; /* 0x0f */ *
uint16_t orig_video_points; /* 0x10 */ *
/* VESA graphic mode -- linear frame buffer */
uint16_t lfb_width; /* 0x12 */ *
uint16_t lfb_height;/* 0x14 */ *
uint16_t lfb_depth; /* 0x16 */ *
uint32_t lfb_base; /* 0x18 */ *
uint32_t lfb_size; /* 0x1c */ *
uint16_t cl_magic; /* 0x20 */ *
#define CL_MAGIC_VALUE 0xA33F
uint16_t cl_offset; /* 0x22 */ *
uint16_t lfb_linelength;/* 0x24 */ *
uint8_t red_size; /* 0x26 */ ?
uint8_t red_pos; /* 0x27 */ ?
uint8_t green_size;/* 0x28 */ ?
uint8_t green_pos; /* 0x29 */ ?
uint8_t blue_size; /* 0x2a */ ?
uint8_t blue_pos; /* 0x2b */ ?
uint8_t rsvd_size; /* 0x2c */ ?
uint8_t rsvd_pos; /* 0x2d */ ?
uint16_t vesapm_seg;/* 0x2e */ *
uint16_t vesapm_off;/* 0x30 */
uint16_t pages; /* 0x32 */ *
uint8_t reserved4[12]; /* 0x34 -- 0x3f reserved for
future expansion */
struct apm_bios_info apm_bios_info; /* 0x40 */ *
struct drive_info_struct drive_info;/* 0x80 */ *
struct sys_desc_table sys_desc_table; /* 0xa0 */ * only .length =
0, aka 0xa2 to 0x1df is not set
uint32_t alt_mem_k; /* 0x1e0 */ *
uint8_t reserved5[4]; /* 0x1e4 */
uint8_t e820_map_nr; /* 0x1e8 */ *
uint8_t eddbuf_entries;/* 0x1e9 */ *
uint8_t edd_mbr_sig_buf_entries; /* 0x1ea */ *
uint8_t reserved6[6]; /* 0x1eb */
HEADER. copied and or meset
0 and set.
uint8_t reserved16[0x290 - 0x248]; /* 0x248 */
uint32_t edd_mbr_sig_buffer[EDD_MBR_SIG_MAX]; /* 0x290 */ *
#endif
struct e820entry e820_map[E820MAX];/* 0x2d0 */ *
uint8_t _pad8[48]; /* 0xcd0 */
struct edd_info eddbuf[EDDMAXNR]; /* 0xd00 */ *
/* 0xeec */
#define COMMAND_LINE_SIZE 2048
};
>
> Also, does kexec set a bootloader ID?
no, 0xff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI
On Wed, Dec 5, 2012 at 5:14 PM, Dave Chinner wrote: > > And for changes to syscalls? That's something that must be peer > reviewed because we are going to be stuck with those changes forever > as we can't undo them at a later date. It doesn't matter who made the > change in question, I would have done exactly the same thing The thing that people are complaining about is exactly the reverse of this. It's *protecting* us from making mistakes, and doesn't actually add any new interfaces in itself. This is why I'm so annoyed with this stupid thread. It's been going on forever, and reverting that change WOULD BE OBJECTIVELY A BAD IDEA. The change is a one-liner, doesn't add any code at all, seeks to protect us from potential future mistakes, and had a good technical rationale for it. Seriously. Why are we even discussing this two weeks later? Don't even bother to answer that question. This thread isn't worth it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] page_alloc: Make movablecore_map has higher priority
Hi Liu, Wu, I got it, thank you very much. The idea is very helpful. :) I'll apply your patches and do some tests later. Thanks. :) On 12/06/2012 10:51 AM, Jianguo Wu wrote: Hi Tang, There is a bug in Gerry's patch, please apply this patch to fix it. --- mm/page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 41c3b51..d981810 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4383,7 +4383,7 @@ static int __init find_zone_movable_from_movablecore_map(void) */ start_pfn = max(start_pfn, movablecore_map.map[map_pos].start); - zone_movable_pfn[nid] = roundup(zone_movable_pfn[nid], + zone_movable_pfn[nid] = roundup(start_pfn, MAX_ORDER_NR_PAGES); break; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
common clock framwork: clk_set_rate issue
hi When develop the clk drivers for SOCs based on common clock framework. I met a issue. For example there is a uart device, it's function clock comes from a divider, and the divider's parent is a mux. It means MUX --> DIV --> UART As we know that UART can work at low baudrate for a terminal, while it can also connect to GPS module which needs a high rate. So the MUX will provide two clock source, a low clock rate and high clock rate. The MUX clk driver clk-mux.c does not implement a ->round_rate callbacks. It means that when uart driver is used for a GPS and it want to change it clock, the driver will call clk_set_rate(); clk_set_rate will loop upward to DIV, and DIV will try to set its divider, and it need loop upward to MUX. In fact the current clk drivers have some issue. MUX clk driver should provide the round_rate callback, it then can provide a new_rate. It means that in clk_calc_subtree MUX can switch the clock source. So in the uart driver we can depends on the configuration passed by device tree to initiaze the clock for different purpose. This driver may be shared by many SOCs, so it does not care the clock framework. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] page_alloc: Make movablecore_map has higher priority
Hi Tang,
There is a bug in Gerry's patch, please apply this patch to fix it.
---
mm/page_alloc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 41c3b51..d981810 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4383,7 +4383,7 @@ static int __init
find_zone_movable_from_movablecore_map(void)
*/
start_pfn = max(start_pfn,
movablecore_map.map[map_pos].start);
- zone_movable_pfn[nid] = roundup(zone_movable_pfn[nid],
+ zone_movable_pfn[nid] = roundup(start_pfn,
MAX_ORDER_NR_PAGES);
break;
}
--
1.7.6.1
On 2012/12/6 10:26, Jiang Liu wrote:
> On 2012-12-6 9:26, Tang Chen wrote:
>> On 12/05/2012 11:43 PM, Jiang Liu wrote:
>>> If we make "movablecore_map" take precedence over "movablecore/kernelcore",
>>> the logic could be simplified. I think it's not so attractive to support
>>> both "movablecore_map" and "movablecore/kernelcore" at the same time.
>>
>> Hi Liu,
>>
>> Thanks for you advice. :)
>>
>> Memory hotplug needs different support on different hardware. We are
>> trying to figure out a way to satisfy as many users as we can.
>> Since it is a little difficult, it may take sometime. :)
>>
>> But I still think we need a boot option to support it. Just a metter of
>> how to make it easier to use. :)
>>
>> Thanks. :)
>>
>>>
>>> On 11/23/2012 06:44 PM, Tang Chen wrote:
If kernelcore or movablecore is specified at the same time
with movablecore_map, movablecore_map will have higher
priority to be satisfied.
This patch will make find_zone_movable_pfns_for_nodes()
calculate zone_movable_pfn[] with the limit from
zone_movable_limit[].
Signed-off-by: Tang Chen
Reviewed-by: Wen Congyang
Reviewed-by: Lai Jiangshan
Tested-by: Lin Feng
---
mm/page_alloc.c | 35 +++
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f23d76a..05bafbb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4800,12 +4800,25 @@ static void __init
find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
-/* If kernelcore was not specified, there is no ZONE_MOVABLE */
-if (!required_kernelcore)
+/*
+ * No matter kernelcore/movablecore was limited or not, movable_zone
+ * should always be set to a usable zone index.
+ */
+find_usable_zone_for_movable();
+
+/*
+ * If neither kernelcore/movablecore nor movablecore_map is specified,
+ * there is no ZONE_MOVABLE. But if movablecore_map is specified, the
+ * start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
+ */
+if (!required_kernelcore) {
+if (movablecore_map.nr_map)
+memcpy(zone_movable_pfn, zone_movable_limit,
+sizeof(zone_movable_pfn));
goto out;
+}
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at
*/
-find_usable_zone_for_movable();
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
restart:
@@ -4833,10 +4846,24 @@ restart:
for_each_mem_pfn_range(i, nid,_pfn,_pfn, NULL) {
unsigned long size_pages;
+/*
+ * Find more memory for kernelcore in
+ * [zone_movable_pfn[nid], zone_movable_limit[nid]).
+ */
start_pfn = max(start_pfn, zone_movable_pfn[nid]);
if (start_pfn>= end_pfn)
continue;
+if (zone_movable_limit[nid]) {
+end_pfn = min(end_pfn, zone_movable_limit[nid]);
+/* No range left for kernelcore in this node */
+if (start_pfn>= end_pfn) {
+zone_movable_pfn[nid] =
+zone_movable_limit[nid];
+break;
+}
+}
> Hi Tang,
> I just to remove the above logic, so the implementation will be greatly
> simplified. Please refer to the attachment.
> Regards!
> Gerry
>
+
/* Account for what is only usable for kernelcore */
if (start_pfn< usable_startpfn) {
unsigned long kernel_pages;
@@ -4896,12 +4923,12 @@ restart:
if (usable_nodes&& required_kernelcore> usable_nodes)
goto restart;
+out:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
Re: Linux 3.4.22
diff --git a/Makefile b/Makefile
index 7f9f649..320663d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 21
+SUBLEVEL = 22
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index d3e1152..c4410fb 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -192,6 +193,7 @@ unsigned long kernel_stack_pointer(struct pt_regs *regs)
return (unsigned long)regs;
}
+EXPORT_SYMBOL_GPL(kernel_stack_pointer);
static unsigned long *pt_regs_access(struct pt_regs *regs, unsigned long regno)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.4.22
I'm announcing the release of the 3.4.22 kernel. This release contains a single fix for a build error that some people have reported with the 3.4.21 kernel, if you don't have a problem with 3.4.21 then don't worry about upgrading at this point in time. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- arch/x86/kernel/ptrace.c |2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) Greg Kroah-Hartman (1): Linux 3.4.22 H. Peter Anvin (1): x86-32: Export kernel_stack_pointer() for modules signature.asc Description: Digital signature
Re: Linux 3.0.55
diff --git a/Makefile b/Makefile
index ae984ab..06df950 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 54
+SUBLEVEL = 55
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 8ede567..911e16d 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -191,6 +192,7 @@ unsigned long kernel_stack_pointer(struct pt_regs *regs)
return (unsigned long)regs;
}
+EXPORT_SYMBOL_GPL(kernel_stack_pointer);
static unsigned long *pt_regs_access(struct pt_regs *regs, unsigned long regno)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.0.55
I'm announcing the release of the 3.0.55 kernel. This only fixes a build error that some people have reported from the 3.0.54 kernel, if you don't have a problem with 3.0.54 then don't worry about upgrading at this point in time. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- arch/x86/kernel/ptrace.c |2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) Greg Kroah-Hartman (1): Linux 3.0.55 H. Peter Anvin (1): x86-32: Export kernel_stack_pointer() for modules signature.asc Description: Digital signature
Re: [PATCH v2] drivers/uio/uio_pdrv_genirq.c: Fix memory freeing issues
On Wed, Dec 05, 2012 at 11:22:57AM +0200, Vitalii Demianets wrote:
> 1. uioinfo was kfreed based on the presence of pdev->dev.of_node, which was
> obviously wrong and unrelated to the fact if uioinfo was allocated statically
> or dynamically. This patch introduces new flag which clearly shows if uioinfo
> was allocated dynamically and kfrees uioinfo based on that flag;
> 2. Fix: priv data was not freed in case platform_get_irq() failed. As it was
> caused mainly by improper exit labels naming, labels were renamed too;
> 3. The case of uioinfo AND pdev->dev.of_node both NULL (not initialized
> in platform data) was not treated properly.
I noticed two more issues. See below.
>
> Signed-off-by: Vitalii Demianets
>
> ---
> v2: Constants naming style
>
> ---
> drivers/uio/uio_pdrv_genirq.c | 44
> 1 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
> index 42202cd..75aaeee 100644
> --- a/drivers/uio/uio_pdrv_genirq.c
> +++ b/drivers/uio/uio_pdrv_genirq.c
> @@ -30,6 +30,11 @@
>
> #define DRIVER_NAME "uio_pdrv_genirq"
>
> +enum {
> + UIO_IRQ_DISABLED = 0,
> + UIO_INFO_ALLOCED = 1,
> +};
> +
> struct uio_pdrv_genirq_platdata {
> struct uio_info *uioinfo;
> spinlock_t lock;
> @@ -63,7 +68,7 @@ static irqreturn_t uio_pdrv_genirq_handler(int irq, struct
> uio_info *dev_info)
>* remember the state so we can allow user space to enable it later.
>*/
>
> - if (!test_and_set_bit(0, >flags))
> + if (!test_and_set_bit(UIO_IRQ_DISABLED, >flags))
> disable_irq_nosync(irq);
That is not safe. That flag can only be changed by userspace, and if the
userspace part is not running, the CPU on which the irq is pending will hang.
The handler has to disable the interrupt in any case.
(The original version had the same problem, I know...)
>
> return IRQ_HANDLED;
> @@ -83,10 +88,10 @@ static int uio_pdrv_genirq_irqcontrol(struct uio_info
> *dev_info, s32 irq_on)
>
> spin_lock_irqsave(>lock, flags);
> if (irq_on) {
> - if (test_and_clear_bit(0, >flags))
> + if (test_and_clear_bit(UIO_IRQ_DISABLED, >flags))
> enable_irq(dev_info->irq);
> } else {
> - if (!test_and_set_bit(0, >flags))
> + if (!test_and_set_bit(UIO_IRQ_DISABLED, >flags))
> disable_irq(dev_info->irq);
> }
> spin_unlock_irqrestore(>lock, flags);
> @@ -101,8 +106,9 @@ static int uio_pdrv_genirq_probe(struct platform_device
> *pdev)
> struct uio_mem *uiomem;
> int ret = -EINVAL;
> int i;
> + bool uioinfo_alloced = false;
>
> - if (!uioinfo) {
> + if (!uioinfo && pdev->dev.of_node) {
> int irq;
>
> /* alloc uioinfo for one device */
> @@ -110,10 +116,11 @@ static int uio_pdrv_genirq_probe(struct platform_device
> *pdev)
> if (!uioinfo) {
> ret = -ENOMEM;
> dev_err(>dev, "unable to kmalloc\n");
> - goto bad2;
> + goto out;
> }
> uioinfo->name = pdev->dev.of_node->name;
> uioinfo->version = "devicetree";
> + uioinfo_alloced = true;
>
> /* Multiple IRQs are not supported */
> irq = platform_get_irq(pdev, 0);
> @@ -125,32 +132,33 @@ static int uio_pdrv_genirq_probe(struct platform_device
> *pdev)
>
> if (!uioinfo || !uioinfo->name || !uioinfo->version) {
> dev_err(>dev, "missing platform_data\n");
> - goto bad0;
> + goto out_uioinfo;
> }
>
> if (uioinfo->handler || uioinfo->irqcontrol ||
> uioinfo->irq_flags & IRQF_SHARED) {
> dev_err(>dev, "interrupt configuration error\n");
> - goto bad0;
> + goto out_uioinfo;
> }
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> if (!priv) {
> ret = -ENOMEM;
> dev_err(>dev, "unable to kmalloc\n");
> - goto bad0;
> + goto out_uioinfo;
> }
>
> priv->uioinfo = uioinfo;
> spin_lock_init(>lock);
> - priv->flags = 0; /* interrupt is enabled to begin with */
> + /* interrupt is enabled to begin with */
> + priv->flags = uioinfo_alloced ? (1 << UIO_INFO_ALLOCED) : 0;
The comment doesn't describe the line it's supposed to comment.
> priv->pdev = pdev;
>
> if (!uioinfo->irq) {
> ret = platform_get_irq(pdev, 0);
> if (ret < 0) {
> dev_err(>dev, "failed to get IRQ\n");
> - goto bad0;
> + goto out_priv;
> }
> uioinfo->irq = ret;
> }
> @@ -205,19 +213,19 @@ static int uio_pdrv_genirq_probe(struct platform_device
> *pdev)
> ret =
Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
On 6 December 2012 04:12, Grant Likely wrote: > On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar > wrote: >> This first tries to match the table my patch added, _BUT_ the string will >> never match as we had "st,stmpe810" in table and "stmpe810" in dev. > > of_driver_match_device() matches against the compatible list in > dev->of_node, not against the device name. So, if the compatible > property has a string that is in the table, then it really should match > against it. Grant, but isn't it true that the final device's name would not be the DT way of names? It would simply be "stmpe810" for us and so if we have multiple instances of stmpe on a board, we need to distinguish them ourselves? One way for that was passing id for these instances, which would finally be used, when we create platform devices for sub-modules of stmpe (gpio, keypad, ts, etc). -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: MMU: optimize for set_spte
On 12/06/2012 05:09 AM, Marcelo Tosatti wrote:
> On Tue, Dec 04, 2012 at 07:17:11AM +0800, Xiao Guangrong wrote:
>> There are two cases we need to adjust page size in set_spte:
>> 1): the one is other vcpu creates new sp in the window between
>> mapping_level()
>> and acquiring mmu-lock.
>> 2): the another case is the new sp is created by itself (page-fault path)
>> when
>> guest uses the target gfn as its page table.
>>
>> In current code, set_spte drop the spte and emulate the access for these
>> case,
>> it works not good:
>> - for the case 1, it may destroy the mapping established by other vcpu, and
>> do expensive instruction emulation.
>> - for the case 2, it may emulate the access even if the guest is accessing
>> the page which not used as page table. There is a example, 0~2M is used as
>> huge page in guest, in this huge page, only page 3 used as page table, then
>> guest read/writes on other pages can cause instruction emulation.
>>
>> Both of these cases can be fixed by allowing guest to retry the access, it
>> will refault, then we can establish the mapping by using small page
>>
>> Signed-off-by: Xiao Guangrong
>> ---
>> arch/x86/kvm/mmu.c | 16
>> 1 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index b875a9e..01d7c2a 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -2382,12 +2382,20 @@ static int set_spte(struct kvm_vcpu *vcpu, u64
>> *sptep,
>> || (!vcpu->arch.mmu.direct_map && write_fault
>> && !is_write_protection(vcpu) && !user_fault)) {
>>
>> +/*
>> + * There are two cases:
>> + * - the one is other vcpu creates new sp in the window
>> + * between mapping_level() and acquiring mmu-lock.
>> + * - the another case is the new sp is created by itself
>> + * (page-fault path) when guest uses the target gfn as
>> + * its page table.
>> + * Both of these cases can be fixed by allowing guest to
>> + * retry the access, it will refault, then we can establish
>> + * the mapping by using small page.
>> + */
>> if (level > PT_PAGE_TABLE_LEVEL &&
>> -has_wrprotected_page(vcpu->kvm, gfn, level)) {
>> -ret = 1;
>> -drop_spte(vcpu->kvm, sptep);
>> +has_wrprotected_page(vcpu->kvm, gfn, level))
>> goto done;
>> -}
>>
>> spte |= PT_WRITABLE_MASK | SPTE_MMU_WRITEABLE;
>>
>> --
>> 1.7.7.6
>
> ACK.
>
> Does it fix your testcase?
No.
I will post the new version patch of improving reexecute_instruction.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] page_alloc: Make movablecore_map has higher priority
On 2012-12-6 9:26, Tang Chen wrote:
> On 12/05/2012 11:43 PM, Jiang Liu wrote:
>> If we make "movablecore_map" take precedence over "movablecore/kernelcore",
>> the logic could be simplified. I think it's not so attractive to support
>> both "movablecore_map" and "movablecore/kernelcore" at the same time.
>
> Hi Liu,
>
> Thanks for you advice. :)
>
> Memory hotplug needs different support on different hardware. We are
> trying to figure out a way to satisfy as many users as we can.
> Since it is a little difficult, it may take sometime. :)
>
> But I still think we need a boot option to support it. Just a metter of
> how to make it easier to use. :)
>
> Thanks. :)
>
>>
>> On 11/23/2012 06:44 PM, Tang Chen wrote:
>>> If kernelcore or movablecore is specified at the same time
>>> with movablecore_map, movablecore_map will have higher
>>> priority to be satisfied.
>>> This patch will make find_zone_movable_pfns_for_nodes()
>>> calculate zone_movable_pfn[] with the limit from
>>> zone_movable_limit[].
>>>
>>> Signed-off-by: Tang Chen
>>> Reviewed-by: Wen Congyang
>>> Reviewed-by: Lai Jiangshan
>>> Tested-by: Lin Feng
>>> ---
>>> mm/page_alloc.c | 35 +++
>>> 1 files changed, 31 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index f23d76a..05bafbb 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -4800,12 +4800,25 @@ static void __init
>>> find_zone_movable_pfns_for_nodes(void)
>>> required_kernelcore = max(required_kernelcore, corepages);
>>> }
>>>
>>> -/* If kernelcore was not specified, there is no ZONE_MOVABLE */
>>> -if (!required_kernelcore)
>>> +/*
>>> + * No matter kernelcore/movablecore was limited or not, movable_zone
>>> + * should always be set to a usable zone index.
>>> + */
>>> +find_usable_zone_for_movable();
>>> +
>>> +/*
>>> + * If neither kernelcore/movablecore nor movablecore_map is specified,
>>> + * there is no ZONE_MOVABLE. But if movablecore_map is specified, the
>>> + * start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
>>> + */
>>> +if (!required_kernelcore) {
>>> +if (movablecore_map.nr_map)
>>> +memcpy(zone_movable_pfn, zone_movable_limit,
>>> +sizeof(zone_movable_pfn));
>>> goto out;
>>> +}
>>>
>>> /* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at
>>> */
>>> -find_usable_zone_for_movable();
>>> usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
>>>
>>> restart:
>>> @@ -4833,10 +4846,24 @@ restart:
>>> for_each_mem_pfn_range(i, nid,_pfn,_pfn, NULL) {
>>> unsigned long size_pages;
>>>
>>> +/*
>>> + * Find more memory for kernelcore in
>>> + * [zone_movable_pfn[nid], zone_movable_limit[nid]).
>>> + */
>>> start_pfn = max(start_pfn, zone_movable_pfn[nid]);
>>> if (start_pfn>= end_pfn)
>>> continue;
>>>
>>> +if (zone_movable_limit[nid]) {
>>> +end_pfn = min(end_pfn, zone_movable_limit[nid]);
>>> +/* No range left for kernelcore in this node */
>>> +if (start_pfn>= end_pfn) {
>>> +zone_movable_pfn[nid] =
>>> +zone_movable_limit[nid];
>>> +break;
>>> +}
>>> +}
Hi Tang,
I just to remove the above logic, so the implementation will be greatly
simplified. Please refer to the attachment.
Regards!
Gerry
>>> +
>>> /* Account for what is only usable for kernelcore */
>>> if (start_pfn< usable_startpfn) {
>>> unsigned long kernel_pages;
>>> @@ -4896,12 +4923,12 @@ restart:
>>> if (usable_nodes&& required_kernelcore> usable_nodes)
>>> goto restart;
>>>
>>> +out:
>>> /* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
>>> for (nid = 0; nid< MAX_NUMNODES; nid++)
>>> zone_movable_pfn[nid] =
>>> roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
>>>
>>> -out:
>>> /* restore the node_state */
>>> node_states[N_HIGH_MEMORY] = saved_node_state;
>>> }
>>>
>>
>>
>
>
> .
>
>From 120759daa8410e1bf61d19210ddeb52ef32d002a Mon Sep 17 00:00:00 2001
From: Jiang Liu
Date: Wed, 5 Dec 2012 23:58:42 +0800
Subject: [PATCH 3/6] page_alloc: Introduce zone_movable_limit[] to keep
movable limit for nodes
This patch introduces a new array zone_movable_limit[] to store the
ZONE_MOVABLE limit from movablecore_map boot option for all nodes.
The function sanitize_zone_movable_limit() will find out to which
node the ranges in movable_map.map[] belongs, and calculates the
low boundary of ZONE_MOVABLE for each node.
Signed-off-by: Tang Chen
Reviewed-by: Wen Congyang
Reviewed-by: Lai Jiangshan
Tested-by: Lin Feng
page_alloc: Make
Re: IRQ subsystem menu
Grant Likely , on Thu 2012.11.29 said: > On Mon, 29 Oct 2012 15:03:08 +0100, Michal Marek wrote: > > (Adding lkml and Thomas as IRQ subsystem maintainer to CC) > > > > On Sun, Oct 21, 2012 at 03:40:16AM -0400, Paul Thompson wrote: > > > Hi; > > > > > > In menuconfig, General setup -> IRQ subsystem, there are two > > > possible menu-items. One depends partly on IRQ_DOMAIN, and the other > > > on MAY_HAVE_SPARSE_IRQ. > > > [...] > > > > > > Ideally, the "IRQ subsystem" menu would not even show up > > > if it would contain no menu-items, but I do not know enough to > > > formulate that constraint. > > First, move the 'menu "IRQ subsystem"' line does to right before the > IRQ_DOMAIN_DEBUG line so that it wraps the options that matter, then you > can add a "depends on MAY_HAVE_SPARSE_IRQ || IRQ_DOMAIN" line right > below the menu item. > > You'll also need to move the IRQ_FORCED_THREADING line out from inside > the menu block. > > Try it out and let me know how it goes. > > g. Hi; The logic makes sense to me, and makes the menus appearance dependent on if either option setting can exist. So, on my system, the IRQ subsystem menu does not appear. Paul See if this attached patch looks right: --- linux-3.7-rc8/kernel/irq/Kconfig.orig 2012-12-05 20:59:00.963707538 -0500 +++ linux-3.7-rc8/kernel/irq/Kconfig2012-12-05 21:00:18.454788693 -0500 @@ -3,7 +3,6 @@ config HAVE_GENERIC_HARDIRQS bool if HAVE_GENERIC_HARDIRQS -menu "IRQ subsystem" # # Interrupt subsystem related configuration options # @@ -56,6 +55,13 @@ config GENERIC_IRQ_CHIP config IRQ_DOMAIN bool +# Support forced irq threading +config IRQ_FORCED_THREADING + bool + +menu "IRQ subsystem" + depends on ( IRQ_DOMAIN && DEBUG_FS ) || MAY_HAVE_SPARSE_IRQ + config IRQ_DOMAIN_DEBUG bool "Expose hardware/virtual IRQ mapping via debugfs" depends on IRQ_DOMAIN && DEBUG_FS @@ -66,10 +72,6 @@ config IRQ_DOMAIN_DEBUG If you don't know what this means you don't need it. -# Support forced irq threading -config IRQ_FORCED_THREADING - bool - config SPARSE_IRQ bool "Support sparse irq numbering" if MAY_HAVE_SPARSE_IRQ ---help---
Re: [PATCH 0/3] dynamic_debug: Add print_hex_dump_bytes/debug support and cleanups
On Wed, Dec 05, 2012 at 02:05:06PM -0800, Joe Perches wrote:
> On Wed, 2012-12-05 at 16:48 -0500, Jason Baron wrote:
> > Here's a collection of the latest dynamic debug patches that I have
> > pending.
>
> Any update on the jump table support?
>
I have patches that implement the support, although they are a bit hacky
due to header dependencies. However, the main reason I didn't post them
yet is that the 'data' section increases quite a bit due to the
increased table size (text section is reduced, since we are saving
instructions). On x86_64, the the upper 32-bits of each table entry are
always '0x', so the table could be reduced by a factor of 2.
Although, I haven't figured out a simple way of doing so. Perhaps, the
'data' section bloat is ok, due to the runtime savings, though. I can
dig out the % increase data.
While we're on new features, I think it would be nice to have the ability
to enable the core dynamic debug library - lib/dynamic_debug.c,
independently from the debug statements that use it. So, having
CONFIG_DYNAMIC_DEBUG would just configure the infrastructure bits, and
something such as CONFIG_DYNAMIC_DEBUG_PRINTK could enable pr_debug() and
friends. In that way subsystems that want to use dynamic output can be
enabled/disabled independently. So they could do:
#ifdef CONFIG_DRIVER_FOO_DEBUG
#define drv_foo_debug() dev_dbg()
#else
#define drv_foo_debug() {}
where CONFIG_DRIVER_FOO_DEBUG would enable CONFIG_DYNAMIC_DEBUG.
Thanks,
-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
First of all, thanks for explaining :)
On 6 December 2012 04:12, Grant Likely wrote:
> On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar
> wrote:
>> This first tries to match the table my patch added, _BUT_ the string will
>> never match as we had "st,stmpe810" in table and "stmpe810" in dev.
>
> of_driver_match_device() matches against the compatible list in
> dev->of_node, not against the device name. So, if the compatible
> property has a string that is in the table, then it really should match
> against it.
How could i misread it? Yes you are correct.
>> static int i2c_device_probe(struct device *dev)
>> {
>> .
>> status = driver->probe(client, i2c_match_id(driver->id_table, client));
>
> Here things are a bit wonky. Even if matched against the table, it is
table means of_device_id table ?
> possible that it also matches against i2c_match_id() and that data is
> passed to the driver.
It is a possibility or guarantee ? And so whatever device name we got from
modalias routine, should match with the names in driver->id_table.
> But regardless, it is the responsiblity of the probe function to go and
> look if of_driver_match_device() matches against anything if it cares
> about the of_match_table entries (for instance, if there is extra data
> attached).
Ok, so filling .data field in of_device_id[] is not required for our case as
we aren't doing anything special in our drivers.
>> Which will again match the legacy table to find correct struct i2c_device_id
>> *id
>> to pass to probe().
>>
>> So, the final question: WTF is of_match_table for?
>
> A bit of history is valuable here. The whole of_modalias_node() thing is
> really just a best-effort heuristic for figuring out which driver
> *might* work against a device described in the device tree. It won't
> work in all circumstances (and it was created at a time when there was
> resistance to adding DT knowledge to drivers). An of_match_table is the
> robust way of identifying specific devices and allows for matching
> against any entry in the compatible list.
Got it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Documentation: add docs for 88pm80x dt
On 12/06/2012 06:55 AM, Grant Likely wrote: On Wed, 5 Dec 2012 13:42:00 +0800, Qing Xu wrote: From: Qing Xu Signed-off-by: Qing Xu No commit text? This patch needs to be squashed together with the patch that changes the driver. There is no value in separating them. --- Documentation/devicetree/bindings/mfd/88pm80x.txt | 52 + 1 files changed, 52 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/88pm80x.txt diff --git a/Documentation/devicetree/bindings/mfd/88pm80x.txt b/Documentation/devicetree/bindings/mfd/88pm80x.txt new file mode 100644 index 000..8a0ed07 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/88pm80x.txt @@ -0,0 +1,52 @@ +* Marvell 88pm80x Power Management IC + +Required parent device properties: +- compatible : "marvell,88pm80x" +- reg : the I2C slave address for the 88pm80x chip +- interrupts : IRQ line for the 88pm80x chip +- interrupt-controller: describes the 88pm80x as an interrupt controller (has its own domain) +- #interrupt-cells : should be 1. + - The cell is the 88pm80x local IRQ number + +Optional parent device properties: +- marvell,88pm80x-irqmode: inicates whether interrupt status is cleared by read +- marvell,88pm80x-poweraddr: 88pm80x are multi-chips solution. stores the I2C address + of one chip, and this property stores the I2C address of + power related chip. +- marvell,88pm80x-gpadcaddr: 88pm80x are multi-chips solution. stores the I2C address + of one chip, and this property stores the I2C address of + gpadc related chip. If it is multichip, then I would expect either a separate node for each chip and these properties use phandles (instead of i2c addresses) to point to the other chip nodes. Alternately, if the cluster is described using a single node, then you can put all three i2c addresses into the 'reg' property. g. combined to one patch. please help review again. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kexec and struct boot_params
Hi Eric, Could you give a list of struct boot_params field which are initialized properly by kexec? I think we need to do the sentinel hack, and want to know what to whitelist. Also, does kexec set a bootloader ID? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: 88pm80x: add dt support
From: Qing Xu
add dt support for 88pm800 and 88pm805
Signed-off-by: Qing Xu
---
Documentation/devicetree/bindings/mfd/88pm80x.txt | 52 +
drivers/mfd/88pm800.c | 26 +-
drivers/mfd/88pm805.c | 26 +-
drivers/mfd/88pm80x.c | 32 +
include/linux/mfd/88pm80x.h |3 +
5 files changed, 133 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/88pm80x.txt
diff --git a/Documentation/devicetree/bindings/mfd/88pm80x.txt
b/Documentation/devicetree/bindings/mfd/88pm80x.txt
new file mode 100644
index 000..8a0ed07
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/88pm80x.txt
@@ -0,0 +1,52 @@
+* Marvell 88pm80x Power Management IC
+
+Required parent device properties:
+- compatible : "marvell,88pm80x"
+- reg : the I2C slave address for the 88pm80x chip
+- interrupts : IRQ line for the 88pm80x chip
+- interrupt-controller: describes the 88pm80x as an interrupt controller (has
its own domain)
+- #interrupt-cells : should be 1.
+ - The cell is the 88pm80x local IRQ number
+
+Optional parent device properties:
+- marvell,88pm80x-irqmode: inicates whether interrupt status is cleared by read
+- marvell,88pm80x-poweraddr: 88pm80x are multi-chips solution. stores
the I2C address
+ of one chip, and this property stores the I2C
address of
+ power related chip.
+- marvell,88pm80x-gpadcaddr: 88pm80x are multi-chips solution. stores
the I2C address
+ of one chip, and this property stores the I2C
address of
+ gpadc related chip.
+
+88pm80x consists of various groups of sub-devices:
+
+Device Supply NamesDescription
+-- ---
+88pm80x-onkey : : On key
+88pm80x-rtc: : RTC
+
+Example:
+ pmic: 88pm800@30 {
+ compatible = "marvell,88pm80x";
+ reg = <0x30>;
+ interrupts = <4>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ marvell,88pm80x-irqmode = 0;
+ marvell,88pm80x-poweraddr = <0x31>;
+ marvell,88pm80x-gpadcaddr = <0x32>;
+ };
+
+
+ pmic: 88pm805@38 {
+ compatible = "marvell,88pm80x";
+ reg = <0x38>;
+ interrupts = <124>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ marvell,88pm80x-irqmode = 0;
+ };
+
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 3fcc8dd..20b67d7 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -506,6 +506,22 @@ static int __devinit pm800_probe(struct i2c_client *client,
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
struct pm80x_subchip *subchip;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -540,9 +556,6 @@ static int __devinit pm800_probe(struct i2c_client *client,
goto err_800_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_800_init:
@@ -570,11 +583,18 @@ static int __devexit pm800_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm800_dt_ids[] = {
+ { .compatible = "marvell,88pm800", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm800_dt_ids);
+
static struct i2c_driver pm800_driver = {
.driver = {
.name = "88PM800",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm800_dt_ids),
},
.probe = pm800_probe,
.remove = __devexit_p(pm800_remove),
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index 39a91bd..b0fb3ff 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -239,6 +239,22 @@ static int __devinit pm805_probe(struct i2c_client *client,
int ret = 0;
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata =
Re: [PATCH v2 4/5] page_alloc: Make movablecore_map has higher priority
On 12/05/2012 11:43 PM, Jiang Liu wrote:
If we make "movablecore_map" take precedence over "movablecore/kernelcore",
the logic could be simplified. I think it's not so attractive to support
both "movablecore_map" and "movablecore/kernelcore" at the same time.
Hi Liu,
Thanks for you advice. :)
Memory hotplug needs different support on different hardware. We are
trying to figure out a way to satisfy as many users as we can.
Since it is a little difficult, it may take sometime. :)
But I still think we need a boot option to support it. Just a metter of
how to make it easier to use. :)
Thanks. :)
On 11/23/2012 06:44 PM, Tang Chen wrote:
If kernelcore or movablecore is specified at the same time
with movablecore_map, movablecore_map will have higher
priority to be satisfied.
This patch will make find_zone_movable_pfns_for_nodes()
calculate zone_movable_pfn[] with the limit from
zone_movable_limit[].
Signed-off-by: Tang Chen
Reviewed-by: Wen Congyang
Reviewed-by: Lai Jiangshan
Tested-by: Lin Feng
---
mm/page_alloc.c | 35 +++
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f23d76a..05bafbb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4800,12 +4800,25 @@ static void __init
find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
- /* If kernelcore was not specified, there is no ZONE_MOVABLE */
- if (!required_kernelcore)
+ /*
+* No matter kernelcore/movablecore was limited or not, movable_zone
+* should always be set to a usable zone index.
+*/
+ find_usable_zone_for_movable();
+
+ /*
+* If neither kernelcore/movablecore nor movablecore_map is specified,
+* there is no ZONE_MOVABLE. But if movablecore_map is specified, the
+* start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
+*/
+ if (!required_kernelcore) {
+ if (movablecore_map.nr_map)
+ memcpy(zone_movable_pfn, zone_movable_limit,
+ sizeof(zone_movable_pfn));
goto out;
+ }
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
- find_usable_zone_for_movable();
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
restart:
@@ -4833,10 +4846,24 @@ restart:
for_each_mem_pfn_range(i, nid,_pfn,_pfn, NULL) {
unsigned long size_pages;
+ /*
+* Find more memory for kernelcore in
+* [zone_movable_pfn[nid], zone_movable_limit[nid]).
+*/
start_pfn = max(start_pfn, zone_movable_pfn[nid]);
if (start_pfn>= end_pfn)
continue;
+ if (zone_movable_limit[nid]) {
+ end_pfn = min(end_pfn, zone_movable_limit[nid]);
+ /* No range left for kernelcore in this node */
+ if (start_pfn>= end_pfn) {
+ zone_movable_pfn[nid] =
+ zone_movable_limit[nid];
+ break;
+ }
+ }
+
/* Account for what is only usable for kernelcore */
if (start_pfn< usable_startpfn) {
unsigned long kernel_pages;
@@ -4896,12 +4923,12 @@ restart:
if (usable_nodes&& required_kernelcore> usable_nodes)
goto restart;
+out:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
for (nid = 0; nid< MAX_NUMNODES; nid++)
zone_movable_pfn[nid] =
roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
-out:
/* restore the node_state */
node_states[N_HIGH_MEMORY] = saved_node_state;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/6] kvm: Re-introduce memslots->nmemslots
On Wed, Dec 05, 2012 at 04:02:53PM -0700, Alex Williamson wrote:
> On Wed, 2012-12-05 at 19:26 -0200, Marcelo Tosatti wrote:
> > On Mon, Dec 03, 2012 at 04:39:36PM -0700, Alex Williamson wrote:
> > > struct kvm_memory_slot is currently 52 bytes (LP64), not counting the
> > > arch data. On x86 this means the memslot array to support a tiny 32+3
> > > entries (user+private) is over 2k. We'd like to support more slots
> > > so that we can support more assigned devices, but it doesn't make
> > > sense to penalize everyone by using a statically allocated array.
> > > This allows us to start introducing a grow-able array.
> > >
> > > Signed-off-by: Alex Williamson
> > > ---
> > > arch/ia64/kvm/kvm-ia64.c |2 +-
> > > arch/powerpc/kvm/book3s_hv.c |2 +-
> > > arch/x86/kvm/vmx.c |1 +
> > > arch/x86/kvm/x86.c |4 +++-
> > > include/linux/kvm_host.h |9 ++---
> > > virt/kvm/kvm_main.c | 10 ++
> > > 6 files changed, 18 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
> > > index 012e5dd..96401b5 100644
> > > --- a/arch/ia64/kvm/kvm-ia64.c
> > > +++ b/arch/ia64/kvm/kvm-ia64.c
> > > @@ -1836,7 +1836,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> > >
> > > memslot = id_to_memslot(kvm->memslots, log->slot);
> > > r = -ENOENT;
> > > - if (!memslot->dirty_bitmap)
> > > + if (!memslots || !memslot->dirty_bitmap)
> > > goto out;
> > >
> > > kvm_ia64_sync_dirty_log(kvm, memslot);
> > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > > index 56067db..0417190 100644
> > > --- a/arch/powerpc/kvm/book3s_hv.c
> > > +++ b/arch/powerpc/kvm/book3s_hv.c
> > > @@ -1267,7 +1267,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> > > struct kvm_dirty_log *log)
> > >
> > > memslot = id_to_memslot(kvm->memslots, log->slot);
> > > r = -ENOENT;
> > > - if (!memslot->dirty_bitmap)
> > > + if (!memslot || !memslot->dirty_bitmap)
> > > goto out;
> > >
> > > n = kvm_dirty_bitmap_bytes(memslot);
> > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > index 2bb9157..07fdd90 100644
> > > --- a/arch/x86/kvm/vmx.c
> > > +++ b/arch/x86/kvm/vmx.c
> > > @@ -2751,6 +2751,7 @@ static gva_t rmode_tss_base(struct kvm *kvm)
> > >
> > > slots = kvm_memslots(kvm);
> > > slot = id_to_memslot(slots, KVM_PRIVATE_MEM_SLOTS);
> > > + BUG_ON(!slot);
> > > base_gfn = slot->base_gfn + slot->npages - 3;
> > >
> > > return base_gfn << PAGE_SHIFT;
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index 8765485..53fe9b2 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -3139,9 +3139,11 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> > > struct kvm_dirty_log *log)
> > > goto out;
> > >
> > > memslot = id_to_memslot(kvm->memslots, log->slot);
> > > + r = -ENOENT;
> > > + if (!memslot)
> > > + goto out;
> > >
> > > dirty_bitmap = memslot->dirty_bitmap;
> > > - r = -ENOENT;
> > > if (!dirty_bitmap)
> > > goto out;
> > >
> > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > > index 7b3d5c4..1955a4e 100644
> > > --- a/include/linux/kvm_host.h
> > > +++ b/include/linux/kvm_host.h
> > > @@ -313,6 +313,7 @@ struct kvm_irq_routing_table {};
> > > * to get the memslot by its id.
> > > */
> > > struct kvm_memslots {
> > > + int nmemslots;
> > > u64 generation;
> > > struct kvm_memory_slot memslots[KVM_MEM_SLOTS_NUM];
> > > };
> > > @@ -397,7 +398,7 @@ static inline struct kvm_vcpu *kvm_get_vcpu(struct
> > > kvm *kvm, int i)
> > >
> > > #define kvm_for_each_memslot(memslot, slots) \
> > > for (memslot = >memslots[0]; \
> > > - memslot < slots->memslots + KVM_MEM_SLOTS_NUM && memslot->npages;\
> > > + memslot < slots->memslots + slots->nmemslots && memslot->npages;\
> > > memslot++)
> > >
> > > int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id);
> > > @@ -424,10 +425,12 @@ static inline struct kvm_memslots
> > > *kvm_memslots(struct kvm *kvm)
> > > static inline struct kvm_memory_slot *
> > > id_to_memslot(struct kvm_memslots *slots, int id)
> > > {
> > > - int index = slots->memslots[id].id_to_index;
> > > struct kvm_memory_slot *slot;
> > >
> > > - slot = >memslots[index];
> > > + if (id >= slots->nmemslots)
> > > + return NULL;
> > > +
> > > + slot = >memslots[slots->memslots[id].id_to_index];
> > >
> > > WARN_ON(slot->id != id);
> > > return slot;
> > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > index 3ce2664..ebd3960 100644
> > > --- a/virt/kvm/kvm_main.c
> > > +++ b/virt/kvm/kvm_main.c
> > > @@ -444,7 +444,9 @@ static void kvm_init_memslots_id(struct kvm *kvm)
> > > int i;
> > > struct kvm_memslots *slots = kvm->memslots;
> > >
> > > - for (i = 0; i < KVM_MEM_SLOTS_NUM; i++)
> > > +
Re: [PATCH v5 2/3] aerdrv: Enhanced AER logging
On Tue, 2012-12-04 at 10:30 +0100, Borislav Petkov wrote: > Steve, > > AFAIU, this will create all tracepoint code from the ras.h header > in this compilation unit, i.e. aerdrv_errprint.c. It has only one > tracepoint now but with time, as more RAS TPs are being added, it would > make sense to have that CREATE_TRACE_POINTS code at a more central place > in the kernel, right? Yes. > > And, on configs with PCIEAER disabled, we won't have the TPs available > so the CREATE_TRACE_POINTS thing should be in a compilation unit which > gets included unconditionally, correct? You can have a config that enables these trace points, and when you enable one of the systems that uses them, have that config select the config that enables tracepoints. Have that config compile the file for tracepoints. For example, in a Makefile: obj-$(CONFIG_RAS_TRACE_POINTS) += ras-trace.o Use #ifdef CONFIG_FOO_BAR around tracepoints that are required for specific systems if the tracepoints in the header file are for different subsystems that can be enabled or disabled separately by configs. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V2 PATCH 2/2] rtc: pxa: add pxa95x rtc support
On Wed, Dec 5, 2012 at 3:04 PM, Haojian Zhuang wrote:
> On Wed, Dec 5, 2012 at 2:49 PM, Chao Xie wrote:
>> the pxa95x rtc need access PBSR register before write to
>> RTTR, RCNR, RDCR, and RYCR registers.
>>
>> Signed-off-by: Chao Xie
>> ---
>> drivers/rtc/rtc-pxa.c | 100
>> +---
>> 1 files changed, 85 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c
>> index f771b2e..aee23cb 100644
>> --- a/drivers/rtc/rtc-pxa.c
>> +++ b/drivers/rtc/rtc-pxa.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -77,14 +78,28 @@
>> #define RTCPICR0x34
>> #define PIAR 0x38
>>
>> +#define PSBR_RTC 0x00
>> +
>> #define rtc_readl(pxa_rtc, reg)\
>> __raw_readl((pxa_rtc)->base + (reg))
>> #define rtc_writel(pxa_rtc, reg, value)\
>> __raw_writel((value), (pxa_rtc)->base + (reg))
>> +#define rtc_readl_psbr(pxa_rtc, reg) \
>> + __raw_readl((pxa_rtc)->base_psbr + (reg))
>> +#define rtc_writel_psbr(pxa_rtc, reg, value) \
>> + __raw_writel((value), (pxa_rtc)->base_psbr + (reg))
>> +
>> +enum {
>> + RTC_PXA27X,
>> + RTC_PXA95X,
>> +};
>>
>> struct pxa_rtc {
>> struct resource *ress;
>> + struct resource *ress_psbr;
>> + unsigned intid;
>> void __iomem*base;
>> + void __iomem*base_psbr;
>> int irq_1Hz;
>> int irq_Alrm;
>> struct rtc_device *rtc;
>> @@ -242,9 +257,26 @@ static int pxa_rtc_set_time(struct device *dev, struct
>> rtc_time *tm)
>> {
>> struct pxa_rtc *pxa_rtc = dev_get_drvdata(dev);
>>
>> + /*
>> +* sequence to wirte pxa rtc register RCNR RDCR RYCR is
>> +* 1. set PSBR[RWE] bit, take 2x32-khz to complete
>> +* 2. write to RTC register,take 2x32-khz to complete
>> +* 3. clear PSBR[RWE] bit,take 2x32-khz to complete
>> +*/
>> + if (pxa_rtc->id == RTC_PXA95X) {
>> + rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x01);
>> + udelay(100);
>> + }
>
> How about define PSBP operation as a new clock, rtc interface clock.
> Then you could put
> the enable/disable into clock framework. And you only need to check
> whether the interface
> clock is NULL or not at here. If it's available, you can call
> clk_prepare_enable().
>
>> +
>> rtc_writel(pxa_rtc, RYCR, ryxr_calc(tm));
>> rtc_writel(pxa_rtc, RDCR, rdxr_calc(tm));
>>
>> + if (pxa_rtc->id == RTC_PXA95X) {
>> + udelay(100);
>> + rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x00);
>> + udelay(100);
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -310,6 +342,20 @@ static const struct rtc_class_ops pxa_rtc_ops = {
>> .proc = pxa_rtc_proc,
>> };
>>
>> +static struct of_device_id pxa_rtc_dt_ids[] = {
>> + { .compatible = "marvell,pxa-rtc", .data = (void *)RTC_PXA27X },
>> + { .compatible = "marvell,pxa95x-rtc", .data = (void *)RTC_PXA95X },
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, pxa_rtc_dt_ids);
>> +
>> +static const struct platform_device_id pxa_rtc_id_table[] = {
>> + { "pxa-rtc", RTC_PXA27X },
>> + { "pxa95x-rtc", RTC_PXA95X },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, pxa_rtc_id_table);
>> +
>> static int __init pxa_rtc_probe(struct platform_device *pdev)
>> {
>> struct device *dev = >dev;
>> @@ -324,13 +370,34 @@ static int __init pxa_rtc_probe(struct platform_device
>> *pdev)
>> spin_lock_init(_rtc->lock);
>> platform_set_drvdata(pdev, pxa_rtc);
>>
>> + if (pdev->dev.of_node) {
>> + const struct of_device_id *of_id =
>> + of_match_device(pxa_rtc_dt_ids, >dev);
>> +
>> + pxa_rtc->id = (unsigned int)(of_id->data);
>> + } else {
>> + const struct platform_device_id *id =
>> + platform_get_device_id(pdev);
>> +
>> + pxa_rtc->id = id->driver_data;
>> + }
>> +
>> ret = -ENXIO;
>> pxa_rtc->ress = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> if (!pxa_rtc->ress) {
>> - dev_err(dev, "No I/O memory resource defined\n");
>> + dev_err(dev, "No I/O memory resource(id=0) defined\n");
>> goto err_ress;
>> }
>>
>> + if (pxa_rtc->id == RTC_PXA95X) {
>> + pxa_rtc->ress_psbr =
>> + platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> + if (!pxa_rtc->ress_psbr) {
>> + dev_err(dev, "No I/O memory resource(id=1)
>> defined\n");
>> + goto err_ress;
>> + }
>> + }
>> +
>> pxa_rtc->irq_1Hz = platform_get_irq(pdev, 0);
>> if (pxa_rtc->irq_1Hz < 0) {
>>
Re: [PATCH v2 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
On 12/05/2012 11:46 PM, Jiang Liu wrote:
On 11/23/2012 06:44 PM, Tang Chen wrote:
This patch introduces a new array zone_movable_limit[] to store the
ZONE_MOVABLE limit from movablecore_map boot option for all nodes.
The function sanitize_zone_movable_limit() will find out to which
node the ranges in movable_map.map[] belongs, and calculates the
low boundary of ZONE_MOVABLE for each node.
Signed-off-by: Tang Chen
Reviewed-by: Wen Congyang
Reviewed-by: Lai Jiangshan
Tested-by: Lin Feng
---
mm/page_alloc.c | 55 +++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index fb5cf12..f23d76a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -206,6 +206,7 @@ static unsigned long __meminitdata
arch_zone_highest_possible_pfn[MAX_NR_ZONES];
static unsigned long __initdata required_kernelcore;
static unsigned long __initdata required_movablecore;
static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+static unsigned long __meminitdata zone_movable_limit[MAX_NUMNODES];
/* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */
int movable_zone;
@@ -4323,6 +4324,55 @@ static unsigned long __meminit
zone_absent_pages_in_node(int nid,
return __absent_pages_in_range(nid, zone_start_pfn, zone_end_pfn);
}
+/**
+ * sanitize_zone_movable_limit - Sanitize the zone_movable_limit array.
+ *
+ * zone_movable_limit is initialized as 0. This function will try to get
+ * the first ZONE_MOVABLE pfn of each node from movablecore_map, and
+ * assigne them to zone_movable_limit.
+ * zone_movable_limit[nid] == 0 means no limit for the node.
+ *
+ * Note: Each range is represented as [start_pfn, end_pfn)
+ */
+static void __meminit sanitize_zone_movable_limit(void)
+{
+ int map_pos = 0, i, nid;
+ unsigned long start_pfn, end_pfn;
+
+ if (!movablecore_map.nr_map)
+ return;
+
+ /* Iterate all ranges from minimum to maximum */
+ for_each_mem_pfn_range(i, MAX_NUMNODES,_pfn,_pfn,) {
+ /*
+* If we have found lowest pfn of ZONE_MOVABLE of the node
+* specified by user, just go on to check next range.
+*/
+ if (zone_movable_limit[nid])
+ continue;
Need special handling of low memory here on systems with highmem, otherwise
it will cause us to configure both lowmem and highmem as movable_zone.
Hi Liu,
Yes, and also the DMA address checking you mentioned before.
Thanks. :)
+
+ while (map_pos< movablecore_map.nr_map) {
+ if (end_pfn<= movablecore_map.map[map_pos].start)
+ break;
+
+ if (start_pfn>= movablecore_map.map[map_pos].end) {
+ map_pos++;
+ continue;
+ }
+
+ /*
+* The start_pfn of ZONE_MOVABLE is either the minimum
+* pfn specified by movablecore_map, or 0, which means
+* the node has no ZONE_MOVABLE.
+*/
+ zone_movable_limit[nid] = max(start_pfn,
+ movablecore_map.map[map_pos].start);
+
+ break;
+ }
+ }
+}
+
#else /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
@@ -4341,6 +4391,10 @@ static inline unsigned long __meminit
zone_absent_pages_in_node(int nid,
return zholes_size[zone_type];
}
+static void __meminit sanitize_zone_movable_limit(void)
+{
+}
+
#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
@@ -4906,6 +4960,7 @@ void __init free_area_init_nodes(unsigned long
*max_zone_pfn)
/* Find the PFNs that ZONE_MOVABLE begins at in each node */
memset(zone_movable_pfn, 0, sizeof(zone_movable_pfn));
+ sanitize_zone_movable_limit();
find_zone_movable_pfns_for_nodes();
/* Print out the zone ranges */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Use PCI ROMs from EFI boot services
On 12/05/2012 05:13 PM, Matthew Garrett wrote: "H. Peter Anvin" wrote: And that presumably would be something that cannot be exposed to root? If so we may want to use one of the bits in the setup_data type field as a security flag, perhaps... Yeah, it needs to be hidden from root - but ideally we'd be passing it to the second kernel if we kexec. Alternative would be for it to be capability bounded to a trusted signed kexec binary if we implement Vivek's IMA-based approach. Either way a security flag in the type field makes sense. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] propagate name change to comments in kernel source
On Thu, 2012-12-06 at 12:01 +1100, Stephen Rothwell wrote: > OK, that may be a problem. Does this patch apply to Linus' tree > currently? I guess not. So, either you need to split it up and send it > to the various maintainers (most if it can probably go through the trivial > tree (cc'd)). Or wait until after v3.8-rc1 and fix it so it applies to > Linus' tree and send it to him. > Or Andrew (cc'd) may be able to take it (as his tree is based on > linux-next currently). > (I have attached the patch for Jiri's and Andrew's benefit) It applies with offsets to Linus' current git, actually. I can provide a diff applying with no offsets, but suspect it's unnecessary. The affected comment blocks don't seem to have experienced much turnover recently, if ever. -- nyc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI
On Wed, Dec 05, 2012 at 10:25:17AM -0800, Linus Torvalds wrote: > Yes, people can argue that "process" is about technical issues too, > but let's be honest: our process is fluid. Not everything gets > reviewed on the mailing list, and people *do* talk about things > face-to-face at conferences. Yes, that is true. But we don't review code at conferences. We have mailing lists for that. I've lost count of the number of times I've heard "post your code" or "let's take it to the list" or "better to discuss this on the list where everyone can comment" at conferences such as Plumbers. It's a standard practise - talk at conferences, review on mailing lists. And for changes to syscalls? That's something that must be peer reviewed because we are going to be stuck with those changes forever as we can't undo them at a later date. It doesn't matter who made the change in question, I would have done exactly the same thing Cheers, Dave. -- Dave Chinner da...@fromorbit.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: Use PCI ROMs from EFI boot services
"H. Peter Anvin" wrote: >And that presumably would be something that cannot be exposed to root? >If so we may want to use one of the bits in the setup_data type field >as >a security flag, perhaps... Yeah, it needs to be hidden from root - but ideally we'd be passing it to the second kernel if we kexec. Alternative would be for it to be capability bounded to a trusted signed kexec binary if we implement Vivek's IMA-based approach. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] perf hists: Link hist entries before inserting to an output tree
On Wed, 5 Dec 2012 20:15:47 +0100, Jiri Olsa wrote: > On Wed, Dec 05, 2012 at 08:06:46PM +0100, Jiri Olsa wrote: >> On Wed, Dec 05, 2012 at 03:56:42PM +0900, Namhyung Kim wrote: >> > From: Namhyung Kim >> > @@ -481,6 +459,11 @@ static void hists__process(struct hists *old, struct >> > hists *new) >> >else >> >hists__link(new, old); >> > >> > + hists__output_resort(new); >> > + >> > + if (show_displacement) >> > + hists__compute_position(new); >> > + >> >> Computing the position after hists__link screws up the position data, >> because we likely have new entries in. >> >> However, I wonder if anyone is actualy using displacement info..? > > hum, > > the point of the displacement is to show how far is the matching entry > in baseline wrt report output -> after hists__output_resort.. that goes > in opposite way of what we try do to in here. > > Anyone else in favour of removing 'Displ.' column? ;-) Oh, I somehow thought that the new dummy entries go into the baseline. It's your change in the multi-diff patchset, not current code, right? So we can change either the baseline to have dummies or skipping dummies when computing their position. Of course I have no objection to get rid of the displacement logic completely too. :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Use PCI ROMs from EFI boot services
On 12/05/2012 04:57 PM, Matthew Garrett wrote: > > > "H. Peter Anvin" wrote: > >> I don't think there is anything security-sensitive about that >> information, at least not to root. I could be wrong, of course; I >> wouldn't mind security people telling me about that. > > I don't think there's anything at present, but we'll want to pass the > hibernation encryption key from the bootloader to the kernel in the near > future. setup_data seems like the easiest way to do that. > And that presumably would be something that cannot be exposed to root? If so we may want to use one of the bits in the setup_data type field as a security flag, perhaps... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] propagate name change to comments in kernel source
Hi Nadia, On Wed, 05 Dec 2012 19:44:28 -0500 Nadia Yvette Chambers wrote: > > I've legally changed my name with New York State, the US Social Security > Administration, et al. This patch propagates the name change and change > in initials and login to comments in the kernel source as well. > > vs. next-20121205 OK, that may be a problem. Does this patch apply to Linus' tree currently? I guess not. So, either you need to split it up and send it to the various maintainers (most if it can probably go through the trivial tree (cc'd)). Or wait until after v3.8-rc1 and fix it so it applies to Linus' tree and send it to him. Or Andrew (cc'd) may be able to take it (as his tree is based on linux-next currently). (I have attached the patch for Jiri's and Andrew's benefit) -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --git a/MAINTAINERS b/MAINTAINERS index 26c7b01..b3055a2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3659,7 +3659,7 @@ S: Maintained F: drivers/input/touchscreen/htcpen.c HUGETLB FILESYSTEM -M: William Irwin +M: Nadia Yvette Chambers S: Maintained F: fs/hugetlbfs/ diff --git a/arch/alpha/include/asm/mmzone.h b/arch/alpha/include/asm/mmzone.h index 445dc42..c5b5d6b 100644 --- a/arch/alpha/include/asm/mmzone.h +++ b/arch/alpha/include/asm/mmzone.h @@ -66,7 +66,7 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p, int n) ((unsigned long)__va(NODE_DATA(kvaddr_to_nid(kaddr))->node_start_pfn \ << PAGE_SHIFT)) -/* XXX: FIXME -- wli */ +/* XXX: FIXME -- nyc */ #define kern_addr_valid(kaddr) (0) #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT) diff --git a/arch/frv/mm/pgalloc.c b/arch/frv/mm/pgalloc.c index 4fb63a3..f6084bc 100644 --- a/arch/frv/mm/pgalloc.c +++ b/arch/frv/mm/pgalloc.c @@ -77,7 +77,7 @@ void __set_pmd(pmd_t *pmdptr, unsigned long pmd) * checks at dup_mmap(), exec(), and other mmlist addition points * could be used. The locking scheme was chosen on the basis of * manfred's recommendations and having no core impact whatsoever. - * -- wli + * -- nyc */ DEFINE_SPINLOCK(pgd_lock); struct page *pgd_list; diff --git a/arch/mn10300/mm/pgtable.c b/arch/mn10300/mm/pgtable.c index 4ebf117..bd9ada6 100644 --- a/arch/mn10300/mm/pgtable.c +++ b/arch/mn10300/mm/pgtable.c @@ -95,7 +95,7 @@ struct page *pte_alloc_one(struct mm_struct *mm, unsigned long address) * checks at dup_mmap(), exec(), and other mmlist addition points * could be used. The locking scheme was chosen on the basis of * manfred's recommendations and having no core impact whatsoever. - * -- wli + * -- nyc */ DEFINE_SPINLOCK(pgd_lock); struct page *pgd_list; diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 7353de3..e27fbf8 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -137,7 +137,7 @@ static void pgd_dtor(pgd_t *pgd) * against pageattr.c; it is the unique case in which a valid change * of kernel pagetables can't be lazily synchronized by vmalloc faults. * vmalloc faults work because attached pagetables are never freed. - * -- wli + * -- nyc */ #ifdef CONFIG_X86_PAE diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 4a55f35..78bde32 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1,7 +1,7 @@ /* * hugetlbpage-backed filesystem. Based on ramfs. * - * William Irwin, 2002 + * Nadia Yvette Chambers, 2002 * * Copyright (C) 2002 Linus Torvalds. */ diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c index be20a7e..63d14a9 100644 --- a/fs/ncpfs/mmap.c +++ b/fs/ncpfs/mmap.c @@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_area_struct *area, /* * If I understand ncp_read_kernel() properly, the above always * fetches from the network, here the analogue of disk. - * -- wli + * -- nyc */ count_vm_event(PGMAJFAULT); mem_cgroup_count_vm_event(area->vm_mm, PGMAJFAULT); diff --git a/include/linux/hash.h b/include/linux/hash.h index 24df9e7..61c97ae 100644 --- a/include/linux/hash.h +++ b/include/linux/hash.h @@ -1,7 +1,7 @@ #ifndef _LINUX_HASH_H #define _LINUX_HASH_H /* Fast hashing routine for ints, longs and pointers. - (C) 2002 William Lee Irwin III, IBM */ + (C) 2002 Nadia Yvette Chambers, IBM */ /* * Knuth recommends primes in approximately golden ratio to the maximum diff --git a/kernel/pid.c b/kernel/pid.c index e8750f9..36aa02f 100644 --- a/kernel/pid.c +++ b/kernel/pid.c @@ -1,8 +1,8 @@ /* * Generic pidhash and scalable, time-bounded PID allocator * - * (C) 2002-2003 William Irwin, IBM - * (C) 2004 William Irwin, Oracle + * (C) 2002-2003 Nadia Yvette Chambers, IBM + * (C) 2004 Nadia Yvette Chambers, Oracle * (C) 2002-2004 Ingo Molnar, Red Hat * * pid-structures are backing objects for tasks sharing a given ID to chain diff --git a/kernel/profile.c b/kernel/profile.c index 76b8e77..1f39181 100644 --- a/kernel/profile.c +++ b/kernel/profile.c @@ -8,9 +8,10 @@ * Scheduler profiling suppo
Re: Use PCI ROMs from EFI boot services
"H. Peter Anvin" wrote: >Because it also needs to modify it. Right now kexec userspace >synthesizes struct boot_params from scratch, and does so incorrectly to >boot. I think we have setup_data exported via debugfs but IIRC we >never >got a strong enough use case for sysfs. Kexec userspace needs updating every time we add functionality to setup_data? That really doesn't sound ideal. If we want to be able to pass secrets between kernels then this needs to be done in kernel space, not userland. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mmotm 2012-12-05-16-59 uploaded
The mm-of-the-moment snapshot 2012-12-05-16-59 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.7-rc8: (patches marked "*" will be included in linux-next) origin.patch * tmpfs-fix-shared-mempolicy-leak.patch linux-next.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * thp-fix-update_mmu_cache_pmd-calls.patch * cris-fix-i-o-macros.patch * lib-makefile-fix-oid_registry-build-dependency.patch * vfs-d_obtain_alias-needs-to-use-as-default-name.patch * fs-block_devc-page-cache-wrongly-left-invalidated-after-revalidate_disk.patch * arch-x86-platform-iris-irisc-register-a-platform-device-and-a-platform-driver.patch * x86-numa-dont-check-if-node-is-numa_no_node.patch * arch-x86-tools-insn_sanityc-identify-source-of-messages.patch * uv-fix-incorrect-tlb-flush-all-issue.patch * olpc-fix-olpc-xo1-scic-build-errors.patch * x86-convert-update_mmu_cache-and-update_mmu_cache_pmd-to-functions.patch * x86-fix-the-argument-passed-to-sync_global_pgds.patch * x86-make-mem=-option-to-work-for-efi-platform.patch * audit-create-explicit-audit_seccomp-event-type.patch * audit-catch-possible-null-audit-buffers.patch * ceph-fix-dentry-reference-leak-in-ceph_encode_fh.patch * cris-use-int-for-ssize_t-to-match-size_t.patch * pcmcia-move-unbind-rebind-into-dev_pm_opscomplete.patch * drivers-video-add-support-for-the-solomon-ssd1307-oled-controller.patch * drivers-video-add-support-for-the-solomon-ssd1307-oled-controller-checkpatch-fixes.patch * drivers-video-console-softcursorc-remove-redundant-null-check-before-kfree.patch cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch * irq-tsk-comm-is-an-array.patch * timeconstpl-remove-deprecated-defined-array.patch * time-dont-inline-export_symbol-functions.patch * coccinelle-add-api-d_find_aliascocci.patch * h8300-select-generic-atomic64_t-support.patch * mm-mempolicy-introduce-spinlock-to-read-shared-policy-tree.patch * drivers-message-fusion-mptscsihc-missing-break.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * block-remove-deadlock-in-disk_clear_events.patch * block-remove-deadlock-in-disk_clear_events-fix.patch * block-prevent-race-cleanup.patch * block-prevent-race-cleanup-fix.patch * vfs-increment-iversion-when-a-file-is-truncated.patch * fs-change-return-values-from-eacces-to-eperm.patch * fs-block_devc-need-not-to-check-inode-i_bdev-in-bd_forget.patch * watchdog-trigger-all-cpu-backtrace-when-locked-up-and-going-to-panic.patch * mm-slab-remove-duplicate-check.patch mm.patch * writeback-remove-nr_pages_dirtied-arg-from-balance_dirty_pages_ratelimited_nr.patch * mm-show-migration-types-in-show_mem.patch *
Re: Use PCI ROMs from EFI boot services
"H. Peter Anvin" wrote: >I don't think there is anything security-sensitive about that >information, at least not to root. I could be wrong, of course; I >wouldn't mind security people telling me about that. I don't think there's anything at present, but we'll want to pass the hibernation encryption key from the bootloader to the kernel in the near future. setup_data seems like the easiest way to do that. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Use PCI ROMs from EFI boot services
On 12/05/2012 04:51 PM, Yinghai Lu wrote: > > it moves boot_params from __initdata to data. > and just for using pointer to setup_data. > > should add setup_data pointer instead. so will not waste (4096 - 8) bytes. > That is not the only bit. We already have covered how kexec could use the whole structure, and really, how big a deal is a page of cache-cold storage? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v2 PATCH 2/8] watchdog/at91sam9_wdt: Convert to use the watchdog framework
Hi Florian,
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com] On Behalf Of Florian
> Fainelli
> Sent: 2012年12月5日 18:48
> To: Yang, Wenyou
> Cc: linux-arm-ker...@lists.infradead.org; Ferre, Nicolas;
> plagn...@jcrosoft.com; Lin,
> JM; w...@iguana.be; linux-watch...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [v2 PATCH 2/8] watchdog/at91sam9_wdt: Convert to use the watchdog
> framework
>
> Hello Wenyou,
>
> On Wednesday 05 December 2012 09:34:21 Wenyou Yang wrote:
> > According to the kernel document: convert_drivers_to_kernel_api.txt,
> > remove the file_operations struct, miscdevice, and obsolete includes
> >
> > Since the at91sam watchdog inherent characteristics, add the watchdog
> > operations: at91wdt_start, at91wdt_stop and at91wdt_ping.
> >
>
> [snip]
>
> >
> > +static inline bool watchdog_is_open(struct watchdog_device *wddev)
> > +{
> > + return test_bit(WDOG_DEV_OPEN, >status);
> > +}
>
> This helper should be moved to include/linux/watchdog.h as it can be useful
> for other watchdog drivers as well.
Thanks, I will move it in next version.
> --
> Florian
Best Regards
Wenyou Yang
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Use PCI ROMs from EFI boot services
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu wrote: > On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote: >> On 12/05/2012 04:15 PM, Yinghai Lu wrote: >>> >> >> I don't see why that isn't the right fix. We copy the data into >> boot_params early in the boot; that *is* the official copy as far as the >> kernel is concerned. >> >> So this patch very much seems like The Right Thing. > > it moves boot_params from __initdata to data. should be from __initdata to bss > and just for using pointer to setup_data. > > should add setup_data pointer instead. so will not waste (4096 - 8) bytes. > > Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Use PCI ROMs from EFI boot services
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote: > On 12/05/2012 04:15 PM, Yinghai Lu wrote: >> > > I don't see why that isn't the right fix. We copy the data into > boot_params early in the boot; that *is* the official copy as far as the > kernel is concerned. > > So this patch very much seems like The Right Thing. it moves boot_params from __initdata to data. and just for using pointer to setup_data. should add setup_data pointer instead. so will not waste (4096 - 8) bytes. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] Input: add driver for Cypress APA I2C Trackpad
This patch introduces a driver for Cypress All Points Addressable I2C Trackpad, including the ones in 2012 Samsung Chromebooks. This device is compatible with MT protocol type B, providing identifiable contacts. Signed-off-by: Dudley Du Signed-off-by: Daniel Kurtz Signed-off-by: Benson Leung --- Version history : v2 : * Removed firmware update. * Removed sysfs properties related to firmware update and power mode. * Folded cyapa_detect into cyapa_probe. * Added support for middle and right mechanical buttons, if they exist. * Rearranged disable_irq/enable_irq in suspend and resume to prevent a power mode change from colliding with a read of tracking data. * Made cyapa_get_state more reliable. * Use IRQF_ONESHOT for threaded irq * Simplified cyapa_set_power_mode. * Removed extra kernel-doc style comments * Removed dev_dbg messages. * Cleaned up unused includes. * Cleaned up unused #defines v1 : Initial --- drivers/input/mouse/Kconfig | 12 + drivers/input/mouse/Makefile |1 + drivers/input/mouse/cyapa.c | 838 ++ 3 files changed, 851 insertions(+), 0 deletions(-) create mode 100644 drivers/input/mouse/cyapa.c diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig index cd6268c..23db30a 100644 --- a/drivers/input/mouse/Kconfig +++ b/drivers/input/mouse/Kconfig @@ -193,6 +193,18 @@ config MOUSE_BCM5974 To compile this driver as a module, choose M here: the module will be called bcm5974. +config MOUSE_CYAPA + tristate "Cypress APA I2C Trackpad support" + depends on I2C + help + This driver adds support for Cypress All Points Addressable (APA) + I2C Trackpads, including the ones used in 2012 Samsung Chromebooks. + + Say Y here if you have a Cypress APA I2C Trackpad. + + To compile this driver as a module, choose M here: the module will be + called cyapa. + config MOUSE_INPORT tristate "InPort/MS/ATIXL busmouse" depends on ISA diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile index 46ba755..10b4773 100644 --- a/drivers/input/mouse/Makefile +++ b/drivers/input/mouse/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o obj-$(CONFIG_MOUSE_ATARI) += atarimouse.o obj-$(CONFIG_MOUSE_BCM5974)+= bcm5974.o +obj-$(CONFIG_MOUSE_CYAPA) += cyapa.o obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o obj-$(CONFIG_MOUSE_INPORT) += inport.o obj-$(CONFIG_MOUSE_LOGIBM) += logibm.o diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c new file mode 100644 index 000..08cf1ce --- /dev/null +++ b/drivers/input/mouse/cyapa.c @@ -0,0 +1,838 @@ +/* + * Cypress APA trackpad with I2C interface + * + * Author: Dudley Du + * Further cleanup and restructuring by: + * Daniel Kurtz + * Benson Leung + * + * Copyright (C) 2011-2012 Cypress Semiconductor, Inc. + * Copyright (C) 2011-2012 Google, Inc. + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file COPYING in the main directory of this archive for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include + +/* APA trackpad firmware generation */ +#define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */ + +#define CYAPA_NAME "Cypress APA Trackpad (cyapa)" + +/* commands for read/write registers of Cypress trackpad */ +#define CYAPA_CMD_SOFT_RESET 0x00 +#define CYAPA_CMD_POWER_MODE 0x01 +#define CYAPA_CMD_DEV_STATUS 0x02 +#define CYAPA_CMD_GROUP_DATA 0x03 +#define CYAPA_CMD_GROUP_CMD0x04 +#define CYAPA_CMD_GROUP_QUERY 0x05 +#define CYAPA_CMD_BL_STATUS0x06 +#define CYAPA_CMD_BL_HEAD 0x07 +#define CYAPA_CMD_BL_CMD 0x08 +#define CYAPA_CMD_BL_DATA 0x09 +#define CYAPA_CMD_BL_ALL 0x0a +#define CYAPA_CMD_BLK_PRODUCT_ID 0x0b +#define CYAPA_CMD_BLK_HEAD 0x0c + +/* report data start reg offset address. */ +#define DATA_REG_START_OFFSET 0x + +#define BL_HEAD_OFFSET 0x00 +#define BL_DATA_OFFSET 0x10 + +/* + * Operational Device Status Register + * + * bit 7: Valid interrupt source + * bit 6 - 4: Reserved + * bit 3 - 2: Power status + * bit 1 - 0: Device status + */ +#define REG_OP_STATUS 0x00 +#define OP_STATUS_SRC 0x80 +#define OP_STATUS_POWER 0x0c +#define OP_STATUS_DEV 0x03 +#define OP_STATUS_MASK (OP_STATUS_SRC | OP_STATUS_POWER | OP_STATUS_DEV) + +/* + * Operational Finger Count/Button Flags Register + * + * bit 7 - 4: Number of touched finger + * bit 3: Valid data + * bit 2: Middle Physical Button + * bit 1: Right Physical Button + * bit 0: Left physical Button + */ +#define REG_OP_DATA1 0x01 +#define OP_DATA_VALID 0x08 +#define
[PATCH v2 0/1] Input: add driver for Cypress APA I2C Trackpad
Thanks for the patience on this driver. I have stripped out firmware update, the sysfs properties around firmware version, hardware version, update_fw, and power state. I have incorporated rydberg's suggestions for cleanup. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] propagate name change to comments in kernel source
I've legally changed my name with New York State, the US Social Security Administration, et al. This patch propagates the name change and change in initials and login to comments in the kernel source as well. vs. next-20121205 Signed-off-by: Nadia Yvette Chambers diff --git a/MAINTAINERS b/MAINTAINERS index 26c7b01..b3055a2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3659,7 +3659,7 @@ S: Maintained F: drivers/input/touchscreen/htcpen.c HUGETLB FILESYSTEM -M: William Irwin +M: Nadia Yvette Chambers S: Maintained F: fs/hugetlbfs/ diff --git a/arch/alpha/include/asm/mmzone.h b/arch/alpha/include/asm/mmzone.h index 445dc42..c5b5d6b 100644 --- a/arch/alpha/include/asm/mmzone.h +++ b/arch/alpha/include/asm/mmzone.h @@ -66,7 +66,7 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p, int n) ((unsigned long)__va(NODE_DATA(kvaddr_to_nid(kaddr))->node_start_pfn \ << PAGE_SHIFT)) -/* XXX: FIXME -- wli */ +/* XXX: FIXME -- nyc */ #define kern_addr_valid(kaddr) (0) #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT) diff --git a/arch/frv/mm/pgalloc.c b/arch/frv/mm/pgalloc.c index 4fb63a3..f6084bc 100644 --- a/arch/frv/mm/pgalloc.c +++ b/arch/frv/mm/pgalloc.c @@ -77,7 +77,7 @@ void __set_pmd(pmd_t *pmdptr, unsigned long pmd) * checks at dup_mmap(), exec(), and other mmlist addition points * could be used. The locking scheme was chosen on the basis of * manfred's recommendations and having no core impact whatsoever. - * -- wli + * -- nyc */ DEFINE_SPINLOCK(pgd_lock); struct page *pgd_list; diff --git a/arch/mn10300/mm/pgtable.c b/arch/mn10300/mm/pgtable.c index 4ebf117..bd9ada6 100644 --- a/arch/mn10300/mm/pgtable.c +++ b/arch/mn10300/mm/pgtable.c @@ -95,7 +95,7 @@ struct page *pte_alloc_one(struct mm_struct *mm, unsigned long address) * checks at dup_mmap(), exec(), and other mmlist addition points * could be used. The locking scheme was chosen on the basis of * manfred's recommendations and having no core impact whatsoever. - * -- wli + * -- nyc */ DEFINE_SPINLOCK(pgd_lock); struct page *pgd_list; diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 7353de3..e27fbf8 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -137,7 +137,7 @@ static void pgd_dtor(pgd_t *pgd) * against pageattr.c; it is the unique case in which a valid change * of kernel pagetables can't be lazily synchronized by vmalloc faults. * vmalloc faults work because attached pagetables are never freed. - * -- wli + * -- nyc */ #ifdef CONFIG_X86_PAE diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 4a55f35..78bde32 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1,7 +1,7 @@ /* * hugetlbpage-backed filesystem. Based on ramfs. * - * William Irwin, 2002 + * Nadia Yvette Chambers, 2002 * * Copyright (C) 2002 Linus Torvalds. */ diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c index be20a7e..63d14a9 100644 --- a/fs/ncpfs/mmap.c +++ b/fs/ncpfs/mmap.c @@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_area_struct *area, /* * If I understand ncp_read_kernel() properly, the above always * fetches from the network, here the analogue of disk. - * -- wli + * -- nyc */ count_vm_event(PGMAJFAULT); mem_cgroup_count_vm_event(area->vm_mm, PGMAJFAULT); diff --git a/include/linux/hash.h b/include/linux/hash.h index 24df9e7..61c97ae 100644 --- a/include/linux/hash.h +++ b/include/linux/hash.h @@ -1,7 +1,7 @@ #ifndef _LINUX_HASH_H #define _LINUX_HASH_H /* Fast hashing routine for ints, longs and pointers. - (C) 2002 William Lee Irwin III, IBM */ + (C) 2002 Nadia Yvette Chambers, IBM */ /* * Knuth recommends primes in approximately golden ratio to the maximum diff --git a/kernel/pid.c b/kernel/pid.c index e8750f9..36aa02f 100644 --- a/kernel/pid.c +++ b/kernel/pid.c @@ -1,8 +1,8 @@ /* * Generic pidhash and scalable, time-bounded PID allocator * - * (C) 2002-2003 William Irwin, IBM - * (C) 2004 William Irwin, Oracle + * (C) 2002-2003 Nadia Yvette Chambers, IBM + * (C) 2004 Nadia Yvette Chambers, Oracle * (C) 2002-2004 Ingo Molnar, Red Hat * * pid-structures are backing objects for tasks sharing a given ID to chain diff --git a/kernel/profile.c b/kernel/profile.c index 76b8e77..1f39181 100644 --- a/kernel/profile.c +++ b/kernel/profile.c @@ -8,9 +8,10 @@ * Scheduler profiling support, Arjan van de Ven and Ingo Molnar, * Red Hat, July 2004 * Consolidation of architecture support code for profiling, - * William Irwin, Oracle, July 2004 + * Nadia Yvette Chambers, Oracle, July 2004 * Amortized hit count accounting via per-cpu open-addressed hashtables - * to resolve timer interrupt livelocks, William Irwin, Oracle, 2004 + * to resolve timer interrupt livelocks, Nadia Yvette Chambers, + * Oracle, 2004 */ #include @@ -256,7 +257,7 @@ EXPORT_SYMBOL_GPL(unregister_timer_hook); * pagetable hash functions, but uses a full hashtable full of finite * collision chai
Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI
On Wed, Dec 05, 2012 at 12:34:15PM -0500, Theodore Ts'o wrote: > Because it's the on-disk encoding, when btrfs uses extra bits for its > btrfs-specific inode flags, it means that I need to avoid using those > bits in ext4, if it's a flag that needs to also be exposed via > chattr/lsattr. What, you mean the ones they posted to -fsdevel for peer review? http://marc.info/?t=12991413301=1=2 > P.S. The main reason why it would have been better for btrfs > developers to have consulted me is that they also depend on > lsattr/chattr, and those programs are part of e2fsprogs. They did consult you directly, Ted. Here's the header from V2 of the patch indicating that you are directly cc'd: Message-ID: <4d871243.2060...@cn.fujitsu.com> Date: Mon, 21 Mar 2011 16:54:27 +0800 From: liubo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Linux Btrfs CC: linux-fsdevel , Andreas Dilger , Christoph Hellwig , tytso , Chris Mason Subject: [PATCH 1/2 v2] Btrfs: add datacow flag in inode flag Apples and oranges, Ted. You didn't post your change anywhere, unlike the btrfs guys who did the right thing. Please stop trying to blame someone else for your actions. > That being said, you'll note that unlike Dave, I have > **not** thrown a hissy fit when btrfs grabbed bits from the inode > field, even though quite a bit more bits allocated for the inode flags > than the fallocate flags. IOWs, pointing out that the standard peer review process has been bypassed is "throwing a hissy fit"? And Linus calls it "being a pissy bitch". To me this is acknoweldgement of the fact that something wrong was done, but the actors can't bring themselves to directly admit it and so are resorting to name calling and blame-shifting to discredit the messenger and therefore the message. Or perhaps Linus has given us the go-ahead to push random unreviewed syscall changes through subsystem trees after holding private discussions between a handful of developers like has happened here. Cheers. Dave. -- Dave Chinner da...@fromorbit.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: [PATCH 000/493] remove CONFIG_HOTPLUG as an option
On Thu, Dec 06, 2012 at 12:27:42AM +, Grant Likely wrote:
> On Wed, 21 Nov 2012 20:07:23 -0500, wf...@viridian.itc.virginia.edu (Bill
> Pemberton) wrote:
> > Grant Likely writes:
> > >
> > > You mean this series wasn't created with a script? You did this by
> > > hand? If so then I must say kudos on your dedication!
> > >
> > > But it makes me more nervous about the series. Too easy to fat
> > > finger many things when touching that many files.
> > >
> >
> > No, I didn't do them by hand, it was a script. Originally, it was a
> > couple, all basically the same, but removing each __dev*. Then I'd do
> > a word diff to eyeball them to make sure the script didn't do
> > something goofy.
> >
> > The whack-a-mole part came along because I was working against
> > linux-next and whatever patch series was right for one day wouldn't be
> > right for the next day because of some of the faster moving trees.
> >
> >
> > > Please do write a script and post that for review.
> > >
> >
> > The all-in-one version of the script:
> >
> > #! /usr/bin/perl
> >
> > use strict;
> > use IO::InSitu;
> >
> > sub processfile
> > {
> > my $fn = shift;
> >
> > my ($in, $out) = open_rw($fn, $fn);
> >
> > while (<$in>) {
> > s|__devexit_p\(([^)]+)\)|$1|;
> > s|\s__devexit\b||;
> > s|\s__devinitconst\b||;
> > s|\s__devinitdata\b||;
> > s|\s__devinit\b||;
>
> Pretty straight forward, and works against the files I tried. :-)
>
> Greg, I'd much rather see the change applied all at once in this manner.
> If that isn't possible, then at the least I'll use the script against
> the code that I maintain and push th result out to Linus.
Given that there are a lot of patches already in linux-next from Bill
due to this work, I'm not going to do this for all files right now,
sorry.
But, if you want to use this for the files you maintain and push that
out for 3.8-rc1, that would be great. I'll be walking the tree after
3.8-rc1 is out to catch the stragglers with a script like this.
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: Use PCI ROMs from EFI boot services
On 12/05/2012 04:30 PM, Yinghai Lu wrote: > On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin wrote: >> On 12/05/2012 04:18 PM, Matthew Garrett wrote: > >> Because it also needs to modify it. Right now kexec userspace >> synthesizes struct boot_params from scratch, and does so incorrectly to >> boot. I think we have setup_data exported via debugfs but IIRC we never >> got a strong enough use case for sysfs. > > maybe we could try to export setup_data pointer only /sys, and that > could be safe enough. > I don't think there is anything security-sensitive about that information, at least not to root. I could be wrong, of course; I wouldn't mind security people telling me about that. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Use PCI ROMs from EFI boot services
On 12/05/2012 04:15 PM, Yinghai Lu wrote: > > -#ifndef CONFIG_DEBUG_BOOT_PARAMS > -struct boot_params __initdata boot_params; > -#else > struct boot_params boot_params; > -#endif > > No, that is not a right fix > > We should only cache pointer to setup_data. > > at the same time we should export setup_data into /sys, so kexec could > append this pointer to command of > second kernel, just like kexec append acpi_rsdp. > That should address DavidW's concern. > I don't see why that isn't the right fix. We copy the data into boot_params early in the boot; that *is* the official copy as far as the kernel is concerned. So this patch very much seems like The Right Thing. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Use PCI ROMs from EFI boot services
On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin wrote: > On 12/05/2012 04:18 PM, Matthew Garrett wrote: > Because it also needs to modify it. Right now kexec userspace > synthesizes struct boot_params from scratch, and does so incorrectly to > boot. I think we have setup_data exported via debugfs but IIRC we never > got a strong enough use case for sysfs. maybe we could try to export setup_data pointer only /sys, and that could be safe enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
>OK, so the ENOMEM seems to be leaking from mem_cgroup_newpage_charge. >This can only happen if this was an atomic allocation request >(!__GFP_WAIT) or if oom is not allowed which is the case only for >transparent huge page allocation. >The first case can be excluded (in the clean 3.2 stable kernel) because >all callers of mem_cgroup_newpage_charge use GFP_KERNEL. The later one >should be OK because the page fault should fallback to a regular page if >THP allocation/charge fails. >[/me goes to double check] >Hmm do_huge_pmd_wp_page seems to charge a huge page and fails with >VM_FAULT_OOM without any fallback. We should do_huge_pmd_wp_page_fallback >instead. This has been fixed in 3.5-rc1 by 1f1d06c3 (thp, memcg: split >hugepage for memcg oom on cow) but it hasn't been backported to 3.2. The >patch applies to 3.2 without any further modifications. I didn't have >time to test it but if it helps you we should push this to the stable >tree. This, unfortunately, didn't fix the problem :( http://www.watchdog.sk/lkml/oom_mysqld3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 000/493] remove CONFIG_HOTPLUG as an option
On Wed, 21 Nov 2012 20:07:23 -0500, wf...@viridian.itc.virginia.edu (Bill
Pemberton) wrote:
> Grant Likely writes:
> >
> > You mean this series wasn't created with a script? You did this by
> > hand? If so then I must say kudos on your dedication!
> >
> > But it makes me more nervous about the series. Too easy to fat
> > finger many things when touching that many files.
> >
>
> No, I didn't do them by hand, it was a script. Originally, it was a
> couple, all basically the same, but removing each __dev*. Then I'd do
> a word diff to eyeball them to make sure the script didn't do
> something goofy.
>
> The whack-a-mole part came along because I was working against
> linux-next and whatever patch series was right for one day wouldn't be
> right for the next day because of some of the faster moving trees.
>
>
> > Please do write a script and post that for review.
> >
>
> The all-in-one version of the script:
>
> #! /usr/bin/perl
>
> use strict;
> use IO::InSitu;
>
> sub processfile
> {
> my $fn = shift;
>
> my ($in, $out) = open_rw($fn, $fn);
>
> while (<$in>) {
> s|__devexit_p\(([^)]+)\)|$1|;
> s|\s__devexit\b||;
> s|\s__devinitconst\b||;
> s|\s__devinitdata\b||;
> s|\s__devinit\b||;
Pretty straight forward, and works against the files I tried. :-)
Greg, I'd much rather see the change applied all at once in this manner.
If that isn't possible, then at the least I'll use the script against
the code that I maintain and push th result out to Linus.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
