[patch v4] x86, UV: integer wrap bug in uv_hub_ipi_value()

[Dan Carpenter]

This is a static checker fix.  The problem is that we store the bits
from "uv_apicid_hibits" into "apicid" (the high 16 bits) but then we
shift it 16 bit to the left.  "apicid" is an int so it wraps and we lose
them.

I have also simplified uv_wakeup_secondary() a little based on a
suggestion from Walter Harms.

Signed-off-by: Dan Carpenter 
---
v2: Style fix.  Don't use ulong.
v3: Another style fix to uv_wakeup_secondary() based on Walter Harms's
suggestion.
v4: Fix typo in commit message.

I don't have this hardware so I can't test it.  There may also be other
bugs which this patch does not addressed.  These files are only compiled
on x86_64 and "unsigned long" is used throughout to mean 64 bits.

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 21f7385..e7a83d5 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -577,7 +577,7 @@ static unsigned long uv_hub_ipi_value(int apicid, int 
vector, int mode)
 {
apicid |= uv_apicid_hibits;
return (1UL << UVH_IPI_INT_SEND_SHFT) |
-   ((apicid) << UVH_IPI_INT_APIC_ID_SHFT) |
+   ((unsigned long)apicid << UVH_IPI_INT_APIC_ID_SHFT) |
(mode << UVH_IPI_INT_DELIVERY_MODE_SHFT) |
(vector << UVH_IPI_INT_VECTOR_SHFT);
 }
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 8cfade9..251b36f 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -194,16 +194,10 @@ static int __cpuinit uv_wakeup_secondary(int phys_apicid, 
unsigned long start_ri
pnode = uv_apicid_to_pnode(phys_apicid);
phys_apicid |= uv_apicid_hibits;
val = (1UL << UVH_IPI_INT_SEND_SHFT) |
-   (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
-   ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
-   APIC_DM_INIT;
-   uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
-
-   val = (1UL << UVH_IPI_INT_SEND_SHFT) |
-   (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
-   ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12) |
-   APIC_DM_STARTUP;
-   uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
+   ((unsigned long)phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
+   ((start_rip << UVH_IPI_INT_VECTOR_SHFT) >> 12);
+   uv_write_global_mmr64(pnode, UVH_IPI_INT, val | APIC_DM_INIT);
+   uv_write_global_mmr64(pnode, UVH_IPI_INT, val | APIC_DM_STARTUP);
 
atomic_set(_deasserted, 1);
 #endif

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

Re: [PATCH v2 1/2] zsmalloc: add function to query object size

[Minchan Kim]

On Sun, Dec 02, 2012 at 11:20:42PM -0800, Nitin Gupta wrote:
> 
> 
> On Nov 30, 2012, at 5:54 AM, Minchan Kim  wrote:
> 
> > On Thu, Nov 29, 2012 at 10:54:48PM -0800, Nitin Gupta wrote:
> >> Changelog v2 vs v1:
> >> - None
> >> 
> >> Adds zs_get_object_size(handle) which provides the size of
> >> the given object. This is useful since the user (zram etc.)
> >> now do not have to maintain object sizes separately, saving
> >> on some metadata size (4b per page).
> >> 
> >> The object handle encodes  pair which currently points
> >> to the start of the object. Now, the handle implicitly stores the size
> >> information by pointing to the object's end instead. Since zsmalloc is
> >> a slab based allocator, the start of the object can be easily determined
> >> and the difference between the end offset encoded in the handle and the
> >> start gives us the object size.
> >> 
> >> Signed-off-by: Nitin Gupta 
> > Acked-by: Minchan Kim 
> > 
> > I already had a few comment in your previous versoin.
> > I'm OK although you ignore them because I can make follow up patch about
> > my nitpick but could you answer below my question?
> > 
> >> ---
> >> drivers/staging/zsmalloc/zsmalloc-main.c |  177 
> >> +-
> >> drivers/staging/zsmalloc/zsmalloc.h  |1 +
> >> 2 files changed, 127 insertions(+), 51 deletions(-)
> >> 
> >> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
> >> b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> index 09a9d35..65c9d3b 100644
> >> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> @@ -112,20 +112,20 @@
> >> #define MAX_PHYSMEM_BITS 36
> >> #else /* !CONFIG_HIGHMEM64G */
> >> /*
> >> - * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will 
> >> just
> >> + * If this definition of MAX_PHYSMEM_BITS is used, OFFSET_BITS will just
> >>  * be PAGE_SHIFT
> >>  */
> >> #define MAX_PHYSMEM_BITS BITS_PER_LONG
> >> #endif
> >> #endif
> >> #define _PFN_BITS(MAX_PHYSMEM_BITS - PAGE_SHIFT)
> >> -#define OBJ_INDEX_BITS(BITS_PER_LONG - _PFN_BITS)
> >> -#define OBJ_INDEX_MASK((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
> >> +#define OFFSET_BITS(BITS_PER_LONG - _PFN_BITS)
> >> +#define OFFSET_MASK((_AC(1, UL) << OFFSET_BITS) - 1)
> >> 
> >> #define MAX(a, b) ((a) >= (b) ? (a) : (b))
> >> /* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
> >> #define ZS_MIN_ALLOC_SIZE \
> >> -MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
> >> +MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OFFSET_BITS))
> >> #define ZS_MAX_ALLOC_SIZEPAGE_SIZE
> >> 
> >> /*
> >> @@ -256,6 +256,11 @@ static int is_last_page(struct page *page)
> >>return PagePrivate2(page);
> >> }
> >> 
> >> +static unsigned long get_page_index(struct page *page)
> >> +{
> >> +return is_first_page(page) ? 0 : page->index;
> >> +}
> >> +
> >> static void get_zspage_mapping(struct page *page, unsigned int *class_idx,
> >>enum fullness_group *fullness)
> >> {
> >> @@ -433,39 +438,86 @@ static struct page *get_next_page(struct page *page)
> >>return next;
> >> }
> >> 
> >> -/* Encode  as a single handle value */
> >> -static void *obj_location_to_handle(struct page *page, unsigned long 
> >> obj_idx)
> >> +static struct page *get_prev_page(struct page *page)
> >> {
> >> -unsigned long handle;
> >> +struct page *prev, *first_page;
> >> 
> >> -if (!page) {
> >> -BUG_ON(obj_idx);
> >> -return NULL;
> >> -}
> >> +first_page = get_first_page(page);
> >> +if (page == first_page)
> >> +prev = NULL;
> >> +else if (page == (struct page *)first_page->private)
> >> +prev = first_page;
> >> +else
> >> +prev = list_entry(page->lru.prev, struct page, lru);
> >> 
> >> -handle = page_to_pfn(page) << OBJ_INDEX_BITS;
> >> -handle |= (obj_idx & OBJ_INDEX_MASK);
> >> +return prev;
> >> 
> >> -return (void *)handle;
> >> }
> >> 
> >> -/* Decode  pair from the given object handle */
> >> -static void obj_handle_to_location(unsigned long handle, struct page 
> >> **page,
> >> -unsigned long *obj_idx)
> >> +static void *encode_ptr(struct page *page, unsigned long offset)
> >> {
> >> -*page = pfn_to_page(handle >> OBJ_INDEX_BITS);
> >> -*obj_idx = handle & OBJ_INDEX_MASK;
> >> +unsigned long ptr;
> >> +ptr = page_to_pfn(page) << OFFSET_BITS;
> >> +ptr |= offset & OFFSET_MASK;
> >> +return (void *)ptr;
> >> +}
> >> +
> >> +static void decode_ptr(unsigned long ptr, struct page **page,
> >> +unsigned int *offset)
> >> +{
> >> +*page = pfn_to_page(ptr >> OFFSET_BITS);
> >> +*offset = ptr & OFFSET_MASK;
> >> +}
> >> +
> >> +static struct page *obj_handle_to_page(unsigned long handle)
> >> +{
> >> +struct page *page;
> >> +unsigned int offset;
> >> +
> >> +decode_ptr(handle, , );
> >> +if (offset < get_page_index(page))
> >> +page = 

Re: [PATCH] uio.c: Fix warning: 'ret' might be used uninitialized

[Hans J. Koch]

On Sat, Dec 01, 2012 at 09:58:32AM +, Cong Ding wrote:
> If it is really necessary to save the 4 lines of codes, I would suggest to do 
> in the following style. But you are more senior than me, so I may be wrong in 
> this aspect. 

"Seniority" (whatever you mean by that) has got nothing to do with it.
I'll accept any child's patch if it is good. Discussing code on LKML is
a purely technically thing, only if two patches are technically equivalent,
the maintainer's personal taste will decide. And if it makes you feel better:
My patches (and those of any other developer) are also sometimes rejected
because they are not to some other maintainer's taste.

Thanks,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Cypress PS/2 Trackpad driver

[Henrik Rydberg]

Hi Kamal,

>   Patch #2 (main driver), as recommended by Henrik Rydberg[2]:
>   - use input_mt_assign_slots; drop cypress_cal_finger_id.
>   - enable 2-finger-only SEMI_MT; drop cypress_simulate_fingers.
>   - various code clean-ups.
> 
>   Henrik, does patch #2 appear to properly use assign_slots and SEMI_MT as
>   you intended?  This SEMI_MT method does work (with 2 finger support only),
>   but I'm not clear why we wouldn't want to handle >2 fingers also, so ...

It looks pretty good, please see the patch comments for details. As
Dmitry said, one can report the number of fingers separately from the
two guiding contacts, and this semi-mt behavior is well supported in
userspace.

> 
>   Patch #4 (new) reintroduces simulated multitouch for up to 5 fingers
>   (#if CYPRESS_SIMULATE_MT), disabling SEMI_MT again.
> 
>   If that functionality (support for >2 fingers) can be acheived in some
>   better way, please advise.

Yes, as above, so this patch will not be needed.

Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] input: Cypress PS/2 Trackpad psmouse driver

[Henrik Rydberg]

Hi Kamal,

> From: Cypress Semiconductor Corporation 
> 
> Input/mouse driver for Cypress PS/2 Trackpad.
> 
> Original code contributed by Cypress Semiconductor Corporation,
> modified by Kamal Mostafa and Kyle Fazzari.
> 
> BugLink: http://launchpad.net/bugs/978807
> 
> Signed-off-by: Kamal Mostafa 
> Signed-off-by: Kyle Fazzari 
> Signed-off-by: Mario Limonciello 
> Signed-off-by: Tim Gardner 
> Acked-by: Herton Krzesinski 
> ---
>  drivers/input/mouse/cypress_ps2.c |  830 
> +
>  drivers/input/mouse/cypress_ps2.h |  219 ++
>  2 files changed, 1049 insertions(+)
>  create mode 100644 drivers/input/mouse/cypress_ps2.c
>  create mode 100644 drivers/input/mouse/cypress_ps2.h

Thanks for the patch, it seems to improve nicely. Please find comments inline.

> 
> diff --git a/drivers/input/mouse/cypress_ps2.c 
> b/drivers/input/mouse/cypress_ps2.c
> new file mode 100644
> index 000..472342a
> --- /dev/null
> +++ b/drivers/input/mouse/cypress_ps2.c
> @@ -0,0 +1,830 @@
> +/*
> + * Cypress Trackpad PS/2 mouse driver
> + *
> + * Copyright (c) 2012 Cypress Semiconductor Corporation.
> + *
> + * Additional contributors include:
> + *   Kamal Mostafa 
> + *   Kyle Fazzari 
> + *
> + * 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 "cypress_ps2.h"
> +
> +#define CYTP_DBG_DUMP 0  /* set to 1 for more verbose debug dump 
> */
> +
> +#define cytp_dbg(fmt, ...)  \
> + do {  \
> + if (cytp)  \
> + psmouse_dbg(psmouse, pr_fmt(fmt), ##__VA_ARGS__);  \
> + } while (0)

Where is cytp defined?

> +
> +#if CYTP_DBG_DUMP
> +# define cytp_dbg_dump cytp_dbg
> +#else
> +# define cytp_dbg_dump(fmt, ...)
> +#endif
> +
> +
> +/* p is a pointer points to the buffer containing Cypress Keys. */
> +#define IS_CYPRESS_KEY(p) ((p[0] == CYPRESS_KEY_1) && (p[1] == 
> CYPRESS_KEY_2))

If you use a function instead, you do not need to explain the type.

> +#define CYTP_SET_PACKET_SIZE(n) { psmouse->pktsize = cytp->pkt_size = (n); }

More magic cytp argument stuff, please reformulate this.

> +#define CYTP_SET_MODE_BIT(x)  \
> + do {  \
> + if ((x) & CYTP_BIT_ABS_REL_MASK)  \
> + cytp->mode = (cytp->mode & ~CYTP_BIT_ABS_REL_MASK);  \
> + cytp->mode |= (x);  \
> + } while (0)

Given the generic name, this function does something completely
unexpected. Also, branching on bit manipulations seems odd.

> +#define CYTP_CLEAR_MODE_BIT(x)   { cytp->mode &= ~(x); }

Seems unnecessary to define here for a single instance in the code.

> +
> +#define CYTP_SUPPORT_ABS

Stale code?

> +
> +static unsigned char cytp_rate[] = {10, 20, 40, 60, 100, 200};
> +static unsigned char cytp_resolution[] = {0x00, 0x01, 0x02, 0x03};

const, please.

> +
> +static int cypress_ps2_sendbyte(struct psmouse *psmouse, int value)
> +{
> + struct cytp_data *cytp = psmouse->private;
> + struct ps2dev *ps2dev = >ps2dev;
> +
> + if (ps2_sendbyte(ps2dev, value & 0xff, CYTP_CMD_TIMEOUT) < 0) {
> + cytp_dbg("send command 0x%02x failed, resp 0x%02x\n",
> +  value & 0xff, ps2dev->nak);
> + if (ps2dev->nak == CYTP_PS2_RETRY)
> + return CYTP_PS2_RETRY;
> + else
> + return CYTP_PS2_ERROR;
> + }
> +
> + cytp_dbg("send command 0x%02x success, resp 0xfa\n", value & 0xff);
> +
> + return 0;
> +}
> +
> +static int cypress_ps2_ext_cmd(struct psmouse *psmouse, unsigned short cmd,
> +unsigned char data)
> +{
> + struct ps2dev *ps2dev = >ps2dev;
> + int tries = CYTP_PS2_CMD_TRIES;
> + int rc;
> +
> + ps2_begin_command(ps2dev);
> +
> + do {
> + /*
> +  * send extension command 0xE8 or 0xF3,
> +  * if send extension command failed,
> +  * try to send recovery command to make
> +  * trackpad device return to ready wait command state.
> +  * It alwasy success based on this recovery commands.

-EPARSE

> +  */
> + rc = cypress_ps2_sendbyte(psmouse, cmd & 0xff);
> + if (rc == CYTP_PS2_RETRY) {
> + rc = cypress_ps2_sendbyte(psmouse, 0x00);
> + if (rc == CYTP_PS2_RETRY)
> + rc = cypress_ps2_sendbyte(psmouse, 0x0a);
> + }
> + if (rc == CYTP_PS2_ERROR)
> + continue;
> +
> + rc = cypress_ps2_sendbyte(psmouse, data);
> + if (rc == CYTP_PS2_RETRY)
> + rc = cypress_ps2_sendbyte(psmouse, data);
> + if (rc == CYTP_PS2_ERROR)
> + 

Re: [PATCH v2 0/1] Input: xpad - Implement wireless controller LED setting and fix connect time LED setting

[Dmitry Torokhov]

On Fri, Nov 30, 2012 at 08:13:29PM -0800, Chris Moeller wrote:
> On Fri, 30 Nov 2012 14:30:23 -0800
> Dmitry Torokhov  wrote:
> 
> > Hi Chris,
> > 
> > On Friday, November 30, 2012 01:54:06 PM Chris Moeller wrote:
> > > I've submitted versions of this with prior patch sets, and this part
> > > was never accepted, possibly because it depended on other patches to
> > > work, or possibly because it wasn't so cleanly organized. This time,
> > > I've split the LED setting command off into its own static function,
> > > then call that on controller connect and optionally on LED setting
> > > commands. The static function does not include any locking, because
> > > locking inside the function which receives the incoming packets
> > > deadlocks the driver, and does not appear to be necessary anyway.
> > > 
> > > It also removes all traces of the original bulk out function which
> > > was designed for the purpose of setting the LED status on connect,
> > > as I found that it actually does not work at all. It appears to try
> > > to send the data, but nothing actually happens to the controller
> > > LEDs.
> > 
> > Attached is a reply I sent to on 7/4/11 to which you unfortunately
> > never responded. The issue is that of force feedback (rumble) and LED
> > share the same URB then access to that URB should be arbitrated. The
> > attached message contains a patch that attempts to implement that
> > arbitration, could you please try it out and see what changes are
> > needed to make it work?
> > 
> > Thanks.
> > 
> 
> So sorry I missed your reply. That's what I get for filtering the
> mailing list messages past my inbox, then never following up on my
> filter/folder set for replies to my own messages. I recall you
> mentioned that potential race condition when I first submitted, but I
> forgot to do anything about it. I'm glad at least one of us has our
> stuff together. It seems to work just fine, but there may be a force
> feedback issue with the following test program, where it leaves the
> effect playing indefinitely after the program terminates, and then the
> controller itself ceases to respond until the module is removed and
> reloaded.

Just to confirm, you see this problem only with the patch being
discussed and do not see it without it, right?

-- 
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] stable: uio: Fix warning: 'ret' might be used uninitialized

[Hans J. Koch]

In two cases, the return value variable "ret" can be undefined.

Signed-off-by: Hans J. Koch 
Reported-by: Vitalii Demianets 

---
 drivers/uio/uio.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5110f36..0c80df2 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -273,6 +273,7 @@ static int uio_dev_add_attributes(struct uio_device *idev)
struct uio_portio *portio;
 
for (mi = 0; mi < MAX_UIO_MAPS; mi++) {
+   ret = -ENOMEM;
mem = >info->mem[mi];
if (mem->size == 0)
break;
@@ -298,6 +299,7 @@ static int uio_dev_add_attributes(struct uio_device *idev)
}
 
for (pi = 0; pi < MAX_UIO_PORT_REGIONS; pi++) {
+   ret = -ENOMEM;
port = >info->port[pi];
if (port->size == 0)
break;
-- 
1.7.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Cypress PS/2 Trackpad driver

[Dmitry Torokhov]

Hi Kamal,

On Thu, Nov 29, 2012 at 01:57:57PM -0800, Kamal Mostafa wrote:
> This driver, submitted on behalf of Cypress Semiconductor Corporation and
> additional contributors, provides support for the Cypress PS/2 Trackpad.
> 
> This [PATCH v3] version differs from my previous submitted version[1]:
> 
>   Patch #1 (cmdbuf to 8 bytes) and #3 (link in driver) are unchanged.
> 
>   Patch #2 (main driver), as recommended by Henrik Rydberg[2]:
>   - use input_mt_assign_slots; drop cypress_cal_finger_id.
>   - enable 2-finger-only SEMI_MT; drop cypress_simulate_fingers.
>   - various code clean-ups.
> 
>   Henrik, does patch #2 appear to properly use assign_slots and SEMI_MT as
>   you intended?  This SEMI_MT method does work (with 2 finger support only),
>   but I'm not clear why we wouldn't want to handle >2 fingers also, so ...
> 
>   Patch #4 (new) reintroduces simulated multitouch for up to 5 fingers
>   (#if CYPRESS_SIMULATE_MT), disabling SEMI_MT again.
> 
>   If that functionality (support for >2 fingers) can be acheived in some
>   better way, please advise.

You can still report true number of fingers on the pad via BTN_TOOL_*TAP
while reporting the bounding box, the same way as Synaptics, Elantech,
ALPS and Sentelic drivers are doing it.

Thanks.

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

[PATCH] merge_config.sh: Add option to specify output dir

[Zhangfei Gao]

Provide a -O option to specify dir to put generated .config
Then merge_config.sh does not need to be copied to target dir,
for easy re-usage in other script

Signed-off-by: Zhangfei Gao 
Tested-by: Jon Medhurst (Tixy) 
---
 scripts/kconfig/merge_config.sh |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
index 974d5cb..05274fc 100755
--- a/scripts/kconfig/merge_config.sh
+++ b/scripts/kconfig/merge_config.sh
@@ -32,11 +32,13 @@ usage() {
echo "  -monly merge the fragments, do not execute the make command"
echo "  -nuse allnoconfig instead of alldefconfig"
echo "  -rlist redundant entries when merging fragments"
+   echo "  -Odir to put generated output files"
 }
 
 MAKE=true
 ALLTARGET=alldefconfig
 WARNREDUN=false
+OUTPUT=.
 
 while true; do
case $1 in
@@ -59,6 +61,16 @@ while true; do
shift
continue
;;
+   "-O")
+   if [ -d $2 ];then
+   OUTPUT=$(echo $2 | sed 's/\/*$//')
+   else
+   echo "output directory $2 does not exist" 1>&2
+   exit 1
+   fi
+   shift 2
+   continue
+   ;;
*)
break
;;
@@ -100,9 +112,9 @@ for MERGE_FILE in $MERGE_LIST ; do
 done
 
 if [ "$MAKE" = "false" ]; then
-   cp $TMP_FILE .config
+   cp $TMP_FILE $OUTPUT/.config
echo "#"
-   echo "# merged configuration written to .config (needs make)"
+   echo "# merged configuration written to $OUTPUT/.config (needs make)"
echo "#"
clean_up
exit
@@ -111,14 +123,14 @@ fi
 # Use the merged file as the starting point for:
 # alldefconfig: Fills in any missing symbols with Kconfig default
 # allnoconfig: Fills in any missing symbols with # CONFIG_* is not set
-make KCONFIG_ALLCONFIG=$TMP_FILE $ALLTARGET
+make KCONFIG_ALLCONFIG=$TMP_FILE O=$OUTPUT $ALLTARGET
 
 
 # Check all specified config values took (might have missed-dependency issues)
 for CFG in $(sed -n "$SED_CONFIG_EXP" $TMP_FILE); do
 
REQUESTED_VAL=$(grep -w -e "$CFG" $TMP_FILE)
-   ACTUAL_VAL=$(grep -w -e "$CFG" .config)
+   ACTUAL_VAL=$(grep -w -e "$CFG" $OUTPUT/.config)
if [ "x$REQUESTED_VAL" != "x$ACTUAL_VAL" ] ; then
echo "Value requested for $CFG not in final .config"
echo "Requested value:  $REQUESTED_VAL"
-- 
1.7.9.5

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

Re: [RFC PATCH] staging, android, ashmem: invalidate pin/unpin ioctl for private map

[Dan Carpenter]

On Mon, Dec 03, 2012 at 09:09:59AM +0900, JoonSoo Kim wrote:
> Hello, Dan.
> 
> 2012/12/2 Dan Carpenter :
> > On Sat, Dec 01, 2012 at 02:45:57AM +0900, Joonsoo Kim wrote:
> >> @@ -614,21 +616,35 @@ static int ashmem_pin_unpin(struct ashmem_area 
> >> *asma, unsigned long cmd,
> >>   pgstart = pin.offset / PAGE_SIZE;
> >>   pgend = pgstart + (pin.len / PAGE_SIZE) - 1;
> >>
> >> - mutex_lock(_mutex);
> >> + if (asma->shared_mapping) {
> >> + mutex_lock(_mutex);
> >
> > Wouldn't we need to hold the mutex while we check the
> > ->shared_mapping?
> 
> I doesn't fully understand ashmem's lock semantic.
> Code for retrieving some value of asma instance doesn't hold the mutex, now.
> For example, in ashmem_ioctl(), asma->size, asma->prot_mask.
> And in ashmem_pin_unpin(), there is asma->file, asma->size which is
> retrieved without the mutex.
> According to this semantic, the mutex doesn't need for checking
> asma->shared_mapping.

The ashmem_ioctl() is clearly racy.  :P  asma->size can be modified
and read at the same time.  It's not an example to follow.

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: [PATCH 1/1] regulator: new driver for LP8755

[Mark Brown]

On Mon, Dec 03, 2012 at 04:24:43PM +0900, GShark Jeong wrote:
> 2012/12/3 Mark Brown 
> > On Mon, Dec 03, 2012 at 01:44:24PM +0900, Daniel Jeong wrote:

> > > + if (ret < 0)
> > > + goto out_i2c_error;
> > > + dev_info(pchip->dev, "lp8755 : chip ID is 0x%x\n", regval);

> > This isn't actually checking anything except the I/O.  Can the chip ID
> > really vary?

> My configurations are already programmed in otp memory of chip as default
> values.
> So this comment for to others who are using different initial values with
> default data.
> I will drop it.

It seems like a better fix would be to add a check for the ID and fail
if the OTP value doesn't match, that way the driver won't try to run on
unsupported hardware.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFT PATCH v2 4/5] mm: provide more accurate estimation of pages occupied by memmap

[Chris Clayton]

On 12/02/12 19:55, Chris Clayton wrote:



On 11/29/12 10:52, Chris Clayton wrote:

On 11/28/12 23:52, Andrew Morton wrote:

On Wed, 21 Nov 2012 23:09:46 +0800
Jiang Liu  wrote:


Subject: Re: [RFT PATCH v2 4/5] mm: provide more accurate estimation
of pages occupied by memmap


How are people to test this?  "does it boot"?



I've been running kernels with Gerry's 5 patches applied for 11 days
now. This is on a 64bit laptop but with a 32bit kernel + HIGHMEM. I
joined the conversation because my laptop would not resume from suspend
to disk - it either froze or rebooted. With the patches applied the
laptop does successfully resume and has been stable.

Since Monday, I have have been running a kernel with the patches (plus,
from today, the patch you mailed yesterday) applied to 3.7rc7, without
problems.



I've been running 3.7-rc7 with the patches listed below for a week now
and it has been perfectly stable. In particular, my laptop will now
successfully resume from suspend to disk, which always failed without
the patches.



I should have said, of course, that it was -rc6 and earlier that would 
not boot without Jiang Liu's patches. I applied those patches to rc-6 
and my resume after suspend to disk problem was fixed. For a subsequent 
week I have been running with the patches applied to -rc7, with Andrew's 
patch also applied for the last 3 days. -rc7 was not subject to the 
resume problem because the patch which broke it had been reverted.
All this has been on a 64bit laptop, but running a 32bit kernel with 
HIGHMEM.


Apologies for yesterday's inaccuracy. I shouldn't send testing reports 
when I'm in a hurry.



 From Jiang Liu:
1. [RFT PATCH v2 1/5] mm: introduce new field "managed_pages" to struct
zone
2. [RFT PATCH v1 2/5] mm: replace zone->present_pages with
zone->managed_pages if appreciated
3. [RFT PATCH v1 3/5] mm: set zone->present_pages to number of existing
pages in the zone
4. [RFT PATCH v2 4/5] mm: provide more accurate estimation of pages
occupied by memmap
5. [RFT PATCH v1 5/5] mm: increase totalram_pages when free pages
allocated by bootmem allocator

 From Andrew Morton:
6. mm-provide-more-accurate-estimation-of-pages-occupied-by-memmap.patch

Tested-by: Chris Clayton 


Thanks,
Chris



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

Re: [PATCH v2 1/2] zsmalloc: add function to query object size

[Nitin Gupta]

On Nov 30, 2012, at 5:54 AM, Minchan Kim  wrote:

> On Thu, Nov 29, 2012 at 10:54:48PM -0800, Nitin Gupta wrote:
>> Changelog v2 vs v1:
>> - None
>> 
>> Adds zs_get_object_size(handle) which provides the size of
>> the given object. This is useful since the user (zram etc.)
>> now do not have to maintain object sizes separately, saving
>> on some metadata size (4b per page).
>> 
>> The object handle encodes  pair which currently points
>> to the start of the object. Now, the handle implicitly stores the size
>> information by pointing to the object's end instead. Since zsmalloc is
>> a slab based allocator, the start of the object can be easily determined
>> and the difference between the end offset encoded in the handle and the
>> start gives us the object size.
>> 
>> Signed-off-by: Nitin Gupta 
> Acked-by: Minchan Kim 
> 
> I already had a few comment in your previous versoin.
> I'm OK although you ignore them because I can make follow up patch about
> my nitpick but could you answer below my question?
> 
>> ---
>> drivers/staging/zsmalloc/zsmalloc-main.c |  177 
>> +-
>> drivers/staging/zsmalloc/zsmalloc.h  |1 +
>> 2 files changed, 127 insertions(+), 51 deletions(-)
>> 
>> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
>> b/drivers/staging/zsmalloc/zsmalloc-main.c
>> index 09a9d35..65c9d3b 100644
>> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
>> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
>> @@ -112,20 +112,20 @@
>> #define MAX_PHYSMEM_BITS 36
>> #else /* !CONFIG_HIGHMEM64G */
>> /*
>> - * If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
>> + * If this definition of MAX_PHYSMEM_BITS is used, OFFSET_BITS will just
>>  * be PAGE_SHIFT
>>  */
>> #define MAX_PHYSMEM_BITS BITS_PER_LONG
>> #endif
>> #endif
>> #define _PFN_BITS(MAX_PHYSMEM_BITS - PAGE_SHIFT)
>> -#define OBJ_INDEX_BITS(BITS_PER_LONG - _PFN_BITS)
>> -#define OBJ_INDEX_MASK((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
>> +#define OFFSET_BITS(BITS_PER_LONG - _PFN_BITS)
>> +#define OFFSET_MASK((_AC(1, UL) << OFFSET_BITS) - 1)
>> 
>> #define MAX(a, b) ((a) >= (b) ? (a) : (b))
>> /* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
>> #define ZS_MIN_ALLOC_SIZE \
>> -MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
>> +MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OFFSET_BITS))
>> #define ZS_MAX_ALLOC_SIZEPAGE_SIZE
>> 
>> /*
>> @@ -256,6 +256,11 @@ static int is_last_page(struct page *page)
>>return PagePrivate2(page);
>> }
>> 
>> +static unsigned long get_page_index(struct page *page)
>> +{
>> +return is_first_page(page) ? 0 : page->index;
>> +}
>> +
>> static void get_zspage_mapping(struct page *page, unsigned int *class_idx,
>>enum fullness_group *fullness)
>> {
>> @@ -433,39 +438,86 @@ static struct page *get_next_page(struct page *page)
>>return next;
>> }
>> 
>> -/* Encode  as a single handle value */
>> -static void *obj_location_to_handle(struct page *page, unsigned long 
>> obj_idx)
>> +static struct page *get_prev_page(struct page *page)
>> {
>> -unsigned long handle;
>> +struct page *prev, *first_page;
>> 
>> -if (!page) {
>> -BUG_ON(obj_idx);
>> -return NULL;
>> -}
>> +first_page = get_first_page(page);
>> +if (page == first_page)
>> +prev = NULL;
>> +else if (page == (struct page *)first_page->private)
>> +prev = first_page;
>> +else
>> +prev = list_entry(page->lru.prev, struct page, lru);
>> 
>> -handle = page_to_pfn(page) << OBJ_INDEX_BITS;
>> -handle |= (obj_idx & OBJ_INDEX_MASK);
>> +return prev;
>> 
>> -return (void *)handle;
>> }
>> 
>> -/* Decode  pair from the given object handle */
>> -static void obj_handle_to_location(unsigned long handle, struct page **page,
>> -unsigned long *obj_idx)
>> +static void *encode_ptr(struct page *page, unsigned long offset)
>> {
>> -*page = pfn_to_page(handle >> OBJ_INDEX_BITS);
>> -*obj_idx = handle & OBJ_INDEX_MASK;
>> +unsigned long ptr;
>> +ptr = page_to_pfn(page) << OFFSET_BITS;
>> +ptr |= offset & OFFSET_MASK;
>> +return (void *)ptr;
>> +}
>> +
>> +static void decode_ptr(unsigned long ptr, struct page **page,
>> +unsigned int *offset)
>> +{
>> +*page = pfn_to_page(ptr >> OFFSET_BITS);
>> +*offset = ptr & OFFSET_MASK;
>> +}
>> +
>> +static struct page *obj_handle_to_page(unsigned long handle)
>> +{
>> +struct page *page;
>> +unsigned int offset;
>> +
>> +decode_ptr(handle, , );
>> +if (offset < get_page_index(page))
>> +page = get_prev_page(page);
>> +
>> +return page;
>> +}
>> +
>> +static unsigned int obj_handle_to_offset(unsigned long handle,
>> +unsigned int class_size)
>> +{
>> +struct page *page;
>> +unsigned int offset;
>> +
>> +decode_ptr(handle, , );
>> +if (offset < get_page_index(page))
>> +offset = 

Re: [net-next RFC] pktgen: don't wait for the device who doesn't free skb immediately after sent

[Jason Wang]

On Tuesday, November 27, 2012 08:49:19 AM Stephen Hemminger wrote:
> On Tue, 27 Nov 2012 14:45:13 +0800
> 
> Jason Wang  wrote:
> > On 11/27/2012 01:37 AM, Stephen Hemminger wrote:
> > > On Mon, 26 Nov 2012 15:56:52 +0800
> > > 
> > > Jason Wang  wrote:
> > >> Some deivces do not free the old tx skbs immediately after it has been
> > >> sent
> > >> (usually in tx interrupt). One such example is virtio-net which
> > >> optimizes for virt and only free the possible old tx skbs during the
> > >> next packet sending. This would lead the pktgen to wait forever in the
> > >> refcount of the skb if no other pakcet will be sent afterwards.
> > >> 
> > >> Solving this issue by introducing a new flag IFF_TX_SKB_FREE_DELAY
> > >> which could notify the pktgen that the device does not free skb
> > >> immediately after it has been sent and let it not to wait for the
> > >> refcount to be one.
> > >> 
> > >> Signed-off-by: Jason Wang 
> > > 
> > > Another alternative would be using skb_orphan() and skb->destructor.
> > > There are other cases where skb's are not freed right away.
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > Hi Stephen:
> > 
> > Do you mean registering a skb->destructor for pktgen then set and check
> > bits in skb->tx_flag?
> 
> Yes. Register a destructor that does something like update a counter (number
> of packets pending), then just spin while number of packets pending is over
> threshold.

Have some experiments on this, looks like it does not work weel when clone_skb 
is used. For driver that call skb_orphan() in ndo_start_xmit, the destructor 
is only called when the first packet were sent, but what we need to know is 
when the last were sent. Any thoughts on this or we can just introduce another 
flag (anyway we have something like IFF_TX_SKB_SHARING) ?

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [3.5/6.x][e1000e] - Regression - Unable to receive packets if MTU == 1500

[Shawn Starr]

On Thursday, November 01, 2012 02:01:05 PM Shawn Starr wrote:
> Hello network driver folks,

To follow up, this is fixed now in 3.6.7-5.fc18.x86_64 

[38936.525226] e1000e :00:19.0: eth0: changing MTU from 9000 to 1500
[38936.539510] e1000e :00:19.0: Interrupt Throttle Rate turned on
[38939.352053] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: Rx/Tx

I don't remember which 3.6 -rc fixed it but I saw some adjustments in e1000e 
threshold changes in Linus's usual announce -rc emails.

Thanks for fixing! Now onto Fedora 19 (3.7) kernel testing

Shawn.

> 
> I recently decided to reinstall my Lenovo W500 laptop and found I wasn't
> able to get DHCP leases, I wasn't able to install over PXE (when getting
> the IP a second time within the OS)
> 
> Fedora is currently using kernel-3.6.2-2.fc18.x86_64 (Pre-beta)
> 
> The only difference I noticed was in my old install of Fedora, I had added
> MTU=9000 to the interface config while using a 3.5 kernel, not knowing 3.6.x
> seems to break things.
> 
> My Cisco DPC3825 Switch/Cable modem has an MTU setting but this is from
> Cable provider <-> WAN interface only. I tried changing to 1500 but by
> default it uses this anyway.
> 
> I had noticed tx unit hang errors sometimes, but not when MTU is above 1500.
> 
> PCI info:
> 
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network
> Connection (rev 03)
> Subsystem: Lenovo Device 20ee
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 46
> Region 0: Memory at fc00 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fc025000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at 1840 [size=32]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: fee0100c  Data: 41a2
> Capabilities: [e0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: e1000e
> 
> e1000e conversation log:
> 
> [   12.653816] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
> [   12.653819] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
> [   12.653855] e1000e :00:19.0: setting latency timer to 64
> [   12.653938] e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set
> to dynamic conservative mode
> [   12.653980] e1000e :00:19.0: irq 46 for MSI/MSI-X
> [   12.844121] e1000e :00:19.0: eth0: (PCI Express:2.5GT/s:Width x1)
> 00:22:68:0c:96:e3
> [   12.844124] e1000e :00:19.0: eth0: Intel(R) PRO/1000 Network
> Connection [   12.844150] e1000e :00:19.0: eth0: MAC: 7, PHY: 8, PBA
> No: 1008FF-0FF [   17.459570] e1000e :00:19.0: eth0: changing MTU from
> 1500 to 9000 [   17.459577] e1000e :00:19.0: Interrupt Throttle Rate
> turned off [   17.948121] e1000e :00:19.0: irq 46 for MSI/MSI-X
> [   18.049164] e1000e :00:19.0: irq 46 for MSI/MSI-X
> [   20.442936] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
> Control: Rx/Tx
> 
> When I set MTU = 1500 (2000 works), it will stop receiving packets, it also
> disables Interrupt Throttling when MTU is set higher.
> 
> After testing reasons why it wasn't get a DHCP lease, I decided to bump the
> MTU to 9000 for Jumbo Frames and as soon as I did this, I was able to get a
> lease and the network functioned resumes receiving packets.
> 
> Can anyone else report regressions or might know whats going on?
> 
> Thanks,
> Shawn.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] regulator: new driver for LP8755

[Mark Brown]

On Mon, Dec 03, 2012 at 01:44:24PM +0900, Daniel Jeong wrote:

> + regval &= ~(0x01 << id);
> +
> + /* mode fast means forced pwm mode.
> +mode normal means not forced pwm mode, according to
> +current load it could be one of modes, PWM/PFM/LPPFM. */
> + return regval ? REGULATOR_MODE_FAST : REGULATOR_MODE_NORMAL;

Your set_mode() implemented an idle mode as well but it can't be read
back..

> +err_i2c:
> + dev_err(pchip->dev, "i2c acceess error %s\n", __func__);
> + return -EINVAL;

Your approach to errors throughout the driver is very unhelpful - the
code returned by regmap will be discarded entirely, it's neither
displayed nor returned to the caller.  I'd also be inclined to avoid the
goto idiom, it normally means there's some unwinding to be done but
that's not the case here, just return.

> +/* buck voltage table */
> +static const int lp8755_buck_vtbl[] = {
> + 50, 51, 52, 53, 54,
> + 55, 56, 57, 58, 59,

There is no point in this being a table, as far as I can see it's a
nice linear map of values with some extras at the end which could just
be dropped.

> + /* check vendor id and write init value */

There's no writes...

> + ret = lp8755_read(pchip, 0x18, );

Magic numbers!

> + if (ret < 0)
> + goto out_i2c_error;
> + dev_info(pchip->dev, "lp8755 : chip ID is 0x%x\n", regval);

This isn't actually checking anything except the I/O.  Can the chip ID
really vary?

> + }
> +
> + dev_info(pchip->dev, "regulator init Done %s\n", __func__);

This isn't adding anything, drop it.

> + /* read & clear flag register */
> + ret = lp8755_read(pchip, 0x0D, );
> + ret |= lp8755_write(pchip, 0x0D, 0x00);

More magic numbers.

> + if (pdata == NULL) {
> + dev_err(>dev, "platform data is NULL.\n");
> + return -ENOMEM;
> + }

Platform data should be optional, you should be able to read back the
current regulator state even if you can't set it.

> + dev_info(>dev, "lp8755 init done.\n");
> + return ret;

Again, drop these noisy prints.  They're not adding anything.

> +/**
> + * struct lp8755_platform_data
> + * @mphase_type: Multiphase Switcher Configurations 0~8
> + * @buck_init_volt : buck0~6 init voltage in uV.
> + */
> +struct lp8755_platform_data {
> + int mphase;
> + struct regulator_init_data *buck_data[LP8755_BUCK_MAX];
> +};

The comments don't match the struct.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Doc: Update the naming of profiling based on sysfs

[Hyeonjun Lim]

We setup and run 'profiling' feature under Linux system.
The readprofile(1) command uses the /proc/profile information
to display ascii data on standard output.
sort -nr | head -5

/proc/profile correctly. The ./kernel/ksysfs.c defines 'profiling'
w/o 'profile' like "KERNEL_ATTR_RW(profiling)".
We need to synchronize the content between ksys.c source and kernel doc. 

Signed-off-by: Hyeonjun Lim 
---
 Documentation/ABI/testing/sysfs-profiling |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-profiling 
b/Documentation/ABI/testing/sysfs-profiling
index b02d8b8..8a8e466 100644
--- a/Documentation/ABI/testing/sysfs-profiling
+++ b/Documentation/ABI/testing/sysfs-profiling
@@ -1,13 +1,13 @@
-What:  /sys/kernel/profile
+What:  /sys/kernel/profiling
 Date:  September 2008
 Contact:   Dave Hansen 
 Description:
-   /sys/kernel/profile is the runtime equivalent
+   /sys/kernel/profiling is the runtime equivalent
of the boot-time profile= option.
 
You can get the same effect running:
 
-   echo 2 > /sys/kernel/profile
+   echo 2 > /sys/kernel/profiling
 
as you would by issuing profile=2 on the boot
command line.
-- 
1.7.8.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/

RE: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver

[Dudley Du]

Hi Henrik,

Okay, agree.
Thanks.

Best Wishes,
Dudley Du
d...@cypress.com

-Original Message-
From: Henrik Rydberg [mailto:rydb...@euromail.se]
Sent: Monday, December 03, 2012 2:31 PM
To: Dudley Du
Cc: Kamal Mostafa; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org; 
Dmitry Torokhov; David Solda; Troy Abercrombia; customercare; Kyle Fazzari; 
Mario Limonciello; Tim Gardner; Herton Krzesinski; d...@cyress.com
Subject: Re: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver

Hi Dudley,

> Another question is that new interface input_mt_assign_slots() is
> introduced since 3.7-rc7 or later, So we could not support the kernel 
> releases that earlier than 3.7-rc7 with this driver.

The patch is a submission to mainline, so of course it should be in sync with 
mainline.

Thanks.
Henrik

This message and any attachments may contain Cypress (or its subsidiaries) 
confidential information. If it has been received in error, please advise the 
sender and immediately delete this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] input: Cypress PS/2 Trackpad psmouse driver

[Henrik Rydberg]

Hi Dudley,

> Another question is that new interface input_mt_assign_slots() is introduced 
> since 3.7-rc7 or later,
> So we could not support the kernel releases that earlier than 3.7-rc7 with 
> this driver.

The patch is a submission to mainline, so of course it should be in sync with 
mainline.

Thanks.
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Partialy mapped page stays in page cache after unmap

[Vineet Gupta]

On Tuesday 30 October 2012 11:54 PM, chru...@suse.cz wrote:
> Hi!
> I'm currently revisiting mmap related tests in LTP (Linux Test Project)
> and I've came to the tests testing that writes to the partially
> mapped page (at the end of mapping) are carried out correctly.
> 
> These tests fails because even after the object is unmapped and the
> file-descriptor closed the pages still stays in the page cache so if
> (possibly another process) opens and maps the file again the whole
> content of the partial page is preserved.
> 
> Strictly speaking this is not a bug at least when sticking to regular
> files as POSIX which says that the change is not written out. In this
> case the file content is correct and forcing the data to be written out
> by msync() makes the test pass.

Hi Cyril,

I've seen the LTP open posix mmap/{11-4,11-5} issues in the past myself
and was something I wanted to discuss on the lists myself. Thanks for
bringing this up.

Jut to reiterate: the expectations are

1. zero filling of unmapped (trailing) partial page
2. NO Writeout (to disk) of trailing partial page.

#1 is broken as your latter test case proves. We can have an alternate
test case which starts with non empty file (preloaded with all 'a's),
mmap partial page and then read out the trailing partial page, it will
not be zeroes (it's probably ftruncate which does the trick in first place).

Regarding #2 - I did verify that msync indeed makes it pass - but I'm
confused why. After all it is going to commit the buffer  with 'b' to
on-disk - so a subsequent mmap is bound to see the update to file and
hence would make the test fail. What am  I missing here ?

Thx,
-Vineet

 The SHM mappings seems to preserve the
> content even after calling msync() which is, in my opinion, POSIX
> violation although a minor one.
> 
> Looking at the test results I have, the file based mmap test worked fine
> on 2.6.5 (or perhaps the page cache was working/setup differently and
> the test succeeded by accidend).
> 
> Attached is a stripped down LTP test for the problem, uncommenting the
> msync() makes the test succeed.
> 
> I would like to hear your opinions on this 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 1/1] regulator: new driver for LP8755

[Wanlong Gao]

<...>
> +
> +static int __devinit lp8755_regulator_init(struct lp8755_chip *pchip)

CONFIG_HOTPLUG is going away; it's already defined to always be 'Y'.
So, please don't use __devinit anymore.
refer to : http://marc.info/?l=linux-i2c=135341812915168=2

> +{
> + int ret, icnt, buck_num;
> + struct lp8755_platform_data *pdata = pchip->pdata;
> +
> + struct regulator_config rconfig = { };
> +
> + rconfig.regmap = pchip->regmap;
> + rconfig.dev = pchip->dev;
> + rconfig.driver_data = pchip;
<..>
> +}
> +
> +static int __devinit lp8755_int_config(struct lp8755_chip *pchip)

Ditto.

> +{
> + 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, );

> +}
> +
> +static int __devinit lp8755_probe(struct i2c_client *client,

Ditto.

> +   const struct i2c_device_id *id)
> +{
> + int ret, icnt;
> + struct lp8755_chip *pchip;
> + struct lp8755_platform_data *pdata = client->dev.platform_data;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + dev_err(>dev, "i2c functionality check fail.\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (pdata == NULL) {
> + dev_err(>dev, "platform data is NULL.\n");
> + return -ENOMEM;

> +
> + return ret;
> +}
> +
> +static int __devexit lp8755_remove(struct i2c_client *client)

Ditto.


> +{
> + int icnt;
> + struct lp8755_chip *pchip = i2c_get_clientdata(client);
> +
> + for (icnt = 0; icnt < mphase_buck[pchip->mphase].nreg; icnt++)
<..>
> +static struct i2c_driver lp8755_i2c_driver = {
> + .driver = {
> +.name = LP8755_NAME,
> +},
> + .probe = lp8755_probe,
> + .remove = __devexit_p(lp8755_remove),

Ditto. remove __devexit_p.


Thanks,
Wanlong Gao

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 1/8] video: tegra: Add nvhost driver

[Terje Bergström]

On 02.12.2012 22:55, Thierry Reding wrote:
> FWIW I'm convinced that you're genuinely trying to make this work and
> nobody welcomes this more than me. However it is only natural if you
> dump such a large body of code on the community that people will
> disagree with some of the design decisions.
> 
> So when I comment on the design or patches in general, it is not my
> intention to exclude you or NVIDIA in any way. All I'm trying to do is
> spot problematic or unclear parts that will make working with the code
> any more difficult than it has to be.

Thanks, I know it'a a large dump and you've made great comments about
the code, and hit most of the sore spots I've had with the driver, too.
I appreciate your effort - this process is making the driver better.

It's good to hear that our goals are aligned. So now that we got that
out of the system, let's get back to business. :-)

> Since tegra-drm is a DRM driver it should stay in drivers/gpu/drm. I can
> also live with the host1x driver staying in drivers/video, but I don't
> think it's the proper location and drivers/gpu/host1x seems like a much
> better fit.

That sounds like a plan to me.

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

linux-next: manual merge of the arm-soc tree with the slave_dma and tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/dma/mv_xor.c between commit d51e88b99533 ("dma: Convert dev_printk
(KERN_ to dev_(") from the slave-dma tree, commits
a7d6e3ec28bb ("dma: remove use of __devexit_p") and 463a1f8b3cee ("dma:
remove use of __devinit") from the driver-core tree and various commits
from the arm-soc tree.

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

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

diff --cc drivers/dma/mv_xor.c
index 3ef4095,9659e58..000
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@@ -206,8 -209,8 +209,8 @@@ static void mv_set_mode(struct mv_xor_c
op_mode = XOR_OPERATION_MODE_MEMSET;
break;
default:
-   dev_err(chan->device->common.dev,
+   dev_err(mv_chan_to_devp(chan),
 -  "error: unsupported operation %d.\n",
 +  "error: unsupported operation %d\n",
type);
BUG();
return;
@@@ -828,22 -828,28 +828,28 @@@ static void mv_dump_xor_regs(struct mv_
u32 val;
  
val = __raw_readl(XOR_CONFIG(chan));
-   dev_err(chan->device->common.dev, "config   0x%08x\n", val);
+   dev_err(mv_chan_to_devp(chan),
 -  "config   0x%08x.\n", val);
++  "config   0x%08x\n", val);
  
val = __raw_readl(XOR_ACTIVATION(chan));
-   dev_err(chan->device->common.dev, "activation   0x%08x\n", val);
+   dev_err(mv_chan_to_devp(chan),
 -  "activation   0x%08x.\n", val);
++  "activation   0x%08x\n", val);
  
val = __raw_readl(XOR_INTR_CAUSE(chan));
-   dev_err(chan->device->common.dev, "intr cause   0x%08x\n", val);
+   dev_err(mv_chan_to_devp(chan),
 -  "intr cause   0x%08x.\n", val);
++  "intr cause   0x%08x\n", val);
  
val = __raw_readl(XOR_INTR_MASK(chan));
-   dev_err(chan->device->common.dev, "intr mask0x%08x\n", val);
+   dev_err(mv_chan_to_devp(chan),
 -  "intr mask0x%08x.\n", val);
++  "intr mask0x%08x\n", val);
  
val = __raw_readl(XOR_ERROR_CAUSE(chan));
-   dev_err(chan->device->common.dev, "error cause  0x%08x\n", val);
+   dev_err(mv_chan_to_devp(chan),
 -  "error cause  0x%08x.\n", val);
++  "error cause  0x%08x\n", val);
  
val = __raw_readl(XOR_ERROR_ADDR(chan));
-   dev_err(chan->device->common.dev, "error addr   0x%08x\n", val);
+   dev_err(mv_chan_to_devp(chan),
 -  "error addr   0x%08x.\n", val);
++  "error addr   0x%08x\n", val);
  }
  
  static void mv_xor_err_interrupt_handler(struct mv_xor_chan *chan,
@@@ -855,8 -861,8 +861,8 @@@
 return;
}
  
-   dev_err(chan->device->common.dev,
+   dev_err(mv_chan_to_devp(chan),
 -  "error on chan %d. intr cause 0x%08x.\n",
 +  "error on chan %d. intr cause 0x%08x\n",
chan->idx, intr_cause);
  
mv_dump_xor_regs(chan);
@@@ -895,7 -901,7 +901,7 @@@ static void mv_xor_issue_pending(struc
   */
  #define MV_XOR_TEST_SIZE 2000
  
- static int mv_xor_memcpy_self_test(struct mv_xor_device *device)
 -static int __devinit mv_xor_memcpy_self_test(struct mv_xor_chan *mv_chan)
++static int mv_xor_memcpy_self_test(struct mv_xor_chan *mv_chan)
  {
int i;
void *src, *dest;
@@@ -969,8 -970,8 +970,8 @@@ out
  }
  
  #define MV_XOR_NUM_SRC_TEST 4 /* must be <= 15 */
 -static int __devinit
 +static int
- mv_xor_xor_self_test(struct mv_xor_device *device)
+ mv_xor_xor_self_test(struct mv_xor_chan *mv_chan)
  {
int i, src_idx;
struct page *dest;
@@@ -1199,26 -1188,28 +1187,27 @@@ mv_xor_channel_add(struct mv_xor_devic
}
  
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
-   ret = mv_xor_xor_self_test(adev);
+   ret = mv_xor_xor_self_test(mv_chan);
dev_dbg(>dev, "xor self test returned %d\n", ret);
if (ret)
-   goto err_free_dma;
+   goto err_free_irq;
}
  
 -  dev_info(>dev, "Marvell XOR: "
 -"( %s%s%s%s)\n",
 -dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
 -dma_has_cap(DMA_MEMSET, dma_dev->cap_mask)  ? "fill " : "",
 -dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
 -dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
 +  dev_info(>dev, "Marvell XOR: ( %s%s%s%s)\n",
 +   dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
 +   dma_has_cap(DMA_MEMSET, dma_dev->cap_mask)  ? "fill " : "",
 +   dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
 +   dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
  
dma_async_device_register(dma_dev);
-   goto 

Re: [PATCH 0/1] regulator: new driver for LP8755

[Mark Brown]

On Mon, Dec 03, 2012 at 01:44:23PM +0900, Daniel Jeong wrote:
> From: Daniel Jeong 
> 
> 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 be filexibly bundled
> together in multiphase converters as required by application.

Don't send cover letters for single patches. If doing this either you
need to improve your patch description or the cover letter is adding
nothing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net-next rfc v7 3/3] virtio-net: change the number of queues through ethtool

[Jason Wang]

On Sunday, December 02, 2012 06:09:06 PM Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2012 at 06:16:00PM +0800, Jason Wang wrote:
> > This patch implement the {set|get}_channels method of ethool to allow user
> > to change the number of queues dymaically when the device is running.
> > This would let the user to configure it on demand.
> > 
> > Signed-off-by: Jason Wang 
> > ---
> > 
> >  drivers/net/virtio_net.c |   41 +
> >  1 files changed, 41 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index bcaa6e5..f08ec2a 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1578,10 +1578,51 @@ static struct virtio_driver virtio_net_driver = {
> > 
> >  #endif
> >  };
> > 
> > +/* TODO: Eliminate OOO packets during switching */
> > +static int virtnet_set_channels(struct net_device *dev,
> > +   struct ethtool_channels *channels)
> > +{
> > +   struct virtnet_info *vi = netdev_priv(dev);
> > +   u16 queue_pairs = channels->combined_count;
> > +
> > +   /* We don't support separate rx/tx channels.
> > +* We don't allow setting 'other' channels.
> > +*/
> > +   if (channels->rx_count || channels->tx_count || channels->other_count)
> > +   return -EINVAL;
> > +
> > +   /* Only two modes were support currently */
> > +   if (queue_pairs != vi->max_queue_pairs && queue_pairs != 1)
> > +   return -EINVAL;
> > +
> 
> Why the limitation?

Not sure the value bettwen 1 and max_queue_pairs is useful. But anyway, I can 
remove this limitation.
> Also how does userspace discover what the legal values are?

Userspace only check whether the value is greater than max_queue_pairs.
> 
> > +   vi->curr_queue_pairs = queue_pairs;
> > +   BUG_ON(virtnet_set_queues(vi));
> > +
> > +   netif_set_real_num_tx_queues(dev, vi->curr_queue_pairs);
> > +   netif_set_real_num_rx_queues(dev, vi->curr_queue_pairs);
> > +
> > +   return 0;
> > +}
> > +
> > +static void virtnet_get_channels(struct net_device *dev,
> > +struct ethtool_channels *channels)
> > +{
> > +   struct virtnet_info *vi = netdev_priv(dev);
> > +
> > +   channels->combined_count = vi->curr_queue_pairs;
> > +   channels->max_combined = vi->max_queue_pairs;
> > +   channels->max_other = 0;
> > +   channels->rx_count = 0;
> > +   channels->tx_count = 0;
> > +   channels->other_count = 0;
> > +}
> > +
> > 
> >  static const struct ethtool_ops virtnet_ethtool_ops = {
> >  
> > .get_drvinfo = virtnet_get_drvinfo,
> > .get_link = ethtool_op_get_link,
> > .get_ringparam = virtnet_get_ringparam,
> > 
> > +   .set_channels = virtnet_set_channels,
> > +   .get_channels = virtnet_get_channels,
> > 
> >  };
> >  
> >  static int __init init(void)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [net-next rfc v7 2/3] virtio_net: multiqueue support

[Jason Wang]

On Monday, December 03, 2012 12:34:08 PM Rusty Russell wrote:
> Jason Wang  writes:
> > +static const struct ethtool_ops virtnet_ethtool_ops;
> > +
> > +/*
> > + * Converting between virtqueue no. and kernel tx/rx queue no.
> > + * 0:rx0 1:tx0 2:cvq 3:rx1 4:tx1 ... 2N+1:rxN 2N+2:txN
> > + */
> > +static int vq2txq(struct virtqueue *vq)
> > +{
> > +   int index = virtqueue_get_queue_index(vq);
> > +   return index == 1 ? 0 : (index - 2) / 2;
> > +}
> > +
> > +static int txq2vq(int txq)
> > +{
> > +   return txq ? 2 * txq + 2 : 1;
> > +}
> > +
> > +static int vq2rxq(struct virtqueue *vq)
> > +{
> > +   int index = virtqueue_get_queue_index(vq);
> > +   return index ? (index - 1) / 2 : 0;
> > +}
> > +
> > +static int rxq2vq(int rxq)
> > +{
> > +   return rxq ? 2 * rxq + 1 : 0;
> > +}
> > +
> 
> I thought MST changed the proposed spec to make the control queue always
> the last one, so this logic becomes trivial.

But it may break the support of legacy guest. If we boot a legacy single queue 
guest on a 2 queue virtio-net device. It may think vq 2 is cvq which is indeed 
rx1.
> 
> > +static int virtnet_set_queues(struct virtnet_info *vi)
> > +{
> > +   struct scatterlist sg;
> > +   struct virtio_net_ctrl_rfs s;
> > +   struct net_device *dev = vi->dev;
> > +
> > +   s.virtqueue_pairs = vi->curr_queue_pairs;
> > +   sg_init_one(, , sizeof(s));
> > +
> > +   if (!vi->has_cvq)
> > +   return -EINVAL;
> > +
> > +   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RFS,
> > + VIRTIO_NET_CTRL_RFS_VQ_PAIRS_SET, , 1, 0)){
> > +   dev_warn(>dev, "Fail to set the number of queue pairs to"
> > +" %d\n", vi->curr_queue_pairs);
> > +   return -EINVAL;
> > +   }
> 
> Where do we check the VIRTIO_NET_F_RFS bit?

Yes, we need this check. Will let the caller does the check and add a comment 
and check in the caller.
> 
> >  static int virtnet_probe(struct virtio_device *vdev)
> >  {
> > 
> > -   int err;
> > +   int i, err;
> > 
> > struct net_device *dev;
> > struct virtnet_info *vi;
> > 
> > +   u16 curr_queue_pairs;
> > +
> > +   /* Find if host supports multiqueue virtio_net device */
> > +   err = virtio_config_val(vdev, VIRTIO_NET_F_RFS,
> > +   offsetof(struct virtio_net_config,
> > +   max_virtqueue_pairs), _queue_pairs);
> > +
> > +   /* We need at least 2 queue's */
> > +   if (err)
> > +   curr_queue_pairs = 1;
> 
> Huh?  Just call this queue_pairs.  It's not curr_ at all...
> 
> > +   if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > +   vi->has_cvq = true;
> > +
> > +   /* Use single tx/rx queue pair as default */
> > +   vi->curr_queue_pairs = 1;
> > +   vi->max_queue_pairs = curr_queue_pairs;
> 
> See...

Right, will use max_queue_pairs then.

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

RE: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver

[Dudley Du]

Hi Kamal,

Another question is that new interface input_mt_assign_slots() is introduced 
since 3.7-rc7 or later,
So we could not support the kernel releases that earlier than 3.7-rc7 with this 
driver.

So my idea is that in order to keep compatible with earlier kernel release,
Let's use our old method to calculate the slots, not using latest interface 
input_mt_assign_slots() here.

What's your idea about it?

Thanks.

Best Wishes,
Dudley Du
d...@cypress.com


-Original Message-
From: Dudley Du
Sent: Monday, December 03, 2012 11:21 AM
To: 'Kamal Mostafa'; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org; 
Dmitry Torokhov; Henrik Rydberg
Cc: David Solda; Troy Abercrombia; customercare; Kyle Fazzari; Mario 
Limonciello; Tim Gardner; Herton Krzesinski; 'd...@cyress.com'
Subject: RE: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver

Hi Kamal,

I'm the writer of this driver.
Thanks for help upstream this driver.

I noticed that you marked out the reconnect function for it never work at all.
But in my test, it seems work fine.
I do the test steps as below:
1. load this driver with Cypress trackpad. Cursor moving on system; 2. directly 
unplug the trackpad from system; 3. reconnect the trackpad device to PC again; 
4. moving finger on trackpad to check cursor still working on the system.
And also, I checked the debug message through dmesg, it makes sure that the 
reconnection function is called, and also the driver and trackpad still working 
fine.

So I want to know what situation is in your test to this function, could you 
help describe your test steps to me, so we can figure out this issue.

Thanks.

Best Wishes,
Dudley Du
d...@cyrpess.com



>From: Cypress Semiconductor Corporation 
>
>Input/mouse driver for Cypress PS/2 Trackpad.
>
>Original code contributed by Cypress Semiconductor Corporation,
>modified by Kamal Mostafa and Kyle Fazzari.
>
>BugLink: http://launchpad.net/bugs/978807
>
>Signed-off-by: Kamal Mostafa 
>Signed-off-by: Kyle Fazzari 
>Signed-off-by: Mario Limonciello 
>Signed-off-by: Tim Gardner 
>Acked-by: Herton Krzesinski 
>---
> drivers/input/mouse/cypress_ps2.c |  830
>+
> drivers/input/mouse/cypress_ps2.h |  219 ++
> 2 files changed, 1049 insertions(+)
> create mode 100644 drivers/input/mouse/cypress_ps2.c  create mode
>100644 drivers/input/mouse/cypress_ps2.h
>
>diff --git a/drivers/input/mouse/cypress_ps2.c
>b/drivers/input/mouse/cypress_ps2.c
>new file mode 100644
>index 000..472342a
>--- /dev/null
>+++ b/drivers/input/mouse/cypress_ps2.c
>@@ -0,0 +1,830 @@
>+/*
>+ * Cypress Trackpad PS/2 mouse driver
>+ *
>+ * Copyright (c) 2012 Cypress Semiconductor Corporation.
>+ *
>+ * Additional contributors include:
>+ *   Kamal Mostafa 
>+ *   Kyle Fazzari 
>+ *
>+ * 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 "cypress_ps2.h"
>+
>+#define CYTP_DBG_DUMP 0   /* set to 1 for more verbose debug dump 
>*/
>+
>+#define cytp_dbg(fmt, ...)  \
>+  do {  \
>+  if (cytp)  \
>+  psmouse_dbg(psmouse, pr_fmt(fmt), ##__VA_ARGS__);  \
>+  } while (0)
>+
>+#if CYTP_DBG_DUMP
>+# define cytp_dbg_dump cytp_dbg
>+#else
>+# define cytp_dbg_dump(fmt, ...)
>+#endif
>+
>+
>+/* p is a pointer points to the buffer containing Cypress Keys. */
>+#define IS_CYPRESS_KEY(p) ((p[0] == CYPRESS_KEY_1) && (p[1] ==
>+CYPRESS_KEY_2)) #define CYTP_SET_PACKET_SIZE(n) { psmouse->pktsize =
>+cytp->pkt_size = (n); } #define CYTP_SET_MODE_BIT(x)  \
>+  do {  \
>+  if ((x) & CYTP_BIT_ABS_REL_MASK)  \
>+  cytp->mode = (cytp->mode & ~CYTP_BIT_ABS_REL_MASK);  \
>+  cytp->mode |= (x);  \
>+  } while (0)
>+#define CYTP_CLEAR_MODE_BIT(x){ cytp->mode &= ~(x); }
>+
>+#define CYTP_SUPPORT_ABS
>+
>+static unsigned char cytp_rate[] = {10, 20, 40, 60, 100, 200}; static
>+unsigned char cytp_resolution[] = {0x00, 0x01, 0x02, 0x03};
>+
>+static int cypress_ps2_sendbyte(struct psmouse *psmouse, int value) {
>+  struct cytp_data *cytp = psmouse->private;
>+  struct ps2dev *ps2dev = >ps2dev;
>+
>+  if (ps2_sendbyte(ps2dev, value & 0xff, CYTP_CMD_TIMEOUT) < 0) {
>+  cytp_dbg("send command 0x%02x failed, resp 0x%02x\n",
>+   value & 0xff, ps2dev->nak);
>+  if (ps2dev->nak == CYTP_PS2_RETRY)
>+  return CYTP_PS2_RETRY;
>+  else
>+  return CYTP_PS2_ERROR;
>+  }
>+
>+  cytp_dbg("send command 0x%02x success, resp 0xfa\n", value & 0xff);
>+
>+  return 0;
>+}
>+
>+static int cypress_ps2_ext_cmd(struct psmouse *psmouse, unsigned short cmd,
>+ unsigned 

linux-next: manual merge of the arm-soc tree with the devicetree tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-vexpress/v2m.c between commit 465aac6d496a ("Fix build when
CONFIG_W1_MASTER_GPIO=m b exporting "allnodes"") from the devicetree tree
and commit 0891642cf117 ("ARM: vexpress: Start using new Versatile
Express infrastructure") from the arm-soc tree.

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

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

diff --cc arch/arm/mach-vexpress/v2m.c
index 359f782,4e168e8..000
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@@ -580,20 -420,13 +420,13 @@@ void __init v2m_dt_map_io(void
  
  void __init v2m_dt_init_early(void)
  {
-   struct device_node *node;
u32 dt_hbi;
  
-   node = of_find_compatible_node(NULL, NULL, "arm,vexpress-sysreg");
-   v2m_sysreg_base = of_iomap(node, 0);
-   if (WARN_ON(!v2m_sysreg_base))
-   return;
+   vexpress_sysreg_of_early_init();
  
/* Confirm board type against DT property, if available */
 -  if (of_property_read_u32(allnodes, "arm,hbi", _hbi) == 0) {
 +  if (of_property_read_u32(of_allnodes, "arm,hbi", _hbi) == 0) {
-   int site = v2m_get_master_site();
-   u32 id = readl(v2m_sysreg_base + (site == SYS_CFG_SITE_DB2 ?
-   V2M_SYS_PROCID1 : V2M_SYS_PROCID0));
-   u32 hbi = id & SYS_PROCIDx_HBI_MASK;
+   u32 hbi = vexpress_get_hbi(VEXPRESS_SITE_MASTER);
  
if (WARN_ON(dt_hbi != hbi))
pr_warning("vexpress: DT HBI (%x) is not matching "


pgpWa88GhAU4f.pgp
Description: PGP signature

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/media/platform/omap/omap_vout.c between commit 950e2fb420d5
("[media] omap_vout: use omapdss's version instead of cpu_is_*") from the
omap_dss2 tree and commit 45c3eb7d3a07 ("ARM: OMAP: Move
plat-omap/dma-omap.h to include/linux/omap-dma.h") from the arm-soc tree.

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

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

diff --cc drivers/media/platform/omap/omap_vout.c
index 718e5f6,9935040..000
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@@ -44,6 -44,8 +44,7 @@@
  #include 
  #include 
  
 -#include 
+ #include 
  #include 
  #include 
  


pgppTW9fYTyiV.pgp
Description: PGP signature

Re: [net-next rfc v7 2/3] virtio_net: multiqueue support

[Jason Wang]

On Sunday, December 02, 2012 06:06:31 PM Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2012 at 06:15:59PM +0800, Jason Wang wrote:
> > This addes multiqueue support to virtio_net driver. In multiple queue
> > modes, the driver expects the number of queue paris is equal to the
> > number of vcpus. To eliminate the contention bettwen vcpus and
> > virtqueues, per-cpu virtqueue pairs were implemented through:
> > 
> > - select the txq based on the smp processor id.
> > - smp affinity hint were set to the vcpu that owns the queue pairs.
> > 
> > Signed-off-by: Krishna Kumar 
> > Signed-off-by: Jason Wang 
> > ---
> > 
> >  drivers/net/virtio_net.c|  454
> >  ++- include/uapi/linux/virtio_net.h
> >  |   16 ++
> >  2 files changed, 371 insertions(+), 99 deletions(-)
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 7975133..bcaa6e5 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -84,17 +84,25 @@ struct virtnet_info {
> > 
> > struct virtio_device *vdev;
> > struct virtqueue *cvq;
> > struct net_device *dev;
> > 
> > -   struct napi_struct napi;
> > -   struct send_queue sq;
> > -   struct receive_queue rq;
> > +   struct send_queue *sq;
> > +   struct receive_queue *rq;
> > 
> > unsigned int status;
> > 
> > +   /* Max # of queue pairs supported by the device */
> > +   u16 max_queue_pairs;
> > +
> > +   /* # of queue pairs currently used by the driver */
> > +   u16 curr_queue_pairs;
> > +
> > 
> > /* I like... big packets and I cannot lie! */
> > bool big_packets;
> > 
> > /* Host will merge rx buffers for big packets (shake it! shake it!) */
> > bool mergeable_rx_bufs;
> > 
> > +   /* Has control virtqueue */
> > +   bool has_cvq;
> > +
> > 
> > /* enable config space updates */
> > bool config_enable;
> > 
> > @@ -126,6 +134,34 @@ struct padded_vnet_hdr {
> > 
> > char padding[6];
> >  
> >  };
> > 
> > +static const struct ethtool_ops virtnet_ethtool_ops;
> > +
> > +/*
> > + * Converting between virtqueue no. and kernel tx/rx queue no.
> > + * 0:rx0 1:tx0 2:cvq 3:rx1 4:tx1 ... 2N+1:rxN 2N+2:txN
> > + */
> 
> Weird, this isn't what spec v5 says: it says
> 0:rx0 1:tx0 2: rx1 3: tx1  vcq
> We can change the spec to match but keeping all rx/tx
> together seems a bit prettier?

Oh, I miss the check of this part in v5. Have a thought about this, if we 
change the location of cvq, we may break the support of legacy guest with only 
single queue support. Consider we start a vm with 2 queue but boot a signle 
queue legacy guest, it may think vq 2 is cvq which indeed is rx1.
> 
> > +static int vq2txq(struct virtqueue *vq)
> > +{
> > +   int index = virtqueue_get_queue_index(vq);
> > +   return index == 1 ? 0 : (index - 2) / 2;
> > +}
> > +
> > +static int txq2vq(int txq)
> > +{
> > +   return txq ? 2 * txq + 2 : 1;
> > +}
> > +
> > +static int vq2rxq(struct virtqueue *vq)
> > +{
> > +   int index = virtqueue_get_queue_index(vq);
> > +   return index ? (index - 1) / 2 : 0;
> > +}
> > +
> > +static int rxq2vq(int rxq)
> > +{
> > +   return rxq ? 2 * rxq + 1 : 0;
> > +}
> > +
> > 
> >  static inline struct skb_vnet_hdr *skb_vnet_hdr(struct sk_buff *skb)
> >  {
> >  
> > return (struct skb_vnet_hdr *)skb->cb;
> > 
> > @@ -166,7 +202,7 @@ static void skb_xmit_done(struct virtqueue *vq)
> > 
> > virtqueue_disable_cb(vq);
> > 
> > /* We were probably waiting for more output buffers. */
> > 
> > -   netif_wake_queue(vi->dev);
> > +   netif_wake_subqueue(vi->dev, vq2txq(vq));
> > 
> >  }
> >  
> >  static void set_skb_frag(struct sk_buff *skb, struct page *page,
> > 
> > @@ -503,7 +539,7 @@ static bool try_fill_recv(struct receive_queue *rq,
> > gfp_t gfp)> 
> >  static void skb_recv_done(struct virtqueue *rvq)
> >  {
> >  
> > struct virtnet_info *vi = rvq->vdev->priv;
> > 
> > -   struct receive_queue *rq = >rq;
> > +   struct receive_queue *rq = >rq[vq2rxq(rvq)];
> > 
> > /* Schedule NAPI, Suppress further interrupts if successful. */
> > if (napi_schedule_prep(>napi)) {
> > 
> > @@ -650,7 +686,8 @@ static int xmit_skb(struct send_queue *sq, struct
> > sk_buff *skb)> 
> >  static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device
> >  *dev)
> >  {
> >  
> > struct virtnet_info *vi = netdev_priv(dev);
> > 
> > -   struct send_queue *sq = >sq;
> > +   int qnum = skb_get_queue_mapping(skb);
> > +   struct send_queue *sq = >sq[qnum];
> > 
> > int capacity;
> > 
> > /* Free up any pending old buffers before queueing new ones. */
> > 
> > @@ -664,13 +701,14 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> > struct net_device *dev)> 
> > if (likely(capacity == -ENOMEM)) {
> > 
> > if (net_ratelimit())
> > 
> > dev_warn(>dev,
> > 
> > -"TX queue failure: out of memory\n");
> > + 

[PATCH v2 2/4] mfd: 88pm80x: move to regmap irq base implementation

[Qing Xu]

From: Qing Xu 

get irq_base for mfd sub-device

Signed-off-by: Qiao Zhou 
Signed-off-by: Qing Xu 
---
 drivers/mfd/88pm800.c   |2 +-
 drivers/mfd/88pm805.c   |1 +
 include/linux/mfd/88pm80x.h |1 +
 3 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 73b2c9f..e1525ab 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -343,7 +343,7 @@ static int __devinit device_irq_init_800(struct pm80x_chip 
*chip)
ret =
regmap_add_irq_chip(chip->regmap, chip->irq, flags, -1,
chip->regmap_irq_chip, >irq_data);
-
+   chip->irq_base = regmap_irq_chip_get_base(chip->irq_data);
 out:
return ret;
 }
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index 7878013..8c9e25a 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -168,6 +168,7 @@ static int __devinit device_irq_init_805(struct pm80x_chip 
*chip)
ret =
regmap_add_irq_chip(chip->regmap, chip->irq, flags, -1,
chip->regmap_irq_chip, >irq_data);
+   chip->irq_base = regmap_irq_chip_get_base(chip->irq_data);
 out:
return ret;
 }
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index a0ca0dc..904efb9 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -303,6 +303,7 @@ struct pm80x_chip {
int id;
int irq;
int irq_mode;
+   int irq_base;
unsigned long wu_flag;
spinlock_t lock;
 };
-- 
1.7.0.4

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

[PATCH 4/4] rtc: 88pm80x: update irq base

[Qing Xu]

From: Qing Xu 

irq base is stored in 88pm80x's drv data, we need to add irq
base to get the correct irq num

Signed-off-by: Qiao Zhou 
Signed-off-by: Qing Xu 
---
 drivers/rtc/rtc-88pm80x.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index 6367984..7c3a264 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -256,7 +256,7 @@ static int __devinit pm80x_rtc_probe(struct platform_device 
*pdev)
struct pm80x_rtc_info *info;
struct rtc_time tm;
unsigned long ticks = 0;
-   int ret;
+   int irq, ret;
 
pdata = pdev->dev.platform_data;
if (pdata == NULL)
@@ -266,12 +266,13 @@ static int __devinit pm80x_rtc_probe(struct 
platform_device *pdev)
devm_kzalloc(>dev, sizeof(struct pm80x_rtc_info), GFP_KERNEL);
if (!info)
return -ENOMEM;
-   info->irq = platform_get_irq(pdev, 0);
-   if (info->irq < 0) {
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
dev_err(>dev, "No IRQ resource!\n");
ret = -EINVAL;
goto out;
}
+   info->irq = irq + chip->irq_base;
 
info->chip = chip;
info->map = chip->regmap;
-- 
1.7.0.4

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

Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

[Chao Xie]

On Mon, Dec 3, 2012 at 1:35 PM, Haojian Zhuang  wrote:
> On Mon, Dec 3, 2012 at 10:53 AM, Chao Xie  wrote:
>> On Mon, Dec 3, 2012 at 9:39 AM, Chao Xie  wrote:
>>> On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
>>>  wrote:
 On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
  wrote:
> On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
>> The original sa1100_rtc_open/sa1100_rtc_release will be called
>> when the /dev/rtc0 is opened or closed.
>> In fact, these two functions will enable/disable the clock, and
>> register/unregister the irqs.
>> User application will use /dev/rtc0 to read the rtc time or set
>> the alarm. The rtc should still run indepent of open/close the
>> rtc device.
>> So only enable clock and register the irqs when probe the device,
>> and disable clock and unregister the irqs when remove the device.
>
> NAK.  I don't think you properly understand what's going on here if you
> think moving the entire open and release functions into the probe and
> remove functions is the right thing to do.

 Since PXA27x & PXA3xx supports dual rtc device at the same time,
 user could choose use either of rtc at run time. Then clk & irq are setup
 in open().

 Chao,
 So you shouldn't remove them into probe().
>>>
>>> How can user to choose one RTC?
>>> The user API, for example "date" will open the device, get the time
>>> and then close the device.
>>> WHen set a alarm, it is the same routine. open->set->close.
>>> The open routine will enable clock and register irq, close will
>>> disable the clock and unregister irq. It means that if only open is
>>> invoked, rtc begins to work, and after close is invoked rtc stops
>>> working. It means that the user can not get correct time and can not
>>> get right alarm.
>>
>> hi
>> I want to correct what i said. For the irq register/unregister i think
>> can be done at open/release. But for clock enable/disable, i do not
>> think so. If clock is disabled, as i think RTC will not work. User API
>> still use open->get_time->close for "date" command. It means that RTC
>> will not return correct date to user.
>
> I didn't get your point. Do you mean that RTC can't work without your patch?
hi
open/release will done two things
1. enable/disable clock
2. register/unregister the irq
i checked the rtc dev code. register/unregister irq is prefered to be
done at open/release routine, and the users will keep rtc to be opened
if he want to make use of the interrupts.
the only problemis the clock. It should be on always.
If user want to get the rtc value, or set alarm. it will  follow
open->ioctrl->release. After release the clock is offed, and i do not
think rtc will has its value updated if the clock is offed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] onkey: 88pm80x: update irq base

[Qing Xu]

From: Qing Xu 

irq base is stored in 88pm80x's drv data, we need to add irq
base to get the correct irq num

Signed-off-by: Qiao Zhou 
Signed-off-by: Qing Xu 
---
 drivers/input/misc/88pm80x_onkey.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/88pm80x_onkey.c 
b/drivers/input/misc/88pm80x_onkey.c
index 7f26e7b..cc352f9 100644
--- a/drivers/input/misc/88pm80x_onkey.c
+++ b/drivers/input/misc/88pm80x_onkey.c
@@ -67,7 +67,7 @@ static int __devinit pm80x_onkey_probe(struct platform_device 
*pdev)
 
struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
struct pm80x_onkey_info *info;
-   int err;
+   int irq, err;
 
info = kzalloc(sizeof(struct pm80x_onkey_info), GFP_KERNEL);
if (!info)
@@ -75,13 +75,14 @@ static int __devinit pm80x_onkey_probe(struct 
platform_device *pdev)
 
info->pm80x = chip;
 
-   info->irq = platform_get_irq(pdev, 0);
-   if (info->irq < 0) {
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
dev_err(>dev, "No IRQ resource!\n");
err = -EINVAL;
goto out;
}
 
+   info->irq = irq + chip->irq_base;
info->map = info->pm80x->regmap;
if (!info->map) {
dev_err(>dev, "no regmap!\n");
-- 
1.7.0.4

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

[PATCH 2/4] mfd: 88pm80x: move to regmap irq base implementation

[Qing Xu]

From: Qing Xu 

get irq_base for mfd sub-device

Signed-off-by: Qiao Zhou 
Signed-off-by: Qing Xu 
---
 drivers/mfd/88pm800.c   |2 +-
 drivers/mfd/88pm805.c   |1 +
 include/linux/mfd/88pm80x.h |1 +
 3 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 73b2c9f..e1525ab 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -343,7 +343,7 @@ static int __devinit device_irq_init_800(struct pm80x_chip 
*chip)
ret =
regmap_add_irq_chip(chip->regmap, chip->irq, flags, -1,
chip->regmap_irq_chip, >irq_data);
-
+   chip->irq_base = regmap_irq_chip_get_base(chip->irq_data);
 out:
return ret;
 }
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index 7878013..8c9e25a 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -168,6 +168,7 @@ static int __devinit device_irq_init_805(struct pm80x_chip 
*chip)
ret =
regmap_add_irq_chip(chip->regmap, chip->irq, flags, -1,
chip->regmap_irq_chip, >irq_data);
+   chip->irq_base = regmap_irq_chip_get_base(chip->irq_data);
 out:
return ret;
 }
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index a0ca0dc..904efb9 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -303,6 +303,7 @@ struct pm80x_chip {
int id;
int irq;
int irq_mode;
+   int irq_base;
unsigned long wu_flag;
spinlock_t lock;
 };
-- 
1.7.0.4

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

[PATCH 1/4] mfd: 88pm80x: fix regmap not init before used

[Qing Xu]

From: Qing Xu 

1.put the pm800_page_init before 800_init, otherwise power and
gpadc regmap handle are not inited before being used.
2.remove regmap exit, as it will be called in driver release
3.add lost "return 0" in probe()
4.update driver's name

Signed-off-by: Qiao Zhou 
Signed-off-by: Qing Xu 
---
 drivers/mfd/88pm800.c |   25 -
 drivers/mfd/88pm805.c |5 +++--
 drivers/mfd/88pm80x.c |2 +-
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index ce229ea..73b2c9f 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -401,9 +401,6 @@ static void pm800_pages_exit(struct pm80x_chip *chip)
 {
struct pm80x_subchip *subchip;
 
-   regmap_exit(chip->regmap);
-   i2c_unregister_device(chip->client);
-
subchip = chip->subchip;
if (subchip->power_page) {
regmap_exit(subchip->regmap_power);
@@ -413,6 +410,7 @@ static void pm800_pages_exit(struct pm80x_chip *chip)
regmap_exit(subchip->regmap_gpadc);
i2c_unregister_device(subchip->gpadc_page);
}
+   i2c_unregister_device(chip->client);
 }
 
 static int __devinit device_800_init(struct pm80x_chip *chip,
@@ -528,25 +526,26 @@ static int __devinit pm800_probe(struct i2c_client 
*client,
subchip->gpadc_page_addr = pdata->gpadc_page_addr;
chip->subchip = subchip;
 
-   ret = device_800_init(chip, pdata);
-   if (ret) {
-   dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
-   goto err_800_init;
-   }
-
ret = pm800_pages_init(chip);
if (ret) {
dev_err(>dev, "pm800_pages_init failed!\n");
goto err_page_init;
}
 
+   ret = device_800_init(chip, pdata);
+   if (ret) {
+   dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
+   goto err_800_init;
+   }
+
if (pdata->plat_config)
pdata->plat_config(chip, pdata);
 
-err_page_init:
-   mfd_remove_devices(chip->dev);
-   device_irq_exit_800(chip);
+   return 0;
+
 err_800_init:
+   pm800_pages_exit(chip);
+err_page_init:
devm_kfree(>dev, subchip);
 err_subchip_alloc:
pm80x_deinit(client);
@@ -571,7 +570,7 @@ static int __devexit pm800_remove(struct i2c_client *client)
 
 static struct i2c_driver pm800_driver = {
.driver = {
-   .name = "88PM80X",
+   .name = "88PM800",
.owner = THIS_MODULE,
.pm = _pm_ops,
},
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index c20a311..7878013 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -168,7 +168,6 @@ static int __devinit device_irq_init_805(struct pm80x_chip 
*chip)
ret =
regmap_add_irq_chip(chip->regmap, chip->irq, flags, -1,
chip->regmap_irq_chip, >irq_data);
-
 out:
return ret;
 }
@@ -256,6 +255,8 @@ static int __devinit pm805_probe(struct i2c_client *client,
if (pdata->plat_config)
pdata->plat_config(chip, pdata);
 
+   return 0;
+
 err_805_init:
pm80x_deinit(client);
 out_init:
@@ -276,7 +277,7 @@ static int __devexit pm805_remove(struct i2c_client *client)
 
 static struct i2c_driver pm805_driver = {
.driver = {
-   .name = "88PM80X",
+   .name = "88PM805",
.owner = THIS_MODULE,
.pm = _pm_ops,
},
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index cd0bf52..1adb355 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -31,7 +31,7 @@ const struct regmap_config pm80x_regmap_config = {
 };
 EXPORT_SYMBOL_GPL(pm80x_regmap_config);
 
-int __devinit pm80x_init(struct i2c_client *client,
+int pm80x_init(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
struct pm80x_chip *chip;
-- 
1.7.0.4

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

Re: [patch] Re: [RFC GIT PULL] scheduler fix for autogroups

[Ingo Molnar]

* Mike Galbraith  wrote:

> > Willing to write a changelog with the pointer to the actual 
> > oops that happens due to this issue?
> 
> I don't have a link, so reproduced/captured it.  With 
> systemd-sysvinit (bleh) installed, it's trivial to reproduce:
> 
> Add echo 0 > /proc/sys/kernel/sched_autogroup_enabled to /root/.bashrc
> (or wherever), boot box, type reboot, box explodes.
> 
> revert 800d4d30 sched, autogroup: Stop going ahead if autogroup is disabled
> 
> Between 8323f26ce and 800d4d30, autogroup is a wreck.  With both

Slightly decoded, for our human readers:

 8323f26ce342 ("sched: Fix race in task_group()")

:-)

> applied, all you have to do to crash a box is disable autogroup
> during boot up, then reboot.. boom, NULL pointer dereference due
> to 800d4d30 not allowing autogroup to move things, and 8323f26ce
> making that the only way to switch runqueues.
> 
> [  202.187747] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [  202.191644] IP: [] effective_load.isra.43+0x50/0x90
> [  202.191644] PGD 220a74067 PUD 220402067 PMD 0 
> [  202.191644] Oops:  [#1] SMP 
> [  202.191644] Modules linked in: nfs nfsd fscache lockd nfs_acl auth_rpcgss 
> sunrpc exportfs bridge stp cpufreq_conservative cpufreq_ondemand 
> cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf ext3 jbd fuse 
> nls_iso8859_1 snd_hda_codec_realtek nls_cp437 snd_hda_intel vfat fat 
> snd_hda_codec e1000e sr_mod snd_hwdep cdrom snd_pcm sg snd_timer usb_storage 
> snd firewire_ohci usb_libusual firewire_core soundcore uas snd_page_alloc 
> i2c_i801 coretemp edd microcode hid_generic button crc_itu_t ipv6 autofs4 
> ext4 mbcache jbd2 crc16 usbhid hid sd_mod uhci_hcd ahci libahci libata 
> rtc_cmos ehci_hcd scsi_mod thermal fan usbcore processor usb_common
> [  202.191644] CPU 0 
> [  202.191644] Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 
> MEDIONPC MS-7502/MS-7502
> [  202.191644] RIP: 0010:[]  [] 
> effective_load.isra.43+0x50/0x90
> [  202.191644] RSP: 0018:880221ddfbd8  EFLAGS: 00010086
> [  202.191644] RAX: 0400 RBX: 88022621d880 RCX: 
> 
> [  202.191644] RDX:  RSI: 0002 RDI: 
> 880220a363a0
> [  202.191644] RBP: 880221ddfbd8 R08: 0400 R09: 
> 000115c0
> [  202.191644] R10:  R11: 0400 R12: 
> 8802214ed180
> [  202.191644] R13: 03fd R14:  R15: 
> 0003
> [  202.191644] FS:  7f174a81c7a0() GS:88022fc0() 
> knlGS:
> [  202.191644] CS:  0010 DS:  ES:  CR0: 80050033
> [  202.191644] CR2:  CR3: 000221fad000 CR4: 
> 07f0
> [  202.191644] DR0:  DR1:  DR2: 
> 
> [  202.191644] DR3:  DR6: 0ff0 DR7: 
> 0400
> [  202.191644] Process systemd-user-se (pid: 7047, threadinfo 
> 880221dde000, task 88022618b3a0)
> [  202.191644] Stack:
> [  202.191644]  880221ddfc88 81063d55 0400 
> 000115c0
> [  202.191644]  88022235c218 814ef9e8 ea00 
> 88022621d880
> [  202.191644]  880227007200 0003 0010 
> 00018f38
> [  202.191644] Call Trace:
> [  202.191644]  [] select_task_rq_fair+0x255/0x780
> [  202.191644]  [] try_to_wake_up+0x156/0x2c0
> [  202.191644]  [] wake_up_state+0xb/0x10
> [  202.191644]  [] signal_wake_up+0x28/0x40
> [  202.191644]  [] complete_signal+0x1d6/0x250
> [  202.191644]  [] __send_signal+0x170/0x310
> [  202.191644]  [] send_signal+0x40/0x80
> [  202.191644]  [] do_send_sig_info+0x47/0x90
> [  202.191644]  [] group_send_sig_info+0x4a/0x70
> [  202.191644]  [] kill_pid_info+0x3a/0x60
> [  202.191644]  [] sys_kill+0x97/0x1a0
> [  202.191644]  [] ? vfs_read+0x120/0x160
> [  202.191644]  [] ? sys_read+0x45/0x90
> [  202.191644]  [] system_call_fastpath+0x16/0x1b
> [  202.191644] Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 
> 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 
> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c 
> [  202.191644] RIP  [] effective_load.isra.43+0x50/0x90
> [  202.191644]  RSP 
> [  202.191644] CR2: 
> 
> Signed-off-by: Mike Galbraith 
> Cc: Yong Zhang 
> Cc: sta...@vger.kernel.org

Thanks Mike!

Acked-by: Ingo Molnar 

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

Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

[Haojian Zhuang]

On Mon, Dec 3, 2012 at 10:53 AM, Chao Xie  wrote:
> On Mon, Dec 3, 2012 at 9:39 AM, Chao Xie  wrote:
>> On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
>>  wrote:
>>> On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
>>>  wrote:
 On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
> The original sa1100_rtc_open/sa1100_rtc_release will be called
> when the /dev/rtc0 is opened or closed.
> In fact, these two functions will enable/disable the clock, and
> register/unregister the irqs.
> User application will use /dev/rtc0 to read the rtc time or set
> the alarm. The rtc should still run indepent of open/close the
> rtc device.
> So only enable clock and register the irqs when probe the device,
> and disable clock and unregister the irqs when remove the device.

 NAK.  I don't think you properly understand what's going on here if you
 think moving the entire open and release functions into the probe and
 remove functions is the right thing to do.
>>>
>>> Since PXA27x & PXA3xx supports dual rtc device at the same time,
>>> user could choose use either of rtc at run time. Then clk & irq are setup
>>> in open().
>>>
>>> Chao,
>>> So you shouldn't remove them into probe().
>>
>> How can user to choose one RTC?
>> The user API, for example "date" will open the device, get the time
>> and then close the device.
>> WHen set a alarm, it is the same routine. open->set->close.
>> The open routine will enable clock and register irq, close will
>> disable the clock and unregister irq. It means that if only open is
>> invoked, rtc begins to work, and after close is invoked rtc stops
>> working. It means that the user can not get correct time and can not
>> get right alarm.
>
> hi
> I want to correct what i said. For the irq register/unregister i think
> can be done at open/release. But for clock enable/disable, i do not
> think so. If clock is disabled, as i think RTC will not work. User API
> still use open->get_time->close for "date" command. It means that RTC
> will not return correct date to user.

I didn't get your point. Do you mean that RTC can't work without your patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

[Haojian Zhuang]

On Mon, Dec 3, 2012 at 9:39 AM, Chao Xie  wrote:
> On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
>  wrote:
>> On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
>>  wrote:
>>> On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
 The original sa1100_rtc_open/sa1100_rtc_release will be called
 when the /dev/rtc0 is opened or closed.
 In fact, these two functions will enable/disable the clock, and
 register/unregister the irqs.
 User application will use /dev/rtc0 to read the rtc time or set
 the alarm. The rtc should still run indepent of open/close the
 rtc device.
 So only enable clock and register the irqs when probe the device,
 and disable clock and unregister the irqs when remove the device.
>>>
>>> NAK.  I don't think you properly understand what's going on here if you
>>> think moving the entire open and release functions into the probe and
>>> remove functions is the right thing to do.
>>
>> Since PXA27x & PXA3xx supports dual rtc device at the same time,
>> user could choose use either of rtc at run time. Then clk & irq are setup
>> in open().
>>
>> Chao,
>> So you shouldn't remove them into probe().
>
> How can user to choose one RTC?

/dev/rtc0 & /dev/rtc1.

The user can choose the rtc by iteself. Is it right?

> The user API, for example "date" will open the device, get the time
> and then close the device.

"date" command is always using /dev/rtc. It's the alias of rtc0 or rtc1.

> WHen set a alarm, it is the same routine. open->set->close.
> The open routine will enable clock and register irq, close will
> disable the clock and unregister irq. It means that if only open is
> invoked, rtc begins to work, and after close is invoked rtc stops
> working. It means that the user can not get correct time and can not
> get right alarm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] EXTCON: Get and set cable properties

[anish kumar]

On Mon, 2012-12-03 at 01:53 +, Tc, Jenny wrote:
> > We discussed about this patch and then suggest some method to resolve this
> > issue by Myungjoo Ham. Why don't you write additional feature or your
> > opinion based on following patch by Myungjoo Ham?
> > -
> > http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commitdiff;h=73
> > 12b79d69a2b9f06af4f1254bc4644751e3e3ea
> > 
> 
> I replied on the thread and pointed out issues that I see with this solution. 
> IMHO
> It's not fair to register a cable with power_supply/regulator/charger manager 
> just to
> expose the cable properties. 
Don't we do that with already in allmost all drivers?Like if I have a
keyboard driver and then I register with input framework and if the
keyboard driver needs clk services then I register with clk framework as
well and same with other services needed by keyboard driver.I think it
makes sense for a cable to register with different framework if it
supports that functionality as those services also would know that we
have a cable with so and so property.
> 
> > 
> > On 11/28/2012 06:49 AM, Jenny TC wrote:
> > > Existing EXTCON implementation doesn't give a mechanim to read the
> > > cable properties and extra states a cable needs to support. There are
> > > scenarios where a cable can have more than two
> > > states(CONNECT/DISCONNECT/SUSPEND/RESUME etc) and can have some
> > > properties associated with cables(mA)
> > >
> > > This patch introduces interface to get and set cable properties from
> > > EXTCON framework. The cable property can be set either by the extcon
> > > cable provider or by other subsystems who know the cable properties
> > > using eth API extcon_cable_set_data()
> > >
> > > When the consumer gets a notification from the extcon, it can use the
> > > extcon_cable_get_data() to get the cable properties irrespective of
> > > who provides the cable data.
> > >
> > > This gives a single interface for setting and getting the cable 
> > > properties.
> > >
> > > Signed-off-by: Jenny TC 
> > > ---
> > >  drivers/extcon/extcon-class.c |   30
> > ++
> > >  include/linux/extcon.h|   39
> > +++
> > >  2 files changed, 69 insertions(+)
> > >
> > > diff --git a/drivers/extcon/extcon-class.c
> > > b/drivers/extcon/extcon-class.c index d398821..304f343 100644
> > > --- a/drivers/extcon/extcon-class.c
> > > +++ b/drivers/extcon/extcon-class.c
> > > @@ -545,6 +545,36 @@ int extcon_unregister_notifier(struct extcon_dev
> > > *edev,  }  EXPORT_SYMBOL_GPL(extcon_unregister_notifier);
> > >
> > > +/**
> > > + * extcon_cable_set_data() - Set the data structure for a cable
> > > + * @edev:the extcon device
> > > + * @cable_index: the cable index of the correspondant
> > > + * @type:type of the data structure
> > > + * @data:
> > > + */
> > > +void extcon_cable_set_data(struct extcon_dev *edev, int cable_index,
> > > +enum extcon_cable_name type,
> > > +union extcon_cable_data data)
> > > +{
> > > + edev->cables[cable_index].type = type;
> > > + edev->cables[cable_index].data = data; }
> > > +
> > > +/**
> > > + * extcon_cable_get_data() - Get the data structure for a cable
> > > + * @edev:the extcon device
> > > + * @cable_index: the cable index of the correspondant
> > > + * @type:type of the data structure
> > > + * @data:the corresponding data structure (e.g., regulator)
> > > + */
> > > +void extcon_cable_get_data(struct extcon_dev *edev, int cable_index,
> > > +enum extcon_cable_name *type,
> > > +union extcon_cable_data *data)
> > > +{
> > > + *type = edev->cables[cable_index].type;
> > > + *data = edev->cables[cable_index].data; }
> > > +
> > >  static struct device_attribute extcon_attrs[] = {
> > >   __ATTR(state, S_IRUGO | S_IWUSR, state_show, state_store),
> > >   __ATTR_RO(name),
> > > diff --git a/include/linux/extcon.h b/include/linux/extcon.h index
> > > 2c26c14..4556cc5 100644
> > > --- a/include/linux/extcon.h
> > > +++ b/include/linux/extcon.h
> > > @@ -135,6 +135,19 @@ struct extcon_dev {
> > >   struct device_attribute *d_attrs_muex;  };
> > >
> > > +/* FIXME: Is this the right place for this structure definition?
> > > + * Do we need to move it to power_supply.h?
> > > + */
> > > +struct extcon_chrgr_cable_props {
> > > + unsigned long state;
> > > + int mA;
> > > +};
> > 
> > As I said, extcon provider driver didn't provide directly charging 
> > current(int
> > mA) and some state(unsigned long state) because the extcon provider
> > driver(Micro USB interface controller device or other device related to
> > external connector) haven't mechanism which detect dynamically charging
> > current immediately. If you wish to provide charging current data to extcon
> > consumer driver or framework, you should use regulator/power_supply
> > framework or other method in extcon provider driver.
> > 
> > The patch 

Re: [GIT PULL rcu/next] RCU commits for 3.8

[Ingo Molnar]

* Paul E. McKenney  wrote:

> Hello, Ingo,
> 
> The major features of this series are:
> 
> 1.A first version of no-callbacks CPUs.  This version prohibits
>   offlining CPU 0, but only when enabled via CONFIG_RCU_NOCB_CPU=y.
>   Relaxing this constraint is in progress, but not yet ready
>   for prime time.  These commits were posted to LKML at
>   https://lkml.org/lkml/2012/10/30/724, and are at branch rcu/nocb.
> 
> 2.Changes to SRCU that allows statically initialized srcu_struct
>   structures.  These commits were posted to LKML at
>   https://lkml.org/lkml/2012/10/30/296, and are at branch rcu/srcu.
> 
> 3.Restructuring of RCU's debugfs output.  These commits were posted
>   to LKML at https://lkml.org/lkml/2012/10/30/341, and are at
>   branch rcu/tracing.
> 
> 4.Additional CPU-hotplug/RCU improvements, posted to LKML at
>   https://lkml.org/lkml/2012/10/30/327, and are at branch rcu/hotplug.
>   Note that the commit eliminating __stop_machine() was judged to
>   be too-high of risk, so is deferred to 3.9.
> 
> 5.Changes to RCU's idle interface, most notably a new module
>   parameter that redirects normal grace-period operations to
>   their expedited equivalents.  These were posted to LKML at
>   https://lkml.org/lkml/2012/10/30/739, and are at branch rcu/idle.
> 
> 6.Additional diagnostics for RCU's CPU stall warning facility,
>   posted to LKML at https://lkml.org/lkml/2012/10/30/315, and
>   are at branch rcu/stall.  The most notable change reduces the
>   default RCU CPU stall-warning time from 60 seconds to 21 seconds,
>   so that it once again happens sooner than the softlockup timeout.
> 
> 7.Documentation updates, which were posted to LKML at
>   https://lkml.org/lkml/2012/10/30/280, and are at branch rcu/doc.
>   A couple of late-breaking changes were posted at
>   https://lkml.org/lkml/2012/11/16/634 and
>   https://lkml.org/lkml/2012/11/16/547.
> 
> 8.Miscellaneous fixes, which were posted to LKML at
>   https://lkml.org/lkml/2012/10/30/309, along with a late-breaking
>   change posted at Fri, 16 Nov 2012 11:26:25 -0800 with message-ID
>   <20121116192625.ga...@linux.vnet.ibm.com>, but which lkml.org
>   seems to have missed.  These are at branch rcu/fixes.
> 
> 9.Finally, a fix for an lockdep-RCU splat was posted to LKML
>   at https://lkml.org/lkml/2012/11/7/486.  This is at rcu/next.
> 
> All executable code in these commits have been subject to -next testing.
> (Fixes to trailing whitespace problems in one of the Documentation files
> has not yet been, but as far as I know -next testing does not do anything
> with Documentation files -- and testing will happen as soon as -next testing
> restarts.)
> 
> These changes are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
> 
>   Thanx, Paul
> 
> -->
> Antti P Miettinen (1):
>   rcu: Add a module parameter to force use of expedited RCU primitives
> 
> Dhaval Giani (1):
>   rcu: Correct the name of a reference in list of RCU papers
> 
> Eric Dumazet (1):
>   rcu: Fix batch-limit size problem
> 
> Frederic Weisbecker (2):
>   rcu: Remove rcu_switch()
>   rcu: Fix unrecovered RCU user mode in syscall_trace_leave()
> 
> Kees Cook (1):
>   rcu: Update docs to include kfree_rcu()
> 
> Lai Jiangshan (4):
>   srcu: Credit Lai Jiangshan with SRCU rewrite
>   srcu: Export process_srcu()
>   srcu: Add DEFINE_SRCU()
>   rcutorture: Use DEFINE_STATIC_SRCU()
> 
> Michael Wang (12):
>   rcu: Create directory for each flavor of rcu
>   rcu: Fundamental facility for 'CPU units sequence reading'
>   rcu: Optimize the 'rcudata' for RCU trace
>   rcu: Optimize the 'rcudata.csv' for RCU trace
>   rcu: Optimize the 'rcu_pending' for RCU trace
>   rcu: Replace the old interface with the new one
>   rcu: Remove the interface "rcudata.csv"
>   rcu: split 'rcubarrier' to each flavor
>   rcu: split 'rcuboost' to each flavor
>   rcu: split 'rcugp' to each flavor
>   rcu: split 'rcuhier' to each flavor
>   rcu: Remove old debugfs interfaces and also RCU flavor name
> 
> Paul E. McKenney (27):
>   rcu: Accelerate callbacks for CPU initiating a grace period
>   Documentation: Fix memory-barriers.txt example
>   rcu: Fix comment about _rcu_barrier()/orphanage exclusion
>   rcu: Make rcutorture give diagnostics if CPU offline fails
>   rcu: Update RCU_FAST_NO_HZ help text
>   rcu: Fix precedence error in cpu_needs_another_gp()
>   rcu: Print remote CPU's stacks in stall warnings
>   rcu: Add grace-period information to RCU CPU stall warnings
>   rcu: Dump number of callbacks in stall warning messages
>   rcu: Document alternative RCU/reference-count algorithms
>   

[patch] Re: [RFC GIT PULL] scheduler fix for autogroups

[Mike Galbraith]

On Sun, 2012-12-02 at 11:36 -0800, Linus Torvalds wrote: 
> On Sun, Dec 2, 2012 at 11:27 AM, Ingo Molnar  wrote:
> >
> > * Mike Galbraith  wrote:
> >
> >> On Sat, 2012-12-01 at 22:44 +0100, Ingo Molnar wrote:
> >>
> >> > Should we use some other file for that - or no file at all and
> >> > just emit a bootup printk for kernel hackers with a short
> >> > attention span?
> >>
> >> Or, whack the file and don't bother with a printk either.  If
> >> it's in your config, and your command line doesn't contain
> >> noautogroup, it's on, so the info is already present (until
> >> buffer gets full).  That makes for even fewer lines dedicated
> >> to dinky sideline feature.
> >>
> >> Or (as previously mentioned) just depreciate (or rip out) the
> >> whole thing since systemd is propagating everywhere anyway,
> >> and offers the same functionality.
> >>
> >> For 3.7, a revert of 800d4d30c8f2 would prevent the explosion
> >> when folks play with the now non-functional on/off switch
> >> (task groups are required to _always_ exist, that commit
> >> busted the autogroup assumption), so is perhaps a viable
> >> quickfix until autogroups fate is decided?
> >
> > Linus, which one would be your preference? I'm fine with the
> > first and third options - #2 that rips it all out looks like
> > a sad removal of an otherwise useful feature.
> 
> I suspect #3 is the best option right now - just revert 800d4d30c8f2.
> 
> Willing to write a changelog with the pointer to the actual oops that
> happens due to this issue?

I don't have a link, so reproduced/captured it.  With systemd-sysvinit
(bleh) installed, it's trivial to reproduce:

Add echo 0 > /proc/sys/kernel/sched_autogroup_enabled to /root/.bashrc
(or wherever), boot box, type reboot, box explodes.

revert 800d4d30 sched, autogroup: Stop going ahead if autogroup is disabled

Between 8323f26ce and 800d4d30, autogroup is a wreck.  With both
applied, all you have to do to crash a box is disable autogroup
during boot up, then reboot.. boom, NULL pointer dereference due
to 800d4d30 not allowing autogroup to move things, and 8323f26ce
making that the only way to switch runqueues.

[  202.187747] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[  202.191644] IP: [] effective_load.isra.43+0x50/0x90
[  202.191644] PGD 220a74067 PUD 220402067 PMD 0 
[  202.191644] Oops:  [#1] SMP 
[  202.191644] Modules linked in: nfs nfsd fscache lockd nfs_acl auth_rpcgss 
sunrpc exportfs bridge stp cpufreq_conservative cpufreq_ondemand 
cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf ext3 jbd fuse 
nls_iso8859_1 snd_hda_codec_realtek nls_cp437 snd_hda_intel vfat fat 
snd_hda_codec e1000e sr_mod snd_hwdep cdrom snd_pcm sg snd_timer usb_storage 
snd firewire_ohci usb_libusual firewire_core soundcore uas snd_page_alloc 
i2c_i801 coretemp edd microcode hid_generic button crc_itu_t ipv6 autofs4 ext4 
mbcache jbd2 crc16 usbhid hid sd_mod uhci_hcd ahci libahci libata rtc_cmos 
ehci_hcd scsi_mod thermal fan usbcore processor usb_common
[  202.191644] CPU 0 
[  202.191644] Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 
MEDIONPC MS-7502/MS-7502
[  202.191644] RIP: 0010:[]  [] 
effective_load.isra.43+0x50/0x90
[  202.191644] RSP: 0018:880221ddfbd8  EFLAGS: 00010086
[  202.191644] RAX: 0400 RBX: 88022621d880 RCX: 
[  202.191644] RDX:  RSI: 0002 RDI: 880220a363a0
[  202.191644] RBP: 880221ddfbd8 R08: 0400 R09: 000115c0
[  202.191644] R10:  R11: 0400 R12: 8802214ed180
[  202.191644] R13: 03fd R14:  R15: 0003
[  202.191644] FS:  7f174a81c7a0() GS:88022fc0() 
knlGS:
[  202.191644] CS:  0010 DS:  ES:  CR0: 80050033
[  202.191644] CR2:  CR3: 000221fad000 CR4: 07f0
[  202.191644] DR0:  DR1:  DR2: 
[  202.191644] DR3:  DR6: 0ff0 DR7: 0400
[  202.191644] Process systemd-user-se (pid: 7047, threadinfo 880221dde000, 
task 88022618b3a0)
[  202.191644] Stack:
[  202.191644]  880221ddfc88 81063d55 0400 
000115c0
[  202.191644]  88022235c218 814ef9e8 ea00 
88022621d880
[  202.191644]  880227007200 0003 0010 
00018f38
[  202.191644] Call Trace:
[  202.191644]  [] select_task_rq_fair+0x255/0x780
[  202.191644]  [] try_to_wake_up+0x156/0x2c0
[  202.191644]  [] wake_up_state+0xb/0x10
[  202.191644]  [] signal_wake_up+0x28/0x40
[  202.191644]  [] complete_signal+0x1d6/0x250
[  202.191644]  [] __send_signal+0x170/0x310
[  202.191644]  [] send_signal+0x40/0x80
[  202.191644]  [] do_send_sig_info+0x47/0x90
[  202.191644]  [] group_send_sig_info+0x4a/0x70
[  202.191644]  [] kill_pid_info+0x3a/0x60
[  202.191644]  [] sys_kill+0x97/0x1a0
[  

Re: [PATCH 00/52] RFC: Unified NUMA balancing tree, v1

[Ingo Molnar]

The unified NUMA Git tree can be found in the -tip numa/base 
branch:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git numa/base

The PROT_NONE -v18 numa/core tree can be found in tip:master:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master

Thanks,

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

Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

[devendra.aaru]

CCing Andrew as he is the maintainer of the rtc subsystem

On Wed, Nov 28, 2012 at 9:21 PM, Chao Xie  wrote:
> The original sa1100_rtc_open/sa1100_rtc_release will be called
> when the /dev/rtc0 is opened or closed.
> In fact, these two functions will enable/disable the clock, and
> register/unregister the irqs.
> User application will use /dev/rtc0 to read the rtc time or set
> the alarm. The rtc should still run indepent of open/close the
> rtc device.
> So only enable clock and register the irqs when probe the device,
> and disable clock and unregister the irqs when remove the device.
>
> Signed-off-by: Chao Xie 
> ---
>  drivers/rtc/rtc-sa1100.c |9 +++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
> index 50a5c4a..e933327 100644
> --- a/drivers/rtc/rtc-sa1100.c
> +++ b/drivers/rtc/rtc-sa1100.c
> @@ -218,8 +218,6 @@ static int sa1100_rtc_proc(struct device *dev, struct 
> seq_file *seq)
>  }
>
>  static const struct rtc_class_ops sa1100_rtc_ops = {
> -   .open = sa1100_rtc_open,
> -   .release = sa1100_rtc_release,
> .read_time = sa1100_rtc_read_time,
> .set_time = sa1100_rtc_set_time,
> .read_alarm = sa1100_rtc_read_alarm,
> @@ -253,6 +251,10 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
> spin_lock_init(>lock);
> platform_set_drvdata(pdev, info);
>
> +   ret = sa1100_rtc_open(>dev);
> +   if (ret)
> +   goto err_open;
> +
> /*
>  * According to the manual we should be able to let RTTR be zero
>  * and then a default diviser for a 32.768KHz clock is used.
> @@ -305,7 +307,9 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
>
> return 0;
>  err_dev:
> +   sa1100_rtc_release(>dev);
> platform_set_drvdata(pdev, NULL);
> +err_open:
> clk_put(info->clk);
>  err_clk:
> kfree(info);
> @@ -318,6 +322,7 @@ static int sa1100_rtc_remove(struct platform_device *pdev)
>
> if (info) {
> rtc_device_unregister(info->rtc);
> +   sa1100_rtc_release(>dev);
> clk_put(info->clk);
> platform_set_drvdata(pdev, NULL);
> kfree(info);
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4]menuconfig: Add Save button

[Wang YanQing]

Hi Yann, All,

On Sun, Dec 02, 2012 at 06:52:50PM +0100, Yann E. MORIN wrote:
> To make the behavior consistent, may I suggest that you push the
> concept even a bit further:
>   - add a "Load" *and* a "Save" buttons
>   - get rid of the top-level "Load an Alternate Configuration File"
> and "Save an Alternate Configuration File" entries
> 
> For the "Save" and "Load" buttons, please mimick how the nconf frontend
> behaves: prompt for the file to save to/load from, and prefill it with
> the last filename that was entered (".config" per default).
> 
> Of course, two patches for that: one for the "Save/Load" buttons, one
> to get rid of the top-level entries afterward.
Thanks, very good suggestion, I will jump in.

> Note: I do not state that your use-case is valid or not. That's your
> call how you configure and test your kernel. However, I think that
> having a consistent behavior across the frontends is a very nice goal
> to pursue.
I understand, I make a mistake in the comment in previous Email.

> See other comments in-lined, below.
> 
> > V1-V2: Rewrite the most code to make it more correct
> > V2-V3: Fix the behavior of conf_message_callback when exit.
> > V3-V4:
> > 1: Move Buttons a little left to make them look like symmetrical.
> > 2: Exchange the position between Save button and Exit button.
> > 3: Use conf_save instead of conf_write to make we can save
> > an alternate configuration file with Save button.
> > 
> > Signed-off-by: Wang YanQing 
> > ---
> >  scripts/kconfig/lxdialog/menubox.c | 21 +-
> >  scripts/kconfig/mconf.c| 45 
> > ++
> >  2 files changed, 47 insertions(+), 19 deletions(-)
> > 
> > diff --git a/scripts/kconfig/lxdialog/menubox.c 
> > b/scripts/kconfig/lxdialog/menubox.c
> > index 1d60473..b445bda 100644
> > --- a/scripts/kconfig/lxdialog/menubox.c
> > +++ b/scripts/kconfig/lxdialog/menubox.c
> > @@ -26,7 +26,7 @@
> >   *
> >   **)  A bugfix for the Page-Down problem
> >   *
> > - **)  Formerly when I used Page Down and Page Up, the cursor would be 
> > set 
> > + **)  Formerly when I used Page Down and Page Up, the cursor would be 
> > set
> 
> Space-damage. Don't send trailing-space fixes, or at least add a quick
> note for it at the end of the commit log (eg.: "remove trailing space
> while at it").
Ok, it is right.

Thanks Yann E. MORIN, and All

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Capabilities still can't be inherited by normal programs

[Andy Lutomirski]

On Sun, Dec 2, 2012 at 6:20 PM, Andrew G. Morgan  wrote:
> On Sun, Dec 2, 2012 at 3:04 PM, Andy Lutomirski  wrote:
>> On Sun, Dec 2, 2012 at 2:26 PM, Andrew G. Morgan  wrote:
>>> On Sun, Dec 2, 2012 at 10:35 AM, Andy Lutomirski  
>>> wrote:
 On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan  wrote:
> There is a fairly well written paper ;-) explaining how things are
> supposed to work:
>
>   http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf
>
> The inheritable set is not intended to work the way you seem to want.
> Naive inheritance like that is quite explicitly the opposite of what
> was designed.

 I'm aware that the system was designed, or perhaps evolved, to prevent
 users with uid != 0 from inheriting capabilities unless vfs
 inheritable caps are granted on a per-file basis.  I want a way around
 that -- I want to mix non-root, capabilities, and exec.  This is damn
 near impossible right now if I don't have CAP_SETFCAP or root's
 explicit, per-program cooperation.  CAP_SETFCAP is essentially
 equivalent to "let me do anything".

 As it stands, using something like pam_cap to grant a user cap_net_raw
 is useless -- that user can't use the privilege because (unless uid ==
 0) the privilege will never end up in the permitted set.
>>>
>>> Have you tried adding fI of cap_net_raw to the file to be executed?
>>
>> Yes, and it works.  I don't like this solution because:
>>
>> a) It doesn't scale in terms of sysadmin resources required.
>
> By doesn't scale, you mean it requires the admin to define which
> actual binaries on their system can wield privilege?

Yes.

>>
>> c) tcpdump isn't really special.  I trust this user account with
>> cap_net_raw, and that should be all the configuration I need.
>
> But this is a statement about access control, and not a statement
> about privilege. You trust the user to invoke something that can do
> tcpdump, you don't really trust the user to generate arbitrary packets
> on the network.

That *really* doesn't scale.  Suppose I trust one user to capture
packets and a second user to run portscans.  Setting tcpdump and nmap
as cap_net_raw+i and granting both users cap_net_raw (inheritable)
doesn't do it.  (Even ignoring the possibility of bugs in tcpdump and
nmap.)

In the immediate case that prompted this question, I only really trust
the user to run tcpdump, although I don't particularly care if they
generate arbitrary packets.  For simplicity, if I could use full
capability inheritance, I'd probably just grant cap_net_raw and be
done with it.  In this case, though, I have a helper that's ~50 lines
of code that has cap_net_raw=p.  It checks that it's happy about
what's going on, it does some apparmor twiddling (sigh), and it
execve's /usr/sbin/tcpdump.  And it only works because I set tcpdump
as cap_net_raw+i.

The ability to run helper programs is *useful*.  I find it rather
limiting that privileged programs that don't have uid=0 can't really
do it without administrative help.

>
>> d) If I really wanted, I could emulate execve without actually doing
>> execve, and capabilities would be inherited.
>
> If you could modify the executable properties of the binary that has
> the privilege to wield a privilege then you are either exploiting an
> app bug, or doing something the privileged binary has been trusted to
> do.

That's not what I mean.  I would:

fork()
munmap everything
mmap ld.so
set up a fake initial stack and the right fd or mapping or whatever
just to ld-linux.so

That's almost execve, and privilege inheritance works.

>
>> The issue with allowing real capability inheritance is that,
>> currently, it's safe for a program with fP != 0 to add an inheritable
>> capability and then execve something caller-controlled.  I don't know
>> whether anything actually does this, but it's hard to prove that
>> nothing does.  Hence my idea of requiring no_new_privs to make
>> capabilities inheritable.
>
> Assuming this is not another app bug, and that's what the executable
> with fP != 0 does, then that's why it was given fP != 0 - its what the
> program was designed to do. Why is this an issue?
>
>> An alternative, and considerably more intrusive, change would be to
>> add a fourth mask of genuinely inheritable capabilities.
>
> If you believe that you want to give a user the privilege to grant a
> privilege to an arbitrary binary to do things like this, why not write
> an app that adds file capabilities to target binaries owned by the
> user? You can make it execute-only by said user and let them do
> whatever they want. This requires no kernel changes.

Egads.  IMO that's way scarier.  I'd rather just mark ld.so as =i.

My point about no_new_privs is: if I trust a user or a program with a
capability, I probably also trust it to invoke helpers (via execve) as
it sees fit.  What I don't trust is everything else on the system that
has fP or set[ug]id bits set -- they probably 

Re: [PATCH] lxdialog:inputbox: Fix can't change selected button with Left/Right when input box selected

[Wang YanQing]

On Sun, Dec 02, 2012 at 06:32:43PM +0100, Yann E. MORIN wrote:
> Wang, All,
> 
> On Sunday 02 December 2012 Wang YanQing wrote:
> > inputbox code don't support use Left/Right to change input
> > position in the input box, so it use continue to skip them
> > when input key is Left/Right, but use break for Up/Down, so
> > we can change selected button with Up/Down but we can't do it
> > with Left/Right key when input box selected.
> > This patch fix it.
> 
> Although I do understand the motivation behind your change, may I suggest
> that left/right are used to navigate *inside* the input field, so it is
> possible to modify the text in place?
Hi Yann,All,
I understand what you say, and I also want inputbox support
changing input position with Left/Right. But this patch is accepted 
before somebody make it come true, right?

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/

[PATCH 1/1] regulator: new driver for LP8755

[Daniel Jeong]

From: Daniel Jeong 

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 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   |  553 ++
 include/linux/platform_data/lp8755.h |   72 +
 4 files changed, 635 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..00d0763
--- /dev/null
+++ b/drivers/regulator/lp8755.c
@@ -0,0 +1,553 @@
+/*
+ * LP8755 High Performance Power Management Unit : System Interface Driver
+ * (based on rev. 0)
+ * 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 
+
+#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_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];
+};
+
+static int lp8755_read(struct lp8755_chip *pchip, unsigned int reg,
+  unsigned int *val)
+{
+   return regmap_read(pchip->regmap, reg, val);
+}
+
+static int lp8755_write(struct lp8755_chip *pchip, unsigned int reg,
+   unsigned int val)
+{
+   return regmap_write(pchip->regmap, reg, val);
+}
+
+static int lp8755_buck_enable_time(struct regulator_dev *rdev)
+{
+   unsigned int regval;
+   enum lp8755_bucks id = rdev_get_id(rdev);
+   struct lp8755_chip *pchip = rdev_get_drvdata(rdev);
+
+   if (lp8755_read(pchip, 0x12 + id, ) < 0) {
+   dev_err(pchip->dev, "i2c acceess error %s\n", __func__);
+   return -EINVAL;
+   }
+   return (regval & 0xff) * 100;
+}
+
+static int lp8755_buck_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+   unsigned int regbval, regcval;
+   enum lp8755_bucks id = rdev_get_id(rdev);
+   struct lp8755_chip *pchip = rdev_get_drvdata(rdev);
+
+   if (lp8755_read(pchip, 0x06, ) < 0)
+   goto err_i2c;
+
+   switch (mode) {
+   case REGULATOR_MODE_FAST:
+   /* forced pwm mode */
+   regbval |= (0x01 << id);
+   break;
+   case REGULATOR_MODE_NORMAL:
+   /* enable automatic pwm/pfm mode */
+   regbval &= ~(0x01 << id);
+   if (lp8755_read(pchip, 0x08 + id, ) < 0)
+   goto err_i2c;
+   regcval &= ~0x20;
+   if 

[PATCH 0/1] regulator: new driver for LP8755

[Daniel Jeong]

From: Daniel Jeong 

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 be filexibly bundled
together in multiphase converters as required by application.

www.ti.com

Daniel Jeong (1):
  regulator: new driver for LP8755

 drivers/regulator/Kconfig|9 +
 drivers/regulator/Makefile   |1 +
 drivers/regulator/lp8755.c   |  553 ++
 include/linux/platform_data/lp8755.h |   72 +
 4 files changed, 635 insertions(+), 0 deletions(-)
 create mode 100644 drivers/regulator/lp8755.c
 create mode 100644 include/linux/platform_data/lp8755.h

-- 
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: [RFC PATCH v3 0/3] acpi: Introduce prepare_remove device operation

[Hanjun Guo]

On 2012/11/30 6:27, Toshi Kani wrote:
> On Thu, 2012-11-29 at 12:48 +0800, Hanjun Guo wrote:
>> On 2012/11/29 2:41, Toshi Kani wrote:
>>> On Wed, 2012-11-28 at 19:05 +0800, Hanjun Guo wrote:
 On 2012/11/24 1:50, Vasilis Liaskovitis wrote:
> As discussed in https://patchwork.kernel.org/patch/1581581/
> the driver core remove function needs to always succeed. This means we 
> need
> to know that the device can be successfully removed before acpi_bus_trim 
> / 
> acpi_bus_hot_remove_device are called. This can cause panics when 
> OSPM-initiated
> or SCI-initiated eject of memory devices fail e.g with:
> echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> since the ACPI core goes ahead and ejects the device regardless of 
> whether the
> the memory is still in use or not.
>
> For this reason a new acpi_device operation called prepare_remove is 
> introduced.
> This operation should be registered for acpi devices whose removal (from 
> kernel
> perspective) can fail.  Memory devices fall in this category.
>
> acpi_bus_remove() is changed to handle removal in 2 steps:
> - preparation for removal i.e. perform part of removal that can fail. 
> Should
>   succeed for device and all its children.
> - if above step was successfull, proceed to actual device removal

 Hi Vasilis,
 We met the same problem when we doing computer node hotplug, It is a good 
 idea
 to introduce prepare_remove before actual device removal.

 I think we could do more in prepare_remove, such as rollback. In most 
 cases, we can
 offline most of memory sections except kernel used pages now, should we 
 rollback
 and online the memory sections when prepare_remove failed ?
>>>
>>> I think hot-plug operation should have all-or-nothing semantics.  That
>>> is, an operation should either complete successfully, or rollback to the
>>> original state.
>>
>> Yes, we have the same point of view with you. We handle this problem in the 
>> ACPI
>> based hot-plug framework as following:
>> 1) hot add / hot remove complete successfully if no error happens;
>> 2) automatic rollback to the original state if meets some error ;
>> 3) rollback to the original if hot-plug operation cancelled by user ;
> 
> Cool!
>  
 As you may know, the ACPI based hotplug framework we are working on 
 already addressed
 this problem, and the way we slove this problem is a bit like yours.

 We introduce hp_ops in struct acpi_device_ops:
 struct acpi_device_ops {
acpi_op_add add;
acpi_op_remove remove;
acpi_op_start start;
acpi_op_bind bind;
acpi_op_unbind unbind;
acpi_op_notify notify;
 #ifdef CONFIG_ACPI_HOTPLUG
struct acpihp_dev_ops *hp_ops;
 #endif /* CONFIG_ACPI_HOTPLUG */
 };

 in hp_ops, we divide the prepare_remove into six small steps, that is:
 1) pre_release(): optional step to mark device going to be removed/busy
 2) release(): reclaim device from running system
 3) post_release(): rollback if cancelled by user or error happened
 4) pre_unconfigure(): optional step to solve possible dependency issue
 5) unconfigure(): remove devices from running system
 6) post_unconfigure(): free resources used by devices

 In this way, we can easily rollback if error happens.
 How do you think of this solution, any suggestion ? I think we can achieve
 a better way for sharing ideas. :)
>>>
>>> Yes, sharing idea is good. :)  I do not know if we need all 6 steps (I
>>> have not looked at all your changes yet..), but in my mind, a hot-plug
>>> operation should be composed with the following 3 phases.
>>
>> Good idea ! we also implement a hot-plug operation in 3 phases:
>> 1) acpihp_drv_pre_execute
>> 2) acpihp_drv_execute
>> 3) acpihp_drv_post_execute
>> you may refer to :
>> https://lkml.org/lkml/2012/11/4/79
> 
> Great.  Yes, I will take a look.

Thanks, any comments are welcomed :)

>  
>>> 1. Validate phase - Verify if the request is a supported operation.  All
>>> known restrictions are verified at this phase.  For instance, if a
>>> hot-remove request involves kernel memory, it is failed in this phase.
>>> Since this phase makes no change, no rollback is necessary to fail. 
>>
>> Yes, we have done this in acpihp_drv_pre_execute, and check following things:
>>
>> 1) Hot-plugble or not. the instance kernel memory you mentioned is also 
>> checked
>>when memory device remove;
> 
> Agreed.
> 
>> 2) Dependency check involved. For instance, if hot-add a memory device,
>>processor should be added first, otherwise it's not valid to this 
>> operation.
> 
> I think FW should be the one that assures such dependency.  That is,
> when a memory device object is marked as present/enabled/functioning, it
> should be ready for the OS to use.

Yes, BIOS should do something for the dependency, 

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
tools/perf/Makefile between commit d2709c7ce4c5 ("perf: Make perf build
for x86 with UAPI disintegration applied") from Linus' tree and commit
945aea220bb8 ("perf tests: Move test objects into 'tests' directory")
from the tip tree.

I just used the version from Linus' tree (since it seems to be a superset
of the latter - see below) and can carry the fix as necessary (no action
is required).

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

diff --cc tools/perf/Makefile
index 0a619af,cca5bb8..000
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@@ -169,36 -169,16 +169,43 @@@ endi
  
  ### --- END CONFIGURATION SECTION ---
  
 -BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I$(OUTPUT)util -Iutil 
-I. -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
-D_GNU_SOURCE
 +ifeq ($(srctree),)
 +srctree := $(patsubst %/,%,$(dir $(shell pwd)))
 +srctree := $(patsubst %/,%,$(dir $(srctree)))
 +#$(info Determined 'srctree' to be $(srctree))
 +endif
 +
 +ifneq ($(objtree),)
 +#$(info Determined 'objtree' to be $(objtree))
 +endif
 +
 +ifneq ($(OUTPUT),)
 +#$(info Determined 'OUTPUT' to be $(OUTPUT))
 +endif
 +
 +BASIC_CFLAGS = \
 +  -Iutil/include \
 +  -Iarch/$(ARCH)/include \
 +  $(if $(objtree),-I$(objtree)/arch/$(ARCH)/include/generated/uapi) \
 +  -I$(srctree)/arch/$(ARCH)/include/uapi \
 +  -I$(srctree)/arch/$(ARCH)/include \
 +  $(if $(objtree),-I$(objtree)/include/generated/uapi) \
 +  -I$(srctree)/include/uapi \
 +  -I$(srctree)/include \
 +  -I$(OUTPUT)util \
 +  -Iutil \
 +  -I. \
 +  -I$(TRACE_EVENT_DIR) \
 +  -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
  BASIC_LDFLAGS =
  
+ ifeq ($(call try-cc,$(SOURCE_BIONIC),$(CFLAGS),bionic),y)
+   BIONIC := 1
+   EXTLIBS := $(filter-out -lrt,$(EXTLIBS))
+   EXTLIBS := $(filter-out -lpthread,$(EXTLIBS))
+   BASIC_CFLAGS += -I.
+ endif
+ 
  # Guard against environment variables
  BUILTIN_OBJS =
  LIB_H =


pgpbBKRNixEIT.pgp
Description: PGP signature

Re: [RFC][PATCH 2/2] modsig: differentiate between ephemeral and persistent key names

[Mimi Zohar]

On Mon, 2012-12-03 at 11:56 +1030, Rusty Russell wrote:
> Mimi Zohar  writes:
> > Using the same name for ephemeral and "persistent" keys results
> > in deleting the "persistent" key.  This patch renames the normal
> > kbuild asymmetric key pair name to "default_signing_key" and the
> > ephemeral key pair name to "ephemeral_signing_key".
> 
> I like the idea: I was always uncomfortable with the mixing of
> persistent and temporary keys.  But it's a bit misguided, because surely
> persistent keys don't belong in the build tree at all.

The original intent of the patch was to differentiate between a key
generated as part of the kbuild process, that exists for an indefinite
period of time, versus an ephemeral key, which is created and
immediately thrown away, after signing the kernel modules.

> 
> How about we do something like:
> 
> # Default to temporary keys
> MODKEYPREFIX = ./temp_signing_key
> 
> MODSECKEY = $(MODKEYPREFIX).priv
> MODPUBKEY = $(MODKEYPREFIX).x509
> 
> Then encourage people to do:
> 
> make MODKEYPREFIX=...

Although your suggestion addresses a different use case scenario, I like
it a lot.  Fortunately, it also works for the above ephemeral use case.
The default temporary key would be persistent across builds, while an
ephemeral key could be defined as "MODKEYPREFIX
= ./ephemeral_signing_key".

My main concern is having to force modsign_pubkey to be rebuilt each and
every time, since there is no way of knowing which key was previously
included.

> We could also use a config option to set the path, but that's probably
> less convenient.

Definitely less convenient.  I assume the normal use case for developers
would be multiple builds, followed by an install.  Each build shouldn't
require regenerating a new keypair, nor at the point that we're ready to
sign and install the kernel modules and image, do we want to change
the .config, which would result in additional, as you put it, root owned
turds.

thanks,

Mimi

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

[PATCH net-next] tuntap: attach queue 0 before registering netdevice

[Jason Wang]

We attach queue 0 after registering netdevice currently. This leads to call
netif_set_real_num_{tx|rx}_queues() after registering the netdevice. Since we
allow tun/tap has a maximum of 1024 queues, this may lead a huge number of
uevents to be injected to userspace since we create 2048 kobjects and then
remove 2046. Solve this problem by attaching queue 0 and set the real number of
queues before registering netdevice.

Reported-by: Jiri Slaby 
Tested-by: Jiri Slaby 
Signed-off-by: Jason Wang 
---
 drivers/net/tun.c |   11 +--
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index b44d7b7..cc3f878 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -492,9 +492,6 @@ static int tun_attach(struct tun_struct *tun, struct file 
*file)
 
tun_set_real_num_queues(tun);
 
-   if (tun->numqueues == 1)
-   netif_carrier_on(tun->dev);
-
/* device is allowed to go away first, so no need to hold extra
 * refcnt.
 */
@@ -1611,6 +1608,10 @@ static int tun_set_iff(struct net *net, struct file 
*file, struct ifreq *ifr)
TUN_USER_FEATURES;
dev->features = dev->hw_features;
 
+   err = tun_attach(tun, file);
+   if (err < 0)
+   goto err_free_dev;
+
err = register_netdevice(tun->dev);
if (err < 0)
goto err_free_dev;
@@ -1620,9 +1621,7 @@ static int tun_set_iff(struct net *net, struct file 
*file, struct ifreq *ifr)
device_create_file(>dev->dev, _attr_group))
pr_err("Failed to create tun sysfs files\n");
 
-   err = tun_attach(tun, file);
-   if (err < 0)
-   goto err_free_dev;
+   netif_carrier_on(tun->dev);
}
 
tun_debug(KERN_INFO, tun, "tun_set_iff\n");
-- 
1.7.1

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

RE: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver

[Dudley Du]

Hi Kamal,

I'm the writer of this driver.
Thanks for help upstream this driver.

I noticed that you marked out the reconnect function for it never work at all.
But in my test, it seems work fine.
I do the test steps as below:
1. load this driver with Cypress trackpad. Cursor moving on system;
2. directly unplug the trackpad from system;
3. reconnect the trackpad device to PC again;
4. moving finger on trackpad to check cursor still working on the system.
And also, I checked the debug message through dmesg, it makes sure that the 
reconnection function is called, and also the driver and trackpad still working 
fine.

So I want to know what situation is in your test to this function,
could you help describe your test steps to me, so we can figure out this issue.

Thanks.

Best Wishes,
Dudley Du
d...@cyrpess.com



>From: Cypress Semiconductor Corporation 
>
>Input/mouse driver for Cypress PS/2 Trackpad.
>
>Original code contributed by Cypress Semiconductor Corporation,
>modified by Kamal Mostafa and Kyle Fazzari.
>
>BugLink: http://launchpad.net/bugs/978807
>
>Signed-off-by: Kamal Mostafa 
>Signed-off-by: Kyle Fazzari 
>Signed-off-by: Mario Limonciello 
>Signed-off-by: Tim Gardner 
>Acked-by: Herton Krzesinski 
>---
> drivers/input/mouse/cypress_ps2.c |  830 +
> drivers/input/mouse/cypress_ps2.h |  219 ++
> 2 files changed, 1049 insertions(+)
> create mode 100644 drivers/input/mouse/cypress_ps2.c
> create mode 100644 drivers/input/mouse/cypress_ps2.h
>
>diff --git a/drivers/input/mouse/cypress_ps2.c 
>b/drivers/input/mouse/cypress_ps2.c
>new file mode 100644
>index 000..472342a
>--- /dev/null
>+++ b/drivers/input/mouse/cypress_ps2.c
>@@ -0,0 +1,830 @@
>+/*
>+ * Cypress Trackpad PS/2 mouse driver
>+ *
>+ * Copyright (c) 2012 Cypress Semiconductor Corporation.
>+ *
>+ * Additional contributors include:
>+ *   Kamal Mostafa 
>+ *   Kyle Fazzari 
>+ *
>+ * 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 "cypress_ps2.h"
>+
>+#define CYTP_DBG_DUMP 0   /* set to 1 for more verbose debug dump 
>*/
>+
>+#define cytp_dbg(fmt, ...)  \
>+  do {  \
>+  if (cytp)  \
>+  psmouse_dbg(psmouse, pr_fmt(fmt), ##__VA_ARGS__);  \
>+  } while (0)
>+
>+#if CYTP_DBG_DUMP
>+# define cytp_dbg_dump cytp_dbg
>+#else
>+# define cytp_dbg_dump(fmt, ...)
>+#endif
>+
>+
>+/* p is a pointer points to the buffer containing Cypress Keys. */
>+#define IS_CYPRESS_KEY(p) ((p[0] == CYPRESS_KEY_1) && (p[1] == CYPRESS_KEY_2))
>+#define CYTP_SET_PACKET_SIZE(n) { psmouse->pktsize = cytp->pkt_size = (n); }
>+#define CYTP_SET_MODE_BIT(x)  \
>+  do {  \
>+  if ((x) & CYTP_BIT_ABS_REL_MASK)  \
>+  cytp->mode = (cytp->mode & ~CYTP_BIT_ABS_REL_MASK);  \
>+  cytp->mode |= (x);  \
>+  } while (0)
>+#define CYTP_CLEAR_MODE_BIT(x){ cytp->mode &= ~(x); }
>+
>+#define CYTP_SUPPORT_ABS
>+
>+static unsigned char cytp_rate[] = {10, 20, 40, 60, 100, 200};
>+static unsigned char cytp_resolution[] = {0x00, 0x01, 0x02, 0x03};
>+
>+static int cypress_ps2_sendbyte(struct psmouse *psmouse, int value)
>+{
>+  struct cytp_data *cytp = psmouse->private;
>+  struct ps2dev *ps2dev = >ps2dev;
>+
>+  if (ps2_sendbyte(ps2dev, value & 0xff, CYTP_CMD_TIMEOUT) < 0) {
>+  cytp_dbg("send command 0x%02x failed, resp 0x%02x\n",
>+   value & 0xff, ps2dev->nak);
>+  if (ps2dev->nak == CYTP_PS2_RETRY)
>+  return CYTP_PS2_RETRY;
>+  else
>+  return CYTP_PS2_ERROR;
>+  }
>+
>+  cytp_dbg("send command 0x%02x success, resp 0xfa\n", value & 0xff);
>+
>+  return 0;
>+}
>+
>+static int cypress_ps2_ext_cmd(struct psmouse *psmouse, unsigned short cmd,
>+ unsigned char data)
>+{
>+  struct ps2dev *ps2dev = >ps2dev;
>+  int tries = CYTP_PS2_CMD_TRIES;
>+  int rc;
>+
>+  ps2_begin_command(ps2dev);
>+
>+  do {
>+  /*
>+   * send extension command 0xE8 or 0xF3,
>+   * if send extension command failed,
>+   * try to send recovery command to make
>+   * trackpad device return to ready wait command state.
>+   * It alwasy success based on this recovery commands.
>+   */
>+  rc = cypress_ps2_sendbyte(psmouse, cmd & 0xff);
>+  if (rc == CYTP_PS2_RETRY) {
>+  rc = cypress_ps2_sendbyte(psmouse, 0x00);
>+  if (rc == CYTP_PS2_RETRY)
>+  rc = cypress_ps2_sendbyte(psmouse, 0x0a);
>+  }
>+  if (rc == CYTP_PS2_ERROR)
>+   

Re: [PATCH 1/2] thp: fix anononymous page accounting in fallback path for COW of HZP

[Bob Liu]

On Fri, Nov 30, 2012 at 11:03 PM, Kirill A. Shutemov
 wrote:
> From: "Kirill A. Shutemov" 
>
> Don't forget to account newly allocated page in fallback path for
> copy-on-write of huge zero page.
>

What about fallback path in do_huge_pmd_wp_page_fallback()?
I think we should also account newly allocated page in it.

> Signed-off-by: Kirill A. Shutemov 
> ---
>  mm/huge_memory.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 57f0024..9d6f521 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1164,6 +1164,7 @@ static int do_huge_pmd_wp_zero_page_fallback(struct 
> mm_struct *mm,
> pmd_populate(mm, pmd, pgtable);
> spin_unlock(>page_table_lock);
> put_huge_zero_page();
> +   inc_mm_counter(mm, MM_ANONPAGES);
>
> mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
>
> --
> 1.7.11.7
>

-- 
Regards,
--Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/6] rtl8712: remove useless calls to memset().

[Larry Finger]

On 12/01/2012 08:40 PM, Cyril Roelandt wrote:

These calls are followed by calls to memcpy() on the same memory area, so they
can be safely removed.

Signed-off-by: Cyril Roelandt 
---
  drivers/staging/rtl8712/mlme_linux.c|2 --
  drivers/staging/rtl8712/rtl871x_cmd.c   |1 -
  drivers/staging/rtl8712/rtl871x_ioctl_set.c |2 --
  drivers/staging/rtl8712/rtl871x_mlme.c  |5 -
  4 files changed, 10 deletions(-)


Acked-by: Larry Finger  (for r8712u)

Thanks,

Larry



diff --git a/drivers/staging/rtl8712/mlme_linux.c 
b/drivers/staging/rtl8712/mlme_linux.c
index 7279854..f569a70 100644
--- a/drivers/staging/rtl8712/mlme_linux.c
+++ b/drivers/staging/rtl8712/mlme_linux.c
@@ -106,8 +106,6 @@ void r8712_os_indicate_disconnect(struct _adapter *adapter)
 * disconnect with AP for 60 seconds.
 */

-   memset([0], 0x00, sizeof(
-   struct RT_PMKID_LIST) * NUM_PMKID_CACHE);
memcpy([0], >securitypriv.
PMKIDList[0], sizeof(struct RT_PMKID_LIST) *
NUM_PMKID_CACHE);
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c 
b/drivers/staging/rtl8712/rtl871x_cmd.c
index 31f31dbf..f16307f 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -525,7 +525,6 @@ u8 r8712_joinbss_cmd(struct _adapter  *padapter, struct 
wlan_network *pnetwork)
kfree(pcmd);
return _FAIL;
}
-   memset(psecnetwork, 0, t_len);
memcpy(psecnetwork, >network, t_len);
auth = >authenticator_ie[0];
psecuritypriv->authenticator_ie[0] = (unsigned char)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_set.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_set.c
index d3ab24e..53a7c8c 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_set.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_set.c
@@ -97,8 +97,6 @@ static u8 do_join(struct _adapter *padapter)
pmlmepriv->fw_state = WIFI_ADHOC_MASTER_STATE;
pibss = padapter->registrypriv.dev_network.
MacAddress;
-   memset(_network->Ssid, 0,
-   sizeof(struct ndis_802_11_ssid));
memcpy(_network->Ssid,
>assoc_ssid,
sizeof(struct ndis_802_11_ssid));
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c 
b/drivers/staging/rtl8712/rtl871x_mlme.c
index c51ad9e..e52f04d 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -604,9 +604,6 @@ void r8712_surveydone_event_callback(struct _adapter 
*adapter, u8 *pbuf)
 adapter->registrypriv.
dev_network.MacAddress;
pmlmepriv->fw_state ^= _FW_UNDER_SURVEY;
-   memset(_network->Ssid, 0,
-   sizeof(struct
-  ndis_802_11_ssid));
memcpy(_network->Ssid,
>assoc_ssid,
sizeof(struct
@@ -1006,8 +1003,6 @@ void r8712_stadel_event_callback(struct _adapter 
*adapter, u8 *pbuf)
memcpy(pdev_network, _network->network,
r8712_get_ndis_wlan_bssid_ex_sz(_network->
network));
-   memset(_network->Ssid, 0,
-   sizeof(struct ndis_802_11_ssid));
memcpy(_network->Ssid,
>assoc_ssid,
sizeof(struct ndis_802_11_ssid));



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG REPORT] [mm-hotplug, aio] aio ring_pages can't be offlined

[Lin Feng]

On 11/30/2012 06:47 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 18:29:30 +0800 Lin Feng  wrote:
> 
>>> add a new library function which callers can use before (or after?)
>>> calling get_user_pages[_fast]().
>> Sorry, I'm not quite understand what "library function" function means..
>> Does it means a function aids get_user_pages() or totally wraps/replaces 
>> get_user_pages(), or none of above?
> 
> "library function" is terminology for a general facility which
> the core kernel makes available to other parts of the kernel. 
> get_user_pages() is a library function, as are the functions in lib/,
> etc.  "grep EXPORT_SYMBOL ./*/*.c"
hi Andrew,

Thanks for your explanation and sorry for my ignorant question :)
As Mel said Still I can't find a way to make every guy happy..

Thanks,
linfeng

> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpuidle: coupled: fix the potensial race condition and deadlock

[Joseph Lo]

Considering the chance that two CPU come into cpuidle_enter_state_coupled at
very close time. The 1st CPU increases the waiting count and the 2nd CPU do the
same thing right away. The 2nd CPU found the 1st CPU already in waiting then
prepare to poke it.

Before the 2nd CPU to poke 1st CPU, the 1st found the waiting count already same
with cpu_online count. So the 1st won't go into waiting loop and the 2nd CPU
didn't poke it yet. The 1st CPU will go into ready loop directly.

Then the 2nd CPU set up the couple_cpuidle_mask for 1st CPU and poke it. But the
1st CPU already lost the chance to handle the poke and clear the
couple_cpuidle_mask. Now whole MPcore are alredy to be coupled. The MPcore will
go into the power saving idle mode.

Because the poke was be implemented as a "smp_call_function_single", it's a
software intrrupt of "IPI_SINGLE_FUNC". If the power saving idle mode of the
platform can't retain the software interrupt of power saving idle mode, (e.g.
Tegra's powerd-down idle mode will shut off cpu power that include the power of
GIC) the software interrupt will got lost.

When the CPU resumed from the power saving idle mode and the system still keep
idle, it will go into idle mode again immediately. Because the
"smp_call_function_single" not allow the same function be called for the same
cpu twice, or it will got a lock. So the "couple_cpuidle_mask" can't be cleared
by 1st CPU, the 2nd CPU also can't poke it again. Then the deadlock happens
here.

The fix here used different wake up mechanism. Because there are already two
loops and a gloable variable "ready_waiting_counts" to sync the status of
MPcore to coupled state, the "coupled_cpuidle_mask" was not really necessary.
Just waking up the CPU from waiting and checking if the CPU need resched at
outside world to take the CPU out of idle are enough. And this fix didn't
modify the original behavior of coupled cpuidle framework. It should still
compitable with the origianal. The cpuidle driver that already applies
coupled cpuidle not need to change as well.

Cc: Colin Cross 
Signed-off-by: Joseph Lo 
---
Please check the detail sequence about how race condition and deadlock
be happened below:
It could be reproduced on Tegra20 and Tegra30.
(Suppose the last two cpu came into coupled_cpuidle_state at very close time)

CPU_0   CPU_1
cpuidle_enter_state_coupled
cpuidle_enter_state_coupled
1.increase waiting count
1. increase waiting count
 same time frame ---
2.before went into waiting
  loop, check the waiting
  count first
  2.1 the waiting count
   was same with online
   count
  2.2 so it won't go into
   waiting loop
2.in the procedure to prepare to send an
 "smp_call_function_single" to wake up CPU_0
 next time frame ---
3.before go into ready loop
  3.1 it will enable_irq
  3.2 check if there is any
IPI
  3.3 if yes, clear the coupled_mask
  3.4 then disable_irq
3. trigger the IPI to CPU_0
 3.1 set up the coupled_mask for CPU_0
 3.2 sent IPI to CPU_0
4. the IPI_SINGLE_FUNC been triggered from CPU_1 to CPU_0 and the coupled_mask
  of CPU_0 been set up
  4.1 but the CPU_0 miss the IPI and the chance to clear coupled_mask
 next time frame ---
5. MPCores went into ready loop and been coupled
6. go into power saving idle mode
   (For Tegra, it's means the vdd_cpu rail be shut off. The GIC be powered off
and the SW_INT(IPI) couldn't be retained.)
7. After the resume of power saving idle mode, the coupled_mask of CPU_0 not
   been cleared.
8. return to kernel

If the system still idle, it will come back to idle immediately.

CPU_0   CPU_1
cpuidle_enter_state_coupled
cpuidle_enter_state_coupled
1. set itself to waiting
2. go into waiting loop
3. check the coupled_mask been
  set or not
  3.1 enable_irq
  3.2 waiting for the coupled_mask
be cleared

1. found CPU_0 in waiting
2. prepare an IPI to poke CPU_0
  2.1 check the coupled_mask of CPU_0
  2.2 because it had been set
  2.3 so it didn't trigger and
"smp_call_function_single" to CPU_0 again
3. then go into ready loop

4. because there is no irq of
  "IPI_SINGLE_FUNC" be triggered
  for CPU_0
  4.1 

[PATCH 2/2] vfio powerpc: implemented IOMMU driver for VFIO

[Alexey Kardashevskiy]

VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.

The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does mapping/unmapping pages for the guest IO and
provides information about DMA window (required by a POWERPC
guest).

The counterpart in QEMU is required to support this functionality.

Cc: David Gibson 
Signed-off-by: Alexey Kardashevskiy 
---
 drivers/vfio/Kconfig|6 +
 drivers/vfio/Makefile   |1 +
 drivers/vfio/vfio_iommu_spapr_tce.c |  350 +++
 include/linux/vfio.h|   26 +++
 4 files changed, 383 insertions(+)
 create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 7cd5dec..b464687 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -3,10 +3,16 @@ config VFIO_IOMMU_TYPE1
depends on VFIO
default n
 
+config VFIO_IOMMU_SPAPR_TCE
+   tristate
+   depends on VFIO && SPAPR_TCE_IOMMU
+   default n
+
 menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
+   select VFIO_IOMMU_SPAPR_TCE if PPC_POWERNV
help
  VFIO provides a framework for secure userspace device drivers.
  See Documentation/vfio.txt for more details.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 2398d4a..72bfabc 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
+obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c 
b/drivers/vfio/vfio_iommu_spapr_tce.c
new file mode 100644
index 000..806ad9f
--- /dev/null
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -0,0 +1,350 @@
+/*
+ * VFIO: IOMMU DMA mapping support for TCE on POWER
+ *
+ * Copyright (C) 2012 IBM Corp.  All rights reserved.
+ * Author: Alexey Kardashevskiy 
+ *
+ * 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.
+ *
+ * Derived from original vfio_iommu_type1.c:
+ * Copyright (C) 2012 Red Hat, Inc.  All rights reserved.
+ * Author: Alex Williamson 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_VERSION  "0.1"
+#define DRIVER_AUTHOR   "a...@ozlabs.ru"
+#define DRIVER_DESC "VFIO IOMMU SPAPR TCE"
+
+static void tce_iommu_detach_group(void *iommu_data,
+   struct iommu_group *iommu_group);
+
+/*
+ * VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
+ */
+
+/*
+ * This code handles mapping and unmapping of user data buffers
+ * into DMA'ble space using the IOMMU
+ */
+
+#define NPAGE_TO_SIZE(npage)   ((size_t)(npage) << PAGE_SHIFT)
+
+struct vwork {
+   struct mm_struct*mm;
+   longnpage;
+   struct work_struct  work;
+};
+
+/* delayed decrement/increment for locked_vm */
+static void lock_acct_bg(struct work_struct *work)
+{
+   struct vwork *vwork = container_of(work, struct vwork, work);
+   struct mm_struct *mm;
+
+   mm = vwork->mm;
+   down_write(>mmap_sem);
+   mm->locked_vm += vwork->npage;
+   up_write(>mmap_sem);
+   mmput(mm);
+   kfree(vwork);
+}
+
+static void lock_acct(long npage)
+{
+   struct vwork *vwork;
+   struct mm_struct *mm;
+
+   if (!current->mm)
+   return; /* process exited */
+
+   if (down_write_trylock(>mm->mmap_sem)) {
+   current->mm->locked_vm += npage;
+   up_write(>mm->mmap_sem);
+   return;
+   }
+
+   /*
+* Couldn't get mmap_sem lock, so must setup to update
+* mm->locked_vm later. If locked_vm were atomic, we
+* wouldn't need this silliness
+*/
+   vwork = kmalloc(sizeof(struct vwork), GFP_KERNEL);
+   if (!vwork)
+   return;
+   mm = get_task_mm(current);
+   if (!mm) {
+   kfree(vwork);
+   return;
+   }
+   INIT_WORK(>work, lock_acct_bg);
+   vwork->mm = mm;
+   vwork->npage = npage;
+   schedule_work(>work);
+}
+
+/*
+ * The container descriptor supports only a single group per container.
+ * Required by the API as the container is not supplied with the IOMMU group
+ * at the moment of initialization.
+ */
+struct tce_container {
+   struct mutex lock;
+   struct iommu_table *tbl;
+};
+
+static void *tce_iommu_open(unsigned long arg)
+{
+   struct tce_container *container;
+
+   if (arg != VFIO_SPAPR_TCE_IOMMU) {
+   pr_err("tce_vfio: Wrong IOMMU 

[PATCH 0/2] vfio on power: yet another try

[Alexey Kardashevskiy]

The set includes 2 patches.

The first one adds necessary support for VFIO IOMMU support,
the second one adds a SPAPR TCE IOMMU driver to VFIO.

At the moment we have decided to get rid of DMA64 window
properties because we need more API than just 2 properties
(such as dynamic window allocation) but have not decided
about its actual design yet.

Alexey Kardashevskiy (2):
  vfio powerpc: enabled on powernv platform
  vfio powerpc: implemented IOMMU driver for VFIO

 arch/powerpc/include/asm/iommu.h |9 +
 arch/powerpc/kernel/iommu.c  |  186 ++
 arch/powerpc/platforms/powernv/pci.c |  135 +
 drivers/iommu/Kconfig|8 +
 drivers/vfio/Kconfig |6 +
 drivers/vfio/Makefile|1 +
 drivers/vfio/vfio_iommu_spapr_tce.c  |  350 ++
 include/linux/vfio.h |   26 +++
 8 files changed, 721 insertions(+)
 create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c

-- 
1.7.10.4

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

[PATCH 1/2] vfio powerpc: enabled on powernv platform

[Alexey Kardashevskiy]

This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).

It also implements an API for mapping/unmapping pages for
guest PCI drivers and providing DMA window properties.
This API is going to be used later by QEMU-VFIO to handle
h_put_tce hypercalls from the KVM guest.

Although this driver has been tested only on the POWERNV
platform, it should work on any platform which supports
TCE tables.

To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
option and configure VFIO as required.

Cc: David Gibson 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/iommu.h |9 ++
 arch/powerpc/kernel/iommu.c  |  186 ++
 arch/powerpc/platforms/powernv/pci.c |  135 
 drivers/iommu/Kconfig|8 ++
 4 files changed, 338 insertions(+)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index cbfe678..5c7087a 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -76,6 +76,9 @@ struct iommu_table {
struct iommu_pool large_pool;
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map;   /* A simple allocation bitmap for now */
+#ifdef CONFIG_IOMMU_API
+   struct iommu_group *it_group;
+#endif
 };
 
 struct scatterlist;
@@ -147,5 +150,11 @@ static inline void iommu_restore(void)
 }
 #endif
 
+extern long iommu_clear_tces(struct iommu_table *tbl, unsigned long entry,
+   unsigned long pages);
+extern long iommu_put_tces(struct iommu_table *tbl, unsigned long entry,
+   uint64_t tce, enum dma_data_direction direction,
+   unsigned long pages);
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index ff5a6ce..2738aa4 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DBG(...)
 
@@ -856,3 +857,188 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t 
size,
free_pages((unsigned long)vaddr, get_order(size));
}
 }
+
+#ifdef CONFIG_IOMMU_API
+/*
+ * SPAPR TCE API
+ */
+
+/*
+ * Returns the number of used IOMMU pages (4K) within
+ * the same system page (4K or 64K).
+ * bitmap_weight is not used as it does not support bigendian maps.
+ */
+static int syspage_weight(unsigned long *map, unsigned long entry)
+{
+   int ret = 0, nbits = PAGE_SIZE/IOMMU_PAGE_SIZE;
+
+   /* Aligns TCE entry number to system page boundary */
+   entry &= PAGE_MASK >> IOMMU_PAGE_SHIFT;
+
+   /* Count used 4K pages */
+   while (nbits--)
+   ret += (test_bit(entry++, map) == 0) ? 0 : 1;
+
+   return ret;
+}
+
+static void tce_flush(struct iommu_table *tbl)
+{
+   /* Flush/invalidate TLB caches if necessary */
+   if (ppc_md.tce_flush)
+   ppc_md.tce_flush(tbl);
+
+   /* Make sure updates are seen by hardware */
+   mb();
+}
+
+/*
+ * iommu_clear_tces clears tces and returned the number of system pages
+ * which it called put_page() on
+ */
+static long clear_tces_nolock(struct iommu_table *tbl, unsigned long entry,
+   unsigned long pages)
+{
+   int i, retpages = 0;
+   unsigned long oldtce, oldweight;
+   struct page *page;
+
+   for (i = 0; i < pages; ++i) {
+   oldtce = ppc_md.tce_get(tbl, entry + i);
+   ppc_md.tce_free(tbl, entry + i, 1);
+
+   oldweight = syspage_weight(tbl->it_map, entry);
+   __clear_bit(entry - tbl->it_offset, tbl->it_map);
+
+   if (!(oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)))
+   continue;
+
+   page = pfn_to_page(oldtce >> PAGE_SHIFT);
+
+   WARN_ON(!page);
+   if (!page)
+   continue;
+
+   if (oldtce & TCE_PCI_WRITE)
+   SetPageDirty(page);
+
+   put_page(page);
+
+   /* That was the last IOMMU page within the system page */
+   if ((oldweight == 1) && !syspage_weight(tbl->it_map, entry))
+   ++retpages;
+   }
+
+   return retpages;
+}
+
+/*
+ * iommu_clear_tces clears tces and returned the number
+ / of released system pages
+ */
+long iommu_clear_tces(struct iommu_table *tbl, unsigned long entry,
+   unsigned long pages)
+{
+   int ret;
+   struct iommu_pool *pool = get_pool(tbl, entry);
+
+   spin_lock(&(pool->lock));
+   ret = clear_tces_nolock(tbl, entry, pages);
+   tce_flush(tbl);
+   spin_unlock(&(pool->lock));
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_clear_tces);
+
+static int put_tce(struct iommu_table *tbl, unsigned long entry,
+   uint64_t tce, enum 

Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

[Chao Xie]

On Mon, Dec 3, 2012 at 9:39 AM, Chao Xie  wrote:
> On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
>  wrote:
>> On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
>>  wrote:
>>> On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
 The original sa1100_rtc_open/sa1100_rtc_release will be called
 when the /dev/rtc0 is opened or closed.
 In fact, these two functions will enable/disable the clock, and
 register/unregister the irqs.
 User application will use /dev/rtc0 to read the rtc time or set
 the alarm. The rtc should still run indepent of open/close the
 rtc device.
 So only enable clock and register the irqs when probe the device,
 and disable clock and unregister the irqs when remove the device.
>>>
>>> NAK.  I don't think you properly understand what's going on here if you
>>> think moving the entire open and release functions into the probe and
>>> remove functions is the right thing to do.
>>
>> Since PXA27x & PXA3xx supports dual rtc device at the same time,
>> user could choose use either of rtc at run time. Then clk & irq are setup
>> in open().
>>
>> Chao,
>> So you shouldn't remove them into probe().
>
> How can user to choose one RTC?
> The user API, for example "date" will open the device, get the time
> and then close the device.
> WHen set a alarm, it is the same routine. open->set->close.
> The open routine will enable clock and register irq, close will
> disable the clock and unregister irq. It means that if only open is
> invoked, rtc begins to work, and after close is invoked rtc stops
> working. It means that the user can not get correct time and can not
> get right alarm.

hi
I want to correct what i said. For the irq register/unregister i think
can be done at open/release. But for clock enable/disable, i do not
think so. If clock is disabled, as i think RTC will not work. User API
still use open->get_time->close for "date" command. It means that RTC
will not return correct date to user.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG REPORT] [mm-hotplug, aio] aio ring_pages can't be offlined

[Lin Feng]

On 11/30/2012 07:00 PM, Mel Gorman wrote:
>>
>> Well, that's a fairly low-level implementation detail.  A more typical
>> approach would be to add a new get_user_pages_non_movable() or such. 
>> That would probably have the same signature as get_user_pages(), with
>> one additional argument.  Then get_user_pages() becomes a one-line
>> wrapper which passes in a particular value of that argument.
>>
> 
> That is going in the direction that all pinned pages become MIGRATE_UNMOVABLE
> allocations.  That will impact THP availability by increasing the number
> of MIGRATE_UNMOVABLE blocks that exist and it would hit every user --
> not just those that care about ZONE_MOVABLE.
> 
> I'm likely to NAK such a patch if it's only about node hot-remove because
> it's much more of a corner case than wanting to use THP.
> 
> I would prefer if get_user_pages() checked if the page it was about to
> pin was in ZONE_MOVABLE and if so, migrate it at that point before it's
> pinned. It'll be expensive but will guarantee ZONE_MOVABLE availability
> if that's what they want. The CMA people might also want to take
> advantage of this if the page happened to be in the MIGRATE_CMA
> pageblock.
> 
hi Mel,

Thanks for your suggestion. 
My initial idea is also to restrict the impact as little as possible so 
migrate such pages as we need. 
But even to such "going to pin pages", most of them are going to be released 
soon, so deal with them all in the same way is really *expensive*. 

May be we do have to find another way that makes everybody happy :)

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

Re: [PATCH] ARM: dt: tegra: cardhu: Add drm components

[Mark Zhang]

On 12/01/2012 03:28 AM, Stephen Warren wrote:
> On 11/29/2012 10:44 PM, Mark Zhang wrote:
>> This patch adds the RGB & HDMI nodes in Tegra 30 cardhu's dts.
>> This makes the LVDS & HDMI working.
> 
> This still doesn't add any of the backlight/panel GPIO programming,
> which I believe is required before we enable any LCDs. We could add the
> HDMI node without that though.

Okay. So I think I may misunderstood your words several days ago, when I
submitted the v1 and v2 version for this patch.

So let's hold on this and wait for the backlight/panel working on cardhu.

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

Re: linux-next: build failure after merge of the modules tree

[Rusty Russell]

Stanislaw Gruszka  writes:

> On Mon, Nov 26, 2012 at 03:10:46PM +1100, Stephen Rothwell wrote:
>> After merging the modules tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>> 
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: invalid suffix 
>> "n_disabletype__8" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1196:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: invalid suffix 
>> "n_disable__9" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1198:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: invalid suffix 
>> "ghz_disabletype__32" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1263:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: invalid suffix 
>> "ghz_disable__33" on integer constant
>> drivers/net/wireless/iwlwifi/iwl-drv.c:1264:1: error: expected identifier or 
>> '(' before numeric constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: invalid suffix 
>> "n_disabletype__11" on integer constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6825:1: error: expected identifier 
>> or '(' before numeric constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: invalid suffix 
>> "n_disable__12" on integer constant
>> drivers/net/wireless/iwlegacy/4965-mac.c:6826:1: error: expected identifier 
>> or '(' before numeric constant
>> 
>> Presumably caused by commit 58876af0436e ("moduleparam: use __UNIQUE_ID
>> ()").  This commit removed the "__mod_" prefix that used to be added to
>> the front of the "name" passed to module_param_named().  Admittedly, the
>> documentation says that "name" must be "a valid C identifier which is the
>> parameter name", but the (ab)usage here used to work (the name starts
>> with a number).
>
> I prefer not to change module parameters name, since there are users
> who use current name in they modprobe config.
>
> Stanislaw

Yes, the names can't be changed.

Here's the patch I've applied, which fixes it:

>From 7a918c7fb6499179e14a4e23a5ccff0ab920ffe0 Mon Sep 17 00:00:00 2001
From: Rusty Russell 
Date: Mon, 3 Dec 2012 10:49:29 +1030
Subject: [PATCH] compiler: fix UNIQUE_ID() for non-identifier names.

Some modules have parameters starting with digits, so always prepend UNIQUE_ID_
which ensures we produce a valid identifier, plus leave a clue if you
should encounter such a symbol.

Reported-by: Stephen Rothwell 
Cc: Stanislaw Gruszka 
Signed-off-by: Rusty Russell 
---
 include/linux/compiler-gcc4.h |2 +-
 include/linux/compiler.h  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 8908821..56c802c 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -31,7 +31,7 @@
 
 #define __linktime_error(message) __attribute__((__error__(message)))
 
-#define __UNIQUE_ID(prefix) __PASTE(prefix, __PASTE(__, __COUNTER__))
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
 #if __GNUC_MINOR__ >= 5
 /*
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index c55ae87..5f45335 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -170,7 +170,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int 
val, int expect);
 
 /* Not-quite-unique ID. */
 #ifndef __UNIQUE_ID
-# define __UNIQUE_ID(prefix) __PASTE(__PASTE(prefix, __), __LINE__)
+# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
 #endif
 
 #endif /* __KERNEL__ */
-- 
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: [net-next rfc v7 2/3] virtio_net: multiqueue support

[Rusty Russell]

Jason Wang  writes:
> +static const struct ethtool_ops virtnet_ethtool_ops;
> +
> +/*
> + * Converting between virtqueue no. and kernel tx/rx queue no.
> + * 0:rx0 1:tx0 2:cvq 3:rx1 4:tx1 ... 2N+1:rxN 2N+2:txN
> + */
> +static int vq2txq(struct virtqueue *vq)
> +{
> + int index = virtqueue_get_queue_index(vq);
> + return index == 1 ? 0 : (index - 2) / 2;
> +}
> +
> +static int txq2vq(int txq)
> +{
> + return txq ? 2 * txq + 2 : 1;
> +}
> +
> +static int vq2rxq(struct virtqueue *vq)
> +{
> + int index = virtqueue_get_queue_index(vq);
> + return index ? (index - 1) / 2 : 0;
> +}
> +
> +static int rxq2vq(int rxq)
> +{
> + return rxq ? 2 * rxq + 1 : 0;
> +}
> +

I thought MST changed the proposed spec to make the control queue always
the last one, so this logic becomes trivial.

> +static int virtnet_set_queues(struct virtnet_info *vi)
> +{
> + struct scatterlist sg;
> + struct virtio_net_ctrl_rfs s;
> + struct net_device *dev = vi->dev;
> +
> + s.virtqueue_pairs = vi->curr_queue_pairs;
> + sg_init_one(, , sizeof(s));
> +
> + if (!vi->has_cvq)
> + return -EINVAL;
> +
> + if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_RFS,
> +   VIRTIO_NET_CTRL_RFS_VQ_PAIRS_SET, , 1, 0)){
> + dev_warn(>dev, "Fail to set the number of queue pairs to"
> +  " %d\n", vi->curr_queue_pairs);
> + return -EINVAL;
> + }

Where do we check the VIRTIO_NET_F_RFS bit?

>  static int virtnet_probe(struct virtio_device *vdev)
>  {
> - int err;
> + int i, err;
>   struct net_device *dev;
>   struct virtnet_info *vi;
> + u16 curr_queue_pairs;
> +
> + /* Find if host supports multiqueue virtio_net device */
> + err = virtio_config_val(vdev, VIRTIO_NET_F_RFS,
> + offsetof(struct virtio_net_config,
> + max_virtqueue_pairs), _queue_pairs);
> +
> + /* We need at least 2 queue's */
> + if (err)
> + curr_queue_pairs = 1;

Huh?  Just call this queue_pairs.  It's not curr_ at all...

> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> + vi->has_cvq = true;
> +
> + /* Use single tx/rx queue pair as default */
> + vi->curr_queue_pairs = 1;
> + vi->max_queue_pairs = curr_queue_pairs;

See...

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

Re: [RFC][PATCH 2/2] modsig: differentiate between ephemeral and persistent key names

[Rusty Russell]

Mimi Zohar  writes:
> Using the same name for ephemeral and "persistent" keys results
> in deleting the "persistent" key.  This patch renames the normal
> kbuild asymmetric key pair name to "default_signing_key" and the
> ephemeral key pair name to "ephemeral_signing_key".

I like the idea: I was always uncomfortable with the mixing of
persistent and temporary keys.  But it's a bit misguided, because surely
persistent keys don't belong in the build tree at all.

How about we do something like:

# Default to temporary keys
MODKEYPREFIX = ./temp_signing_key

MODSECKEY = $(MODKEYPREFIX).priv
MODPUBKEY = $(MODKEYPREFIX).x509

Then encourage people to do:

make MODKEYPREFIX=...

We could also use a config option to set the path, but that's probably
less convenient.

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

Re: [ 11/83] module: fix out-by-one error in kallsyms

[Rusty Russell]

satoru takeuchi  writes:
> Hi,

Hi!

>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -2273,12 +2273,17 @@ static void layout_symtab(struct module
>> src = (void *)info->hdr + symsect->sh_offset;
>> nsrc = symsect->sh_size / sizeof(*src);
>>
>> +   /* strtab always starts with a nul, so offset 0 is the empty string. 
>> */
>> +   strtab_size = 1;
>> +
>
> I suspect above code sniped is not needed since the size of src[0](always 1) 
> is
> counted at the following code("strtab_size += strlen(..) + 1;").

You are correct, on both counts.  This was a remnant of the previous
1-based looping.

Here's the fix I have pending.

Thanks!
Rusty.

module: fix one byte kallsyms overallocation.

Since we fixed our kallsyms strtab expansion code in
59ef28b1f14899b10d6b2682c7057ca00a9a3f47 (module: fix out-by-one error
in kallsyms) we now loop from zero, so we don't need to add an extra
byte for the first empty string.

Reported-by: satoru takeuchi 
Signed-off-by: Rusty Russell 

diff --git a/kernel/module.c b/kernel/module.c
index a1d2ed8..79a526d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2285,7 +2285,7 @@ static void layout_symtab(struct module *mod, struct 
load_info *info)
Elf_Shdr *symsect = info->sechdrs + info->index.sym;
Elf_Shdr *strsect = info->sechdrs + info->index.str;
const Elf_Sym *src;
-   unsigned int i, nsrc, ndst, strtab_size;
+   unsigned int i, nsrc, ndst, strtab_size = 0;
 
/* Put symbol section at end of init part of module. */
symsect->sh_flags |= SHF_ALLOC;
@@ -2296,9 +2296,6 @@ static void layout_symtab(struct module *mod, struct 
load_info *info)
src = (void *)info->hdr + symsect->sh_offset;
nsrc = symsect->sh_size / sizeof(*src);
 
-   /* strtab always starts with a nul, so offset 0 is the empty string. */
-   strtab_size = 1;
-
/* Compute total space required for the core symbols' strtab. */
for (ndst = i = 0; i < nsrc; i++) {
if (i == 0 ||
@@ -2340,7 +2337,6 @@ static void add_kallsyms(struct module *mod, const struct 
load_info *info)
mod->core_symtab = dst = mod->module_core + info->symoffs;
mod->core_strtab = s = mod->module_core + info->stroffs;
src = mod->symtab;
-   *s++ = 0;
for (ndst = i = 0; i < mod->num_symtab; i++) {
if (i == 0 ||
is_core_symbol(src+i, info->sechdrs, info->hdr->e_shnum)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net-next rfc v7 1/3] virtio-net: separate fields of sending/receiving queue from virtnet_info

[Rusty Russell]

Jason Wang  writes:
> To support multiqueue transmitq/receiveq, the first step is to separate queue
> related structure from virtnet_info. This patch introduce send_queue and
> receive_queue structure and use the pointer to them as the parameter in
> functions handling sending/receiving.

OK, seems like a straightforward xform: a few nit-picks:

> +/* Internal representation of a receive virtqueue */
> +struct receive_queue {
> + /* Virtqueue associated with this receive_queue */
> + struct virtqueue *vq;
> +
> +struct napi_struct napi;
> +
> +/* Number of input buffers, and max we've ever had. */
> +unsigned int num, max;

Weird whitespace here.

> +
> + /* Work struct for refilling if we run low on memory. */
> + struct delayed_work refill;

I can't really see the justificaiton for a refill per queue.  Just have
one work iterate all the queues if it happens, unless it happens often
(in which case, we need to look harder at this anyway).

>  struct virtnet_info {
>   struct virtio_device *vdev;
> - struct virtqueue *rvq, *svq, *cvq;
> + struct virtqueue *cvq;
>   struct net_device *dev;
>   struct napi_struct napi;

You leave napi here, and take it away in the next patch.  I think it's
supposed to go away now.

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

Re: [PATCH 0/2] modsign: fix missing symbol prefix

[Rusty Russell]

James Hogan  writes:
> These patches fix linker errors on blackfin and metag when module
> signing is enabled. This is due to the use of symbol prefixes on these
> architectures, and the asm in modsign_pubkey.c not prefixing one.

Sorry, I was away last week.

I've applied these to my fixes branch, and will push to Linus now.

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: [RFC][PATCH 1/2] modsig: add support to sign kernel modules using ephemeral keys

[Rusty Russell]

Mimi Zohar  writes:
> From: Dmitry Kasatkin 
>
> Signed modules are only as secure as the private key used to sign
> them.  This patch limits access to the private key by limiting the
> private key's existence to 'modules_install'(ie. this is meant for
> local developers, not distros.)
>
> This patch defines a new kernel build command line parameter
> called MODSIG (eg. make MODSIG=1 modules_install) and adds
> support for ephemeral keys.
>
> MODSIG=1 creates an ephemeral key pair during 'modules_install',
> forcing the rebuilding of the bzImage containing the new ephemeral
> builtin public key, signs the kernel modules with the private key,
> and then destroys the private key, limiting the existance of the
> private key to the 'modules_install' execution time.  (The private
> key's existence could be further limited, if the key generation
> wasn't tied to a specific file, but defined as a separate target.)

OK, I like the idea of this, though I'm not sure I'd personally use it
because I run modules_install as root, and thus I'd have root-owned
turds left in my tree.

If there are no complaints, I'll apply this.

Cheers,
Rusty.

> Another possible MODSIG option would be to password protect the
> private key.  Although this option is not as safe as removing the
> private key, it would not require rebuilding the bzImage, as the
> key pair is generated during 'make'.
>
> Changelog v1:
> - rebased on the upsteamed kernel module support
>
> Signed-off-by: Dmitry Kasatkin 
> Signed-off-by: Mimi Zohar 
> ---
>  Makefile |   26 ++
>  1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9f6ca12..d0dd777 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -718,10 +718,17 @@ mod_strip_cmd = true
>  endif # INSTALL_MOD_STRIP
>  export mod_strip_cmd
>  
> +export KBUILD_MODSIG := 0
>  
>  ifeq ($(CONFIG_MODULE_SIG),y)
>  MODSECKEY = ./signing_key.priv
>  MODPUBKEY = ./signing_key.x509
> +
> +# Use 'make MODSIG=1 modules_install' to use ephemeral keys for module 
> signing
> +ifeq ("$(origin MODSIG)", "command line")
> +KBUILD_MODSIG := $(MODSIG)
> +endif
> +
>  export MODPUBKEY
>  mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
>  else
> @@ -957,8 +964,27 @@ modules_prepare: prepare scripts
>  
>  # Target to install modules
>  PHONY += modules_install
> +
> +# Create an ephemeral keypair before module install
> +ifeq ($(KBUILD_MODSIG),1)
> +modules_install: _newmodpubkey_
> +endif
> +
>  modules_install: _modinst_ _modinst_post
>  
> +ifeq ($(KBUILD_MODSIG),1)
> +modules_install:  _rmprivkey_
> +endif
> +
> +PHONY += _newmodpubkey_
> +_newmodpubkey_: 
> + @rm -f $(MODSECKEY) $(MODPUBKEY)
> + $(Q)$(MAKE) -W kernel/modsign_pubkey.o
> +
> +PHONY += _rmprivkey_ 
> +_rmprivkey_: 
> + @rm -f $(MODSECKEY)
> +
>  PHONY += _modinst_
>  _modinst_:
>   @rm -rf $(MODLIB)/kernel
> -- 
> 1.7.7.6


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

Re: [PATCH] module: Remove a extra null character at the top of module->strtab.

[Rusty Russell]

sat  writes:
> From: Satoru Takeuchi 
>
> There is a extra null character('\0') at the top of module->strtab for
> each module. Commit 59ef28b introduced this bug and this patch fixes it.

Hi Satoru!

Unfortunately I took a week off last week, and when I read my
mail I read your previous report first, and created the fix myself.

I have now discarded my fix, and applied your identical one; you were
first, after all!

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 2/4] rtc: pxa: fix rtc caculation issue

[Chao Xie]

On Fri, Nov 30, 2012 at 4:04 AM, Robert Jarzmik  wrote:
> Chao Xie  writes:
>
> Hi Chao Xie,
>
> First of all, could you please send patches from rtc-pxa to me also, as I'm
> maintaining that driver ?
>
> Second point, the original design of the driver relies on the special case of
> writing zeroes to WOM and DOM, as mentionned in PXA27x Developers Guide, 
> chapter
> 21.4.2.3.5 "Writing Alarm Registers with Invalid (Zero) Data", which states :
>> Day-Of-Week (DOW), or Week-Of-Month (WOM), Day of Month (DOM), Month or Year
>> fields—Zero is not valid for these fields. If zero is written into any of
>> these fields, it is ignored while generating the alarm.
>
> I'd like to know if your patch fixes something, or is an enhancement ?
>
> Cheers.
>
> --
> Robert
>
> PS: I've not checked the patch yet, that's just a prelimary comment on the 
> patch
> message.

hi
I am sorry, i just use get_maintainer.pl to get the "to" list.
I have go through the spec. The spec has the desctiption about the
invalid data writing.
I am a little confused about the "wrting 0 to DOW". The descrption is
confused. first it said that "If zero is written into any of these
fields, it is ignored
while generating the alarm", then it gives a example, that if writing
0 to DOW, "For example, if a zero is written into a DOW field, the
alarm is set
every day at the time written in the Hours, Minutes, and Seconds
field”. It seems that the Year/Month/Week will not take effect.
I will do the test on the board again, and send out the update.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thp: avoid race on multiple parallel page faults to the same page

[Bob Liu]

On Fri, Nov 30, 2012 at 11:03 PM, Kirill A. Shutemov
 wrote:
> From: "Kirill A. Shutemov" 
>
> pmd value is stable only with mm->page_table_lock taken. After taking
> the lock we need to check that nobody modified the pmd before change it.
>
> Signed-off-by: Kirill A. Shutemov 

Reviewed-by: Bob Liu 

> ---
>  mm/huge_memory.c | 29 -
>  1 file changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9d6f521..51cb8fe 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -770,17 +770,20 @@ static inline struct page *alloc_hugepage(int defrag)
>  }
>  #endif
>
> -static void set_huge_zero_page(pgtable_t pgtable, struct mm_struct *mm,
> +static bool set_huge_zero_page(pgtable_t pgtable, struct mm_struct *mm,
> struct vm_area_struct *vma, unsigned long haddr, pmd_t *pmd,
> unsigned long zero_pfn)
>  {
> pmd_t entry;
> +   if (!pmd_none(*pmd))
> +   return false;
> entry = pfn_pmd(zero_pfn, vma->vm_page_prot);
> entry = pmd_wrprotect(entry);
> entry = pmd_mkhuge(entry);
> set_pmd_at(mm, haddr, pmd, entry);
> pgtable_trans_huge_deposit(mm, pgtable);
> mm->nr_ptes++;
> +   return true;
>  }
>
>  int do_huge_pmd_anonymous_page(struct mm_struct *mm, struct vm_area_struct 
> *vma,
> @@ -800,6 +803,7 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm, 
> struct vm_area_struct *vma,
> transparent_hugepage_use_zero_page()) {
> pgtable_t pgtable;
> unsigned long zero_pfn;
> +   bool set;
> pgtable = pte_alloc_one(mm, haddr);
> if (unlikely(!pgtable))
> return VM_FAULT_OOM;
> @@ -810,9 +814,13 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm, 
> struct vm_area_struct *vma,
> goto out;
> }
> spin_lock(>page_table_lock);
> -   set_huge_zero_page(pgtable, mm, vma, haddr, pmd,
> +   set = set_huge_zero_page(pgtable, mm, vma, haddr, pmd,
> zero_pfn);
> spin_unlock(>page_table_lock);
> +   if (!set) {
> +   pte_free(mm, pgtable);
> +   put_huge_zero_page();
> +   }
> return 0;
> }
> page = alloc_hugepage_vma(transparent_hugepage_defrag(vma),
> @@ -1046,14 +1054,16 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct 
> mm_struct *src_mm,
>  */
> if (is_huge_zero_pmd(pmd)) {
> unsigned long zero_pfn;
> +   bool set;
> /*
>  * get_huge_zero_page() will never allocate a new page here,
>  * since we already have a zero page to copy. It just takes a
>  * reference.
>  */
> zero_pfn = get_huge_zero_page();
> -   set_huge_zero_page(pgtable, dst_mm, vma, addr, dst_pmd,
> +   set = set_huge_zero_page(pgtable, dst_mm, vma, addr, dst_pmd,
> zero_pfn);
> +   BUG_ON(!set); /* unexpected !pmd_none(dst_pmd) */
> ret = 0;
> goto out_unlock;
> }
> @@ -1110,7 +1120,7 @@ unlock:
>
>  static int do_huge_pmd_wp_zero_page_fallback(struct mm_struct *mm,
> struct vm_area_struct *vma, unsigned long address,
> -   pmd_t *pmd, unsigned long haddr)
> +   pmd_t *pmd, pmd_t orig_pmd, unsigned long haddr)
>  {
> pgtable_t pgtable;
> pmd_t _pmd;
> @@ -1139,6 +1149,9 @@ static int do_huge_pmd_wp_zero_page_fallback(struct 
> mm_struct *mm,
> mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
>
> spin_lock(>page_table_lock);
> +   if (unlikely(!pmd_same(*pmd, orig_pmd)))
> +   goto out_free_page;
> +
> pmdp_clear_flush(vma, haddr, pmd);
> /* leave pmd empty until pte is filled */
>
> @@ -1171,6 +1184,12 @@ static int do_huge_pmd_wp_zero_page_fallback(struct 
> mm_struct *mm,
> ret |= VM_FAULT_WRITE;
>  out:
> return ret;
> +out_free_page:
> +   spin_unlock(>page_table_lock);
> +   mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
> +   mem_cgroup_uncharge_page(page);
> +   put_page(page);
> +   goto out;
>  }
>
>  static int do_huge_pmd_wp_page_fallback(struct mm_struct *mm,
> @@ -1317,7 +1336,7 @@ alloc:
> count_vm_event(THP_FAULT_FALLBACK);
> if (is_huge_zero_pmd(orig_pmd)) {
> ret = do_huge_pmd_wp_zero_page_fallback(mm, vma,
> -   address, pmd, haddr);
> +   

Re: [RFC] Capabilities still can't be inherited by normal programs

[Andrew G. Morgan]

On Sun, Dec 2, 2012 at 3:04 PM, Andy Lutomirski  wrote:
> On Sun, Dec 2, 2012 at 2:26 PM, Andrew G. Morgan  wrote:
>> On Sun, Dec 2, 2012 at 10:35 AM, Andy Lutomirski  wrote:
>>> On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan  wrote:
 There is a fairly well written paper ;-) explaining how things are
 supposed to work:

   http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf

 The inheritable set is not intended to work the way you seem to want.
 Naive inheritance like that is quite explicitly the opposite of what
 was designed.
>>>
>>> I'm aware that the system was designed, or perhaps evolved, to prevent
>>> users with uid != 0 from inheriting capabilities unless vfs
>>> inheritable caps are granted on a per-file basis.  I want a way around
>>> that -- I want to mix non-root, capabilities, and exec.  This is damn
>>> near impossible right now if I don't have CAP_SETFCAP or root's
>>> explicit, per-program cooperation.  CAP_SETFCAP is essentially
>>> equivalent to "let me do anything".
>>>
>>> As it stands, using something like pam_cap to grant a user cap_net_raw
>>> is useless -- that user can't use the privilege because (unless uid ==
>>> 0) the privilege will never end up in the permitted set.
>>
>> Have you tried adding fI of cap_net_raw to the file to be executed?
>
> Yes, and it works.  I don't like this solution because:
>
> a) It doesn't scale in terms of sysadmin resources required.

By doesn't scale, you mean it requires the admin to define which
actual binaries on their system can wield privilege?

> b) It adds no real security over real inheritable capabilities.  I'd
> be rather surprised if tcpdump does not have any bugs that would allow
> me to subvert it to recover its inherited capabilities.  For example,
> it drops privileges like this:

In other words, an app bug can leak a privilege - one of the
privileges that it is explicitly trusted to wield. Its hard to see how
this isn't an app bug.

> if (setgid(getgid()) != 0 || setuid(getuid()) != 0 )
> fprintf(stderr, "Warning: setgid/setuid failed !\n");
>
> This is buggy for at least two reasons: it doesn't abort on error and
> setuid doesn't actually drop capabilities when uid 0 isn't involved.

Right.

>
> c) tcpdump isn't really special.  I trust this user account with
> cap_net_raw, and that should be all the configuration I need.

But this is a statement about access control, and not a statement
about privilege. You trust the user to invoke something that can do
tcpdump, you don't really trust the user to generate arbitrary packets
on the network.

> d) If I really wanted, I could emulate execve without actually doing
> execve, and capabilities would be inherited.

If you could modify the executable properties of the binary that has
the privilege to wield a privilege then you are either exploiting an
app bug, or doing something the privileged binary has been trusted to
do.

> The issue with allowing real capability inheritance is that,
> currently, it's safe for a program with fP != 0 to add an inheritable
> capability and then execve something caller-controlled.  I don't know
> whether anything actually does this, but it's hard to prove that
> nothing does.  Hence my idea of requiring no_new_privs to make
> capabilities inheritable.

Assuming this is not another app bug, and that's what the executable
with fP != 0 does, then that's why it was given fP != 0 - its what the
program was designed to do. Why is this an issue?

> An alternative, and considerably more intrusive, change would be to
> add a fourth mask of genuinely inheritable capabilities.

If you believe that you want to give a user the privilege to grant a
privilege to an arbitrary binary to do things like this, why not write
an app that adds file capabilities to target binaries owned by the
user? You can make it execute-only by said user and let them do
whatever they want. This requires no kernel changes.

Cheers

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ext4: remove some unused code lines

[zwu . kernel]

From: Zhi Yong Wu 

  In ext4_ext_in_cache(), some codes are redundant,
this patch will remove them.

Reviewed-by: Zheng Liu 
Signed-off-by: Zhi Yong Wu 
---
 fs/ext4/extents.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 7011ac9..43ec639 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2156,7 +2156,6 @@ ext4_ext_in_cache(struct inode *inode, ext4_lblk_t block,
  struct ext4_extent *ex)
 {
struct ext4_ext_cache *cex;
-   struct ext4_sb_info *sbi;
int ret = 0;
 
/*
@@ -2164,7 +2163,6 @@ ext4_ext_in_cache(struct inode *inode, ext4_lblk_t block,
 */
spin_lock(_I(inode)->i_block_reservation_lock);
cex = _I(inode)->i_cached_extent;
-   sbi = EXT4_SB(inode->i_sb);
 
/* has cache valid data? */
if (cex->ec_len == 0)
-- 
1.7.6.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 v4 08/12] memory-hotplug: remove memmap of sparse-vmemmap

[Jianguo Wu]

Hi Congyang,

This is the new version.

Thanks,
Jianguo Wu.


Signed-off-by: Jianguo Wu 
Signed-off-by: Jiang Liu 
---
 include/linux/mm.h  |1 +
 mm/sparse-vmemmap.c |  231 +++
 mm/sparse.c |3 +-
 3 files changed, 234 insertions(+), 1 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5657670..1f26af5 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1642,6 +1642,7 @@ int vmemmap_populate(struct page *start_page, unsigned 
long pages, int node);
 void vmemmap_populate_print_last(void);
 void register_page_bootmem_memmap(unsigned long section_nr, struct page *map,
  unsigned long size);
+void vmemmap_free(struct page *memmap, unsigned long nr_pages);
 
 enum mf_flags {
MF_COUNT_INCREASED = 1 << 0,
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 1b7e22a..748732d 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -29,6 +29,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_MEMORY_HOTREMOVE
+#include 
+#endif
+
 /*
  * Allocate a block of memory to be used to back the virtual memory map
  * or to back the page tables that are used to create the mapping.
@@ -224,3 +228,230 @@ void __init sparse_mem_maps_populate_node(struct page 
**map_map,
vmemmap_buf_end = NULL;
}
 }
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+
+#define PAGE_INUSE 0xFD
+
+static void vmemmap_free_pages(struct page *page, int order)
+{
+   struct zone *zone;
+   unsigned long magic;
+
+   magic = (unsigned long) page->lru.next;
+   if (magic == SECTION_INFO || magic == MIX_SECTION_INFO) {
+   put_page_bootmem(page);
+
+   zone = page_zone(page);
+   zone_span_writelock(zone);
+   zone->present_pages++;
+   zone_span_writeunlock(zone);
+   totalram_pages++;
+   } else
+   free_pages((unsigned long)page_address(page), order);
+}
+
+static void free_pte_table(pmd_t *pmd)
+{
+   pte_t *pte, *pte_start;
+   int i;
+
+   pte_start = (pte_t *)pmd_page_vaddr(*pmd);
+   for (i = 0; i < PTRS_PER_PTE; i++) {
+   pte = pte_start + i;
+   if (pte_val(*pte))
+   return;
+   }
+
+   /* free a pte talbe */
+   vmemmap_free_pages(pmd_page(*pmd), 0);
+   spin_lock(_mm.page_table_lock);
+   pmd_clear(pmd);
+   spin_unlock(_mm.page_table_lock);
+}
+
+static void free_pmd_table(pud_t *pud)
+{
+   pmd_t *pmd, *pmd_start;
+   int i;
+
+   pmd_start = (pmd_t *)pud_page_vaddr(*pud);
+   for (i = 0; i < PTRS_PER_PMD; i++) {
+   pmd = pmd_start + i;
+   if (pmd_val(*pmd))
+   return;
+   }
+
+   /* free a pmd talbe */
+   vmemmap_free_pages(pud_page(*pud), 0);
+   spin_lock(_mm.page_table_lock);
+   pud_clear(pud);
+   spin_unlock(_mm.page_table_lock);
+}
+
+static void free_pud_table(pgd_t *pgd)
+{
+   pud_t *pud, *pud_start;
+   int i;
+
+   pud_start = (pud_t *)pgd_page_vaddr(*pgd);
+   for (i = 0; i < PTRS_PER_PUD; i++) {
+   pud = pud_start + i;
+   if (pud_val(*pud))
+   return;
+   }
+
+   /* free a pud table */
+   vmemmap_free_pages(pgd_page(*pgd), 0);
+   spin_lock(_mm.page_table_lock);
+   pgd_clear(pgd);
+   spin_unlock(_mm.page_table_lock);
+}
+
+static int split_large_page(pte_t *kpte, unsigned long address, pte_t *pbase)
+{
+   struct page *page = pmd_page(*(pmd_t *)kpte);
+   int i = 0;
+   unsigned long magic;
+   unsigned long section_nr;
+
+   __split_large_page(kpte, address, pbase);
+   __flush_tlb_all();
+
+   magic = (unsigned long) page->lru.next;
+   if (magic == SECTION_INFO) {
+   section_nr = pfn_to_section_nr(page_to_pfn(page));
+   while (i < PTRS_PER_PMD) {
+   page++;
+   i++;
+   get_page_bootmem(section_nr, page, SECTION_INFO);
+   }
+   }
+
+   return 0;
+}
+
+static void vmemmap_pte_remove(pmd_t *pmd, unsigned long addr, unsigned long 
end)
+{
+   pte_t *pte;
+   unsigned long next;
+   void *page_addr;
+
+   pte = pte_offset_kernel(pmd, addr);
+   for (; addr < end; pte++, addr += PAGE_SIZE) {
+   next = (addr + PAGE_SIZE) & PAGE_MASK;
+   if (next > end)
+   next = end;
+
+   if (pte_none(*pte))
+   continue;
+   if (IS_ALIGNED(addr, PAGE_SIZE) &&
+   IS_ALIGNED(next, PAGE_SIZE)) {
+   vmemmap_free_pages(pte_page(*pte), 0);
+   spin_lock(_mm.page_table_lock);
+   pte_clear(_mm, addr, pte);
+   spin_unlock(_mm.page_table_lock);
+   } else {
+   /*
+

Re: [PATCH] synclink fix ldisc buffer argument

[Chen Gang]

于 2012年12月03日 04:05, Paul Fulghum 写道:
> OK, I’ll do that.
> 

pardon (I am just learning)
  does 65535 mean HDLC_MAX_FRAME_SIZE ?
  why do we need info->max_frame_size >= 4096 ?

in drivers/tty/synclink_gt.c:
3550 if (info->max_frame_size < 4096)
3551 info->max_frame_size = 4096;
3552 else if (info->max_frame_size > 65535)
3553 info->max_frame_size = 65535;
3554
 ...
3603 info->max_frame_size = 4096;


if possible:
  can we move the relative comments (which are inside function) to the
location just above ldisc_receive_buf ?


  thanks.

gchen.


> On Dec 2, 2012, at 12:10 PM, Alan Cox  > wrote:
> 
>> On Sun, 2 Dec 2012 10:11:58 -0600
>> Paul Fulghum mailto:pau...@microgate.com>> wrote:
>>
>>> True, in this mode line disciplines other than N_HDLC would not be
>>> functional and N_HDLC ignores the flag buffer.
>>> This change won’t make other line disciplines useful, it will just
>>> prevent the case of a mistakenly selected line discipline accessing
>>> beyond the end of the (dummy) flag buffer.
>>>
>>> I’m fine with or without the change. It is functional now with a
>>> chance to read past then end of a buffer if misconfigured. With the
>>> change, it has the same functionality without the ability to read
>>> past the end of a buffer if misconfigured.
>>
>> With the change its feeding crap in the flags buffer, which may matter in
>> future depending what happens to the other bits.
>>
>> If this is a real issue far better to just kzalloc a blank flag buffer to
>> match the mtu.
>>
> 
> -- 
> Paul Fulghum
> MicroGate Systems, Ltd.
> =Customer Driven, by Design=
> (800)444-1982
> (512)345-7791 (Direct)
> (512)343-9046 (Fax)
> Central Time Zone (GMT -5h)
> www.microgate.com 
> 


-- 
Chen Gang

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

Re: [PATCH] ext4: remove some unused code lines

[Zhi Yong Wu]

On Sun, Dec 2, 2012 at 8:27 PM, Zheng Liu  wrote:
> On Thu, Nov 29, 2012 at 06:00:00PM +0800, zwu.ker...@gmail.com wrote:
>> From: Zhi Yong Wu 
>
> Please write a commit log to describe this patch, even though it is
> quite simple and straightfoward
Good suggestion, thanks.
>
> Otherwise, it looks good to me.
>
> Reviewed-by: Zheng Liu 
>
> Regards,
> - Zheng
>
>>
>> Signed-off-by: Zhi Yong Wu 
>> ---
>>  fs/ext4/extents.c |2 --
>>  1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
>> index 7011ac9..43ec639 100644
>> --- a/fs/ext4/extents.c
>> +++ b/fs/ext4/extents.c
>> @@ -2156,7 +2156,6 @@ ext4_ext_in_cache(struct inode *inode, ext4_lblk_t 
>> block,
>> struct ext4_extent *ex)
>>  {
>>   struct ext4_ext_cache *cex;
>> - struct ext4_sb_info *sbi;
>>   int ret = 0;
>>
>>   /*
>> @@ -2164,7 +2163,6 @@ ext4_ext_in_cache(struct inode *inode, ext4_lblk_t 
>> block,
>>*/
>>   spin_lock(_I(inode)->i_block_reservation_lock);
>>   cex = _I(inode)->i_cached_extent;
>> - sbi = EXT4_SB(inode->i_sb);
>>
>>   /* has cache valid data? */
>>   if (cex->ec_len == 0)
>> --
>> 1.7.6.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,

Zhi Yong Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.7-rc7: BUG: MAX_STACK_TRACE_ENTRIES too low!

[Li Zhong]

On Sat, 2012-12-01 at 12:32 -0800, Christian Kujau wrote:
> On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
> > On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
> > > On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
> > > > the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
> > > 
> > > I found the following on patchwork, but this seems to deal with powerpc64 
> > > only, while this PowerBook G4 of mine is powerpc32:
> > > 
> > >   http://patchwork.ozlabs.org/patch/193414/
> > > 
> > > It looks related, but then again, I fail to parse assember...
> > 
> > Hi Christian, 
> > 
> > Would you please help to try the following fix? I don't have a powerpc32
> > machine for test...
> 
> After 3 days of uptime with your patch applied (and "normal" usage, just 
> as before) no such BUG message occured. So, from my point of view, feel
> free to add:
> 
>Tested-by: Christian Kujau 

Thank you, Christian. 

I'll try to submit a patch for it.

Thanks, Zhong

> 
> Thanks!
> Christian.
> 
> > ==
> > diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> > index 9499385..cadebfd 100644
> > --- a/arch/powerpc/kernel/entry_32.S
> > +++ b/arch/powerpc/kernel/entry_32.S
> > @@ -439,6 +439,8 @@ ret_from_fork:
> >  ret_from_kernel_thread:
> > REST_NVGPRS(r1)
> > bl  schedule_tail
> > +   li  r3,0
> > +   stw r3,0(r1)
> > mtlrr14
> > mr  r3,r15
> > PPC440EP_ERR42
> > ==
> > 
> > > 
> > > Christian.
> > > 
> > > > [40007.339487] [sched_delayed] sched: RT throttling activated
> > > > [69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
> > > > [69731.390371] turning off the locking correctness validator.
> > > > [69731.391942] Call Trace:
> > > > [69731.393525] [c9a61c10] [c0009064] show_stack+0x70/0x1bc (unreliable)
> > > > [69731.395152] [c9a61c50] [c0077460] save_trace+0xfc/0x114
> > > > [69731.396735] [c9a61c60] [c007be20] __lock_acquire+0x1568/0x19b8
> > > > [69731.398296] [c9a61d00] [c007c2c0] lock_acquire+0x50/0x70
> > > > [69731.399857] [c9a61d20] [c0550e28] _raw_spin_lock_irq+0x5c/0x78
> > > > [69731.401419] [c9a61d40] [c054fb58] __schedule+0xd8/0x534
> > > > [69731.402972] [c9a61da0] [c0550094] _cond_resched+0x50/0x68
> > > > [69731.404527] [c9a61db0] [c0479908] dst_gc_task+0xbc/0x258
> > > > [69731.406070] [c9a61e40] [c004eeb8] process_one_work+0x1f4/0x49c
> > > > [69731.407585] [c9a61e80] [c004f644] worker_thread+0x14c/0x400
> > > > [69731.409075] [c9a61eb0] [c0057634] kthread+0xbc/0xc0
> > > > [69731.410521] [c9a61f40] [c0011ad4] ret_from_kernel_thread+0x5c/0x64
> > > > [...repeated 54 times...]
> > > > 
> > > > Anyone knows what this is about?
> > > > 
> > > > Thanks,
> > > > Christian.
> > > > 
> > > > [0] http://lkml.indiana.edu/hypermail/linux/kernel/1211.0/03025.html
> 


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

RE: [PATCH] EXTCON: Get and set cable properties

[Tc, Jenny]

> > Could you please review this. This is a follow up patch for "PATCH]
> > extcon : callback function to read cable property"
> 
> While I see nothing wrong with the patch itself, I beg you to send some users
> for the new calls. Don't be obsessed with the extcon internals too much,
> think more about how things will interact (i.e. I really really want to see 
> how
> you use these calls from the power supply drivers).

The usage of extcon cable property is captured in patch 
https://lkml.org/lkml/2012/10/18/219
This patch uses a extcon_dev  callback function get_cable_properties() to get 
the
cable properties. As discussed in the previous mail thread, it may not be good 
to have a extcon call
back function since the extcon provider may not be aware of the cable 
properties. This patch replaces
the callback function with an API, so that whoever knows the cable property, 
can set the property
using the extcon API extcon_cable_set_data().

The usage flow would be
1)Consumer gets a notification from the extcon
2)consumer reads the property using the API extcon_cable_get_data

This way it doesn't mandatory for the extcon provider to give the cable 
property.
Anyone who is aware of the cable property can set the cable property using the 
API.
It makes the consumer and provider implementations very simple.

With this new API, the callback function in patch 
https://lkml.org/lkml/2012/10/18/219 can be
replaced by the API extcon_cable_set_data().

Re: [RFC PATCH v3] Add rcu user eqs exception hooks for async page fault

[Li Zhong]

On Fri, 2012-11-30 at 12:26 +0200, Gleb Natapov wrote:
> On Fri, Nov 30, 2012 at 05:18:41PM +0800, Li Zhong wrote:
> > This patch adds user eqs exception hooks for async page fault page not
> > present code path, to exit the user eqs and re-enter it as necessary. 
> > 
> > Async page fault is different from other exceptions that it may be
> > triggered from idle process, so we still need rcu_irq_enter() and
> > rcu_irq_exit() to exit cpu idle eqs when needed, to protect the code
> > that needs use rcu.
> > 
> > As Frederic pointed out it would be safest and simplest to protect the
> > whole kvm_async_pf_task_wait(). Otherwise, "we need to check all the
> > code there deeply for potential RCU uses and ensure it will never be
> > extended later to use RCU.".
> > 
> > However, We'd better re-enter the cpu idle eqs if we get the exception
> > in cpu idle eqs, by calling rcu_irq_exit() before native_safe_halt(). 
> > 
> > So the patch does what Frederic suggested for rcu_irq_*() API usage
> > here, except that I moved the rcu_irq_*() pair originally in
> > do_async_page_fault() into kvm_async_pf_task_wait(). 
> > 
> > That's because, I think it's better to have rcu_irq_*() pairs to be in
> > one function ( rcu_irq_exit() after rcu_irq_enter() ), especially here,
> > kvm_async_pf_task_wait() has other callers, which might cause
> > rcu_irq_exit() be called without a matching rcu_irq_enter() before it,
> > which is illegal if the cpu happens to be in rcu idle state. 
> > 
> > Signed-off-by: Li Zhong 
> > ---
> >  arch/x86/kernel/kvm.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > index 4180a87..342b00b 100644
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> > @@ -42,6 +42,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  static int kvmapf = 1;
> >  
> > @@ -112,6 +113,8 @@ void kvm_async_pf_task_wait(u32 token)
> > DEFINE_WAIT(wait);
> > int cpu, idle;
> >  
> > +   rcu_irq_enter();
> > +
> Why move rcu_irq_*() calls into kvm_async_pf_task_wait()?

I think it is not good for a function to have a rcu_irq_exit(), which
needs a matching rcu_irq_enter() in its caller. 

Here, if not move rcu_irq_* in, then the rcu_irq_exit() before
native_safe_halt() in kvm_async_pf_task_wait() is the one that needs the
matching rcu_irq_enter() in do_async_page_fault(). And, for this case,
kvm_async_pf_task_wait() even has other caller - pf_interception().
Maybe it will always be rcu non-idle for pf_interception (so a matching
rcu_irq_enter() is not needed), or maybe we could (or need) add
rcu_irq_*() in pf_interception().  But I still think it's good to have
those function calls that need to be matched be contained in one
function.

Thanks, Zhong

> > cpu = get_cpu();
> > idle = idle_cpu(cpu);
> > put_cpu();
> > @@ -123,6 +126,8 @@ void kvm_async_pf_task_wait(u32 token)
> > hlist_del(>link);
> > kfree(e);
> > spin_unlock(>lock);
> > +
> > +   rcu_irq_exit();
> We can skip that if  rcu_irq_*() will stay outside.
> 
> > return;
> > }
> >  
> > @@ -147,13 +152,16 @@ void kvm_async_pf_task_wait(u32 token)
> > /*
> >  * We cannot reschedule. So halt.
> >  */
> > +   rcu_irq_exit();
> > native_safe_halt();
> > +   rcu_irq_enter();
> > local_irq_disable();
> > }
> > }
> > if (!n.halted)
> > finish_wait(, );
> >  
> > +   rcu_irq_exit();
> > return;
> >  }
> >  EXPORT_SYMBOL_GPL(kvm_async_pf_task_wait);
> > @@ -247,10 +255,10 @@ do_async_page_fault(struct pt_regs *regs, unsigned 
> > long error_code)
> > break;
> > case KVM_PV_REASON_PAGE_NOT_PRESENT:
> > /* page is swapped out by the host. */
> > -   rcu_irq_enter();
> > +   exception_enter(regs);
> > exit_idle();
> > kvm_async_pf_task_wait((u32)read_cr2());
> > -   rcu_irq_exit();
> > +   exception_exit(regs);
> > break;
> > case KVM_PV_REASON_PAGE_READY:
> > rcu_irq_enter();
> > -- 
> > 1.7.11.4
> 
> --
>   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/

Re: [BUG REPORT] [mm-hotplug, aio] aio ring_pages can't be offlined

[Lin Feng]

hi Domenico,

Sorry for my late reply and thanks for your attention, see below :)

On 11/30/2012 11:24 PM, Domenico Andreoli wrote:
> On Thu, Nov 29, 2012 at 02:54:58PM +0800, Lin Feng wrote:
>> Hi all,
> 
> Hi Lin,
> 
>> We encounter a "Resource temporarily unavailable" fail while trying
>> to offline a memory section in a movable zone. We found that there are 
>> some pages can't be migrated. The offline operation fails in function 
>> migrate_page_move_mapping() returning -EAGAIN till timeout because 
>> the if assertion 'page_count(page) != 1' fails.
> 
> is this something that worked before? if yes (then it's a regression)
> do you know with which kernel?

I think it's a problem exist long ago since we got the offline feature,
while I'm not sure from which version :)

It can only be reproduce by a zone-movable configured system holding 
pages allocated by get_user_pages() for a long time. 

Maybe we could also reproduce it by write a app just calls io_setup()
syscall and never release until it dies.  Then locate the memory section 
from which pages are allocated and try to offline it.
 
In fact if one doesn't want to use offline/hotplug memory feature, 
to whom it's not a bug :)

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

RE: [PATCH v3 4/4] input: Cypress PS/2 Trackpad simulated multitouch

[Dudley Du]

> Instead of SEMI_MT, present a full mt interface with simulated contact 
> positions for >=3 fingers.  Enables e.g. multi-finger tap and drag.
>
> Signed-off-by: Kamal Mostafa 
> ---
>  drivers/input/mouse/cypress_ps2.c |   16 
>  drivers/input/mouse/cypress_ps2.h |   14 +-
>  2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/cypress_ps2.c 
> b/drivers/input/mouse/cypress_ps2.c
> index 472342a..bbaa9b9 100644
> --- a/drivers/input/mouse/cypress_ps2.c
> +++ b/drivers/input/mouse/cypress_ps2.c
> @@ -408,7 +408,9 @@ static int cypress_set_input_params(struct input_dev 
> *input,
>   return ret;
>   }
>
> +#if ( CYPRESS_SIMULATED_MT != 1 )
>   __set_bit(INPUT_PROP_SEMI_MT, input->propbit);
> +#endif
>
>   if (cytp->tp_res_x && cytp->tp_res_x) {


Here, should be "if (cytp->tp_res_x && cytp->tp_res_y) {".
And since cytp->tp_max_abs_y read from trackpad maybe zero, so we should better 
double check here.


>   input_abs_set_res(input, ABS_X, cytp->tp_res_x); @@ 
> -531,6 +533,20 @@ static int cypress_parse_packet(struct psmouse *psmouse,
>   ((packet[5] & 0x0f) << 8) | packet[7];
>   if (cytp->mode & CYTP_BIT_ABS_PRESSURE)
>   report_data->contacts[1].z = 
> report_data->contacts[0].z;
> +#if ( CYPRESS_SIMULATED_MT == 1 )
> + /* simulate contact positions for >2 fingers */
> + if ( report_data->contact_cnt >= 3 )
> + for ( i=1; icontact_cnt; i++ ) {
> + report_data->contacts[i].x =
> + report_data->contacts[0].x
> + + 100*(i)*((i%2)?-1:1);
> + report_data->contacts[i].y =
> + report_data->contacts[0].y;
> + if (cytp->mode & CYTP_BIT_ABS_PRESSURE)
> + report_data->contacts[i].z =
> + report_data->contacts[0].z;
> + }
> +#endif
>   }
>
>   report_data->left = (header_byte & BTN_LEFT_BIT) ? 1 : 0; diff 
> --git a/drivers/input/mouse/cypress_ps2.h b/drivers/input/mouse/cypress_ps2.h
> index ce70462..4b903a9 100644
> --- a/drivers/input/mouse/cypress_ps2.h
> +++ b/drivers/input/mouse/cypress_ps2.h
> @@ -134,7 +134,19 @@
>  #define RESP_SMBUS_BIT  0x80
>
>  #define CYTP_MAX_CONTACTS 5
> -#define CYTP_MAX_MT_SLOTS 2
> +
> +/*
> + * CYPRESS_SIMULATED_MT
> + *   set to 1 for simulated multitouch (up to CTYP_MAX_CONTACTS fingers)
> + *   set to 0 for SEMI_MT (2 fingers only)
> + */
> +#define CYPRESS_SIMULATED_MT 1
> +
> +#if ( CYPRESS_SIMULATED_MT == 1 )
> +# define CYTP_MAX_MT_SLOTS 16
> +#else
> +# define CYTP_MAX_MT_SLOTS 2
> +#endif
>
>  enum cytp_type {
>   CYTP_STG,
> --
> 1.7.10.4


This message and any attachments may contain Cypress (or its subsidiaries) 
confidential information. If it has been received in error, please advise the 
sender and immediately delete this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/18] perf ui/hist: Add support for event group view

[Namhyung Kim]

Hi Jiri,

On Fri, Nov 30, 2012 at 10:29 PM, Jiri Olsa  wrote:
> On Thu, Nov 29, 2012 at 03:38:40PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>> +#define __HPP_COLOR_PERCENT_FN(_type, _field)   
>>  \
>> +static int hpp__color_##_type(struct perf_hpp *hpp, struct hist_entry *he)  
>>  \
>> +{   
>>  \
>> + int ret;   
>>  \
>> + double percent = 0.0;  
>>  \
>> + struct hists *hists = he->hists;   
>>  \
>> +
>>  \
>> + if (hists->stats.total_period) 
>>  \
>> + percent = 100.0 * he->stat._field / hists->stats.total_period; 
>>  \
>> +
>>  \
>> + ret = percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%", 
>> percent); \
>> +
>>  \
>> + if (symbol_conf.event_group) { 
>>  \
>> + int i; 
>>  \
>> + struct perf_evsel *evsel = hists_to_evsel(hists);  
>>  \
>> + struct hist_entry *pair;   
>>  \
>> + int nr_members = evsel->nr_members;
>>  \
>> + double *percents;  
>>  \
>> +
>>  \
>> + if (nr_members <= 1)   
>>  \
>> + return ret;
>>  \
>> +
>>  \
>> + percents = zalloc(sizeof(*percents) * nr_members); 
>>  \
>> + if (percents == NULL) {
>>  \
>> + pr_warning("Not enough memory!\n");
>>  \
>> + return ret;
>>  \
>> + }  
>>  \
>> +
>>  \
>> + list_for_each_entry(pair, >pairs.head, pairs.node) {   
>>  \
>> + u64 period = pair->stat._field;
>>  \
>> + u64 total = pair->hists->stats.total_period;   
>>  \
>> +
>>  \
>> + if (!total)
>>  \
>> + continue;  
>>  \
>> +
>>  \
>> + evsel = hists_to_evsel(pair->hists);   
>>  \
>> + i = perf_evsel__group_idx(evsel);  
>>  \
>> + percents[i] = 100.0 * period / total;  
>>  \
>> + }  
>>  \
>> +
>>  \
>> + for (i = 1; i < nr_members; i++) { 
>>  \
>> + ret += percent_color_snprintf(hpp->buf + ret,  
>>  \
>> +   hpp->size - ret, 
>>  \
>> +   " %6.2f%%", 
>> percents[i]); \
>> + }  
>>  \
>> + free(percents);
>>  \
>> + }  
>>  \
>> + return ret;
>>  \
>> +}
>
> ok, so this is the part thats common for both multi diff and group
> report and hugely depends on how we link matching hist_entry
>
> To sum to what group report does here:
>
> 1) starting with event group
> 2) the function 'he' belongs to leader hists
> 3) display leaders data value
> 4) if 'symbol_conf.event_group' is enabled, we want to display all
>group members data values in a column
> 5) say we have group of 3 events 'e1,e2,e3' and e1 being the leader,
>we have following possibilities:
>- e1 have no pairs
>- e1 is paired with e2
>- e1 is paired with e3
>- e1 is paired with e2 and e3 (e1 could also be dummy one)
> 6) need to display 

RE: [PATCH] EXTCON: Get and set cable properties

[Tc, Jenny]

> We discussed about this patch and then suggest some method to resolve this
> issue by Myungjoo Ham. Why don't you write additional feature or your
> opinion based on following patch by Myungjoo Ham?
> -
> http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commitdiff;h=73
> 12b79d69a2b9f06af4f1254bc4644751e3e3ea
> 

I replied on the thread and pointed out issues that I see with this solution. 
IMHO
It's not fair to register a cable with power_supply/regulator/charger manager 
just to
expose the cable properties. 

> 
> On 11/28/2012 06:49 AM, Jenny TC wrote:
> > Existing EXTCON implementation doesn't give a mechanim to read the
> > cable properties and extra states a cable needs to support. There are
> > scenarios where a cable can have more than two
> > states(CONNECT/DISCONNECT/SUSPEND/RESUME etc) and can have some
> > properties associated with cables(mA)
> >
> > This patch introduces interface to get and set cable properties from
> > EXTCON framework. The cable property can be set either by the extcon
> > cable provider or by other subsystems who know the cable properties
> > using eth API extcon_cable_set_data()
> >
> > When the consumer gets a notification from the extcon, it can use the
> > extcon_cable_get_data() to get the cable properties irrespective of
> > who provides the cable data.
> >
> > This gives a single interface for setting and getting the cable properties.
> >
> > Signed-off-by: Jenny TC 
> > ---
> >  drivers/extcon/extcon-class.c |   30
> ++
> >  include/linux/extcon.h|   39
> +++
> >  2 files changed, 69 insertions(+)
> >
> > diff --git a/drivers/extcon/extcon-class.c
> > b/drivers/extcon/extcon-class.c index d398821..304f343 100644
> > --- a/drivers/extcon/extcon-class.c
> > +++ b/drivers/extcon/extcon-class.c
> > @@ -545,6 +545,36 @@ int extcon_unregister_notifier(struct extcon_dev
> > *edev,  }  EXPORT_SYMBOL_GPL(extcon_unregister_notifier);
> >
> > +/**
> > + * extcon_cable_set_data() - Set the data structure for a cable
> > + * @edev:  the extcon device
> > + * @cable_index:   the cable index of the correspondant
> > + * @type:  type of the data structure
> > + * @data:
> > + */
> > +void extcon_cable_set_data(struct extcon_dev *edev, int cable_index,
> > +  enum extcon_cable_name type,
> > +  union extcon_cable_data data)
> > +{
> > +   edev->cables[cable_index].type = type;
> > +   edev->cables[cable_index].data = data; }
> > +
> > +/**
> > + * extcon_cable_get_data() - Get the data structure for a cable
> > + * @edev:  the extcon device
> > + * @cable_index:   the cable index of the correspondant
> > + * @type:  type of the data structure
> > + * @data:  the corresponding data structure (e.g., regulator)
> > + */
> > +void extcon_cable_get_data(struct extcon_dev *edev, int cable_index,
> > +  enum extcon_cable_name *type,
> > +  union extcon_cable_data *data)
> > +{
> > +   *type = edev->cables[cable_index].type;
> > +   *data = edev->cables[cable_index].data; }
> > +
> >  static struct device_attribute extcon_attrs[] = {
> > __ATTR(state, S_IRUGO | S_IWUSR, state_show, state_store),
> > __ATTR_RO(name),
> > diff --git a/include/linux/extcon.h b/include/linux/extcon.h index
> > 2c26c14..4556cc5 100644
> > --- a/include/linux/extcon.h
> > +++ b/include/linux/extcon.h
> > @@ -135,6 +135,19 @@ struct extcon_dev {
> > struct device_attribute *d_attrs_muex;  };
> >
> > +/* FIXME: Is this the right place for this structure definition?
> > + * Do we need to move it to power_supply.h?
> > + */
> > +struct extcon_chrgr_cable_props {
> > +   unsigned long state;
> > +   int mA;
> > +};
> 
> As I said, extcon provider driver didn't provide directly charging current(int
> mA) and some state(unsigned long state) because the extcon provider
> driver(Micro USB interface controller device or other device related to
> external connector) haven't mechanism which detect dynamically charging
> current immediately. If you wish to provide charging current data to extcon
> consumer driver or framework, you should use regulator/power_supply
> framework or other method in extcon provider driver.
> 
> The patch suggested by Myungjoo Ham define following struct:
>   union extcon_cable_data {
>   struct regualtor *reg;  /* EXTCON_CT_REGULATOR */
>   struct power_supply *psy; /* EXTCON_CT_PSY */
>   struct charger_cable *charger; /*
> EXTCON_CT_CHARGER_MANAGER */
>   /* Please add accordingly with enum extcon_cable_type */
>   };
> 
> Also if you want to define 'struct extcon_chrgr_cable_props', you should
> certainly show how detect dynamically charging current or state.
> 
> > +
> > +union extcon_cable_data {
> > +   struct extcon_chrgr_cable_props chrgr_cbl_props;
> > +   /* Please add accordingly*/
> > +};
> > +
> >  /**
> >   * struct extcon_cable - An internal data 

Re: [PATCH 12/18] perf ui/hist: Add support for event group view

[Namhyung Kim]

On Fri, 30 Nov 2012 10:52:15 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 30, 2012 at 02:29:43PM +0100, Jiri Olsa escreveu:
>> On Thu, Nov 29, 2012 at 03:38:40PM +0900, Namhyung Kim wrote:
>> > +#define __HPP_COLOR_PERCENT_FN(_type, _field) 
>> > \
>> > +static int hpp__color_##_type(struct perf_hpp *hpp, struct hist_entry 
>> > *he)\
>> > +{ 
>> > \
>> > +  int ret;
>> > \
>> > +  double percent = 0.0;   
>> > \
>> > +  struct hists *hists = he->hists;
>> > \
>> > +  
>> > \
>> > +  if (hists->stats.total_period)  
>> > \
>> > +  percent = 100.0 * he->stat._field / hists->stats.total_period;  
>> > \
>> > +  
>> > \
>> > +  ret = percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%", percent); 
>> > \
>> > +  
>> > \
>> > +  if (symbol_conf.event_group) {  
>> > \
>> > +  int i;  
>> > \
>> > +  struct perf_evsel *evsel = hists_to_evsel(hists);   
>> > \
>> > +  struct hist_entry *pair;
>> > \
>> > +  int nr_members = evsel->nr_members; 
>> > \
>> > +  double *percents;   
>> > \
>> > +  
>> > \
>> > +  if (nr_members <= 1)
>> > \
>> > +  return ret; 
>> > \
>> > +  
>> > \
>> > +  percents = zalloc(sizeof(*percents) * nr_members);  
>> > \
>> > +  if (percents == NULL) { 
>> > \
>> > +  pr_warning("Not enough memory!\n"); 
>> > \
>> > +  return ret; 
>> > \
>> > +  }   
>> > \
>
> Why do we need to zalloc this percents array?
>
>> > +  list_for_each_entry(pair, >pairs.head, pairs.node) {
>> > \
>> > +  u64 period = pair->stat._field; 
>> > \
>> > +  u64 total = pair->hists->stats.total_period;
>> > \
>> > +  
>> > \
>> > +  if (!total) 
>> > \
>> > +  continue;   
>> > \
>> > +  
>> > \
>> > +  evsel = hists_to_evsel(pair->hists);
>> > \
>> > +  i = perf_evsel__group_idx(evsel);   
>> > \
>> > +  percents[i] = 100.0 * period / total;   
>> > \
>
> Why not use percent_color_snprintf here, using some "%*s" thing that
> uses i to position the output in the right column? This way the
> following loop can be ditched as well. No?

It's because it's possible that an entry didn't have pairs for every
group member.  Say, there's a group consists of 3 members (1 leader + 2
member).  It's quite legitimate that a leader hist entry has just one
pair for a member and miss another.  So I allocated a zero-filled array,
and filled what it has, and print them all in the for loop below.

Thanks,
Namhyung

>
>> > +  }   
>> > \
>> > +  
>> > \
>> > +  for (i = 1; i < nr_members; i++) {  
>> > \
>> > +  ret += percent_color_snprintf(hpp->buf + ret,   
>> > \
>> > +hpp->size - ret,  
>> > \
>> > +" %6.2f%%", percents[i]); 
>> > \
>> > +  }   
>> > \
>> > +  free(percents); 
>> > \
>> > +  }   
>> > \
>> > +  return ret; 
>> > \
>
> - Arnaldo
--
To unsubscribe from this 

[PATCH RESEND] cgroup: remove subsystem files when remounting cgroup

[Gao feng]

cgroup_clear_directroy is called by cgroup_d_remove_dir
and cgroup_remount.

when we call cgroup_remount to remount the cgroup,the subsystem
may be unlinked from cgroupfs_root->subsys_list in rebind_subsystem,this
subsystem's files will not be removed in cgroup_clear_directroy.
And the system will panic when we try to access these files.

this patch removes subsystems's files before rebind_subsystems,
if rebind_subsystems failed, repopulate these removed files.

With help from Tejun.

Signed-off-by: Gao feng 
---
 kernel/cgroup.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e1293a9..afabd2a 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1349,14 +1349,21 @@ static int cgroup_remount(struct super_block *sb, int 
*flags, char *data)
goto out_unlock;
}
 
+   /*
+* Clear out the files of subsystems that should be removed,do
+* this job before rebind_subsystems,since rebind_subsystems may
+* change this hierarchy's subsys_list.
+*/
+   cgroup_clear_directory(cgrp->dentry, false, removed_mask);
+
ret = rebind_subsystems(root, opts.subsys_mask);
if (ret) {
+   /* rebind_subsystems failed,re-populate the removed files */
+   cgroup_populate_dir(cgrp, false, removed_mask);
drop_parsed_module_refcounts(opts.subsys_mask);
goto out_unlock;
}
 
-   /* clear out any existing files and repopulate subsystem files */
-   cgroup_clear_directory(cgrp->dentry, false, removed_mask);
/* re-populate subsystem files */
cgroup_populate_dir(cgrp, false, added_mask);
 
-- 
1.7.7.6

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

Re: [PATCH 07/18] perf hists: Exchange order of comparing items when collapsing hists

[Namhyung Kim]

On Thu, 29 Nov 2012 15:52:57 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 29, 2012 at 03:38:35PM +0900, Namhyung Kim escreveu:
>> From: Namhyung Kim 
>> 
>> When comparing entries for collapsing put the given entry first, and
>> then the iterated entry.  This is for the sake of consistency and will
>
> consistency with what? and, see below:
>
>> be required by the event group report.
>> 
>> Cc: Jiri Olsa 
>> Cc: Stephane Eranian 
>> Signed-off-by: Namhyung Kim 
>> ---
>>  tools/perf/util/hist.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
>> index 82df1b26f0d4..161c35e7ed0e 100644
>> --- a/tools/perf/util/hist.c
>> +++ b/tools/perf/util/hist.c
>> @@ -433,7 +433,7 @@ static bool hists__collapse_insert_entry(struct hists 
>> *hists __maybe_unused,
>>  parent = *p;
>>  iter = rb_entry(parent, struct hist_entry, rb_node_in);
>>  
>> -cmp = hist_entry__collapse(iter, he);
>> +cmp = hist_entry__collapse(he, iter);
>>  
>>  if (!cmp) {
>>  he_stat__add_stat(>stat, >stat);
>
> doesn't this now gets inconsistent with the hist_entry__collapse() call?
> I.e. iter first, he after, also there is the case for callchains, below,
> care to elaborate here?

I meant it by consistent with hist_entry__cmp() and didn't consider
he_stat__add_stat and callchain_merge things - thought that they're
other kind of operation.

I needed this change because I introduced hists__{match,link}_collapsed
function in the patch 8 and I found that hist_entry__cmp and
hist_entry__collapse received same kind of arguments in different
order.  Sorry about missing this in the changelog.

However on the second thought, I feel like I don't need those _collapsed
functions at all and perf diff can be converted to use collapsed rb tree
directly instead.  IIUC perf diff use those functions to match entries
by sort keys and do additional resort output rb tree by sort keys (IMHO
the function names - _name_resort and _insert_by_name - are misnomers)
to do the match.

Since output resorting (by period) is only needed for the baseline,
other data files doesn't need to do this additional step.  So I can get
rid of those hists__{match,link}_collapsed functions and change plain
hists__{match,link} functions to use collapsed (or input) rb tree
directly.

Jiri, what do you think?  What am I missing? :)

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: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

[Chao Xie]

On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
 wrote:
> On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
>  wrote:
>> On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
>>> The original sa1100_rtc_open/sa1100_rtc_release will be called
>>> when the /dev/rtc0 is opened or closed.
>>> In fact, these two functions will enable/disable the clock, and
>>> register/unregister the irqs.
>>> User application will use /dev/rtc0 to read the rtc time or set
>>> the alarm. The rtc should still run indepent of open/close the
>>> rtc device.
>>> So only enable clock and register the irqs when probe the device,
>>> and disable clock and unregister the irqs when remove the device.
>>
>> NAK.  I don't think you properly understand what's going on here if you
>> think moving the entire open and release functions into the probe and
>> remove functions is the right thing to do.
>
> Since PXA27x & PXA3xx supports dual rtc device at the same time,
> user could choose use either of rtc at run time. Then clk & irq are setup
> in open().
>
> Chao,
> So you shouldn't remove them into probe().

How can user to choose one RTC?
The user API, for example "date" will open the device, get the time
and then close the device.
WHen set a alarm, it is the same routine. open->set->close.
The open routine will enable clock and register irq, close will
disable the clock and unregister irq. It means that if only open is
invoked, rtc begins to work, and after close is invoked rtc stops
working. It means that the user can not get correct time and can not
get right alarm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] bna: remove useless calls to memset().

[David Miller]

From: Cyril Roelandt 
Date: Sun,  2 Dec 2012 03:40:17 +0100

> These calls are followed by calls to memcpy() on the same memory area, so they
> can safely be removed.
> 
> Signed-off-by: Cyril Roelandt 

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] EXTCON: Get and set cable properties

[Anton Vorontsov]

On Sun, Dec 02, 2012 at 06:53:17AM +, Tc, Jenny wrote:
> Could you please review this. This is a follow up patch for "PATCH]
> extcon : callback function to read cable property"

While I see nothing wrong with the patch itself, I beg you to send some
users for the new calls. Don't be obsessed with the extcon internals too
much, think more about how things will interact (i.e. I really really want
to see how you use these calls from the power supply drivers).

Thanks,
Anton.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/18] perf header: Add HEADER_GROUP_DESC feature

[Namhyung Kim]

On Thu, 29 Nov 2012 15:43:04 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 29, 2012 at 03:38:32PM +0900, Namhyung Kim escreveu:
>> From: Namhyung Kim 
>> 
>> Save group relationship information so that it can be restored when
>> perf report is running.
>> 
[snip]
>> +static int write_group_desc(int fd, struct perf_header *h __maybe_unused,
>> +struct perf_evlist *evlist)
>> +{
>> +u32 nr_groups = evlist->nr_groups;
>> +struct perf_evsel *evsel;
>> +
>> +do_write(fd, _groups, sizeof(nr_groups));
>> +
>> +list_for_each_entry(evsel, >entries, node) {
>> +if (perf_evsel__is_group_leader(evsel) &&
>> +evsel->nr_members > 1) {
>> +const char *name = evsel->group_name ?: "{anon_group}";
>> +u32 leader_idx = evsel->idx;
>> +u32 nr_members = evsel->nr_members;
>> +
>> +do_write_string(fd, name);
>> +do_write(fd, _idx, sizeof(leader_idx));
>> +do_write(fd, _members, sizeof(nr_members));
>
> You need to check do_write() return, it can fail. There are some cases
> in header.c that don't check it, those should be eventually fixed, most
> cases check it tho.

Okay.

>
>> +}
>> +}
>> +return 0;
>> +}
[snip]
>> +static int process_group_desc(struct perf_file_section *section 
>> __maybe_unused,
>> +  struct perf_header *ph, int fd,
>> +  void *data __maybe_unused)
>> +{
>> +size_t ret = -1;
>> +u32 i, nr, nr_groups;
>> +struct perf_session *session;
>> +struct perf_evsel *evsel, *leader = NULL;
>> +struct group_desc {
>> +char *name;
>> +u32 leader_idx;
>> +u32 nr_members;
>> +} *desc;
>> +
>> +if (read(fd, _groups, sizeof(nr_groups)) != sizeof(nr_groups))
>
> Please use readn() instead in all read() cases in this function.

Will do.

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: [PATCH] EXTCON: Get and set cable properties

[Chanwoo Choi]

We discussed about this patch and then suggest some method to resolve
this issue by Myungjoo Ham. Why don't you write additional feature or
your opinion based on following patch by Myungjoo Ham?
-
http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commitdiff;h=7312b79d69a2b9f06af4f1254bc4644751e3e3ea


On 11/28/2012 06:49 AM, Jenny TC wrote:
> Existing EXTCON implementation doesn't give a mechanim to read the cable
> properties and extra states a cable needs to support. There are scenarios
> where a cable can have more than two states(CONNECT/DISCONNECT/SUSPEND/RESUME 
> etc)
> and can have some properties associated with cables(mA)
> 
> This patch introduces interface to get and set cable properties
> from EXTCON framework. The cable property can be set either by
> the extcon cable provider or by other subsystems who know the cable
> properties using eth API extcon_cable_set_data()
> 
> When the consumer gets a notification from the extcon, it can use the
> extcon_cable_get_data() to get the cable properties irrespective of who
> provides the cable data.
> 
> This gives a single interface for setting and getting the cable properties.
> 
> Signed-off-by: Jenny TC 
> ---
>  drivers/extcon/extcon-class.c |   30 ++
>  include/linux/extcon.h|   39 +++
>  2 files changed, 69 insertions(+)
> 
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index d398821..304f343 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -545,6 +545,36 @@ int extcon_unregister_notifier(struct extcon_dev *edev,
>  }
>  EXPORT_SYMBOL_GPL(extcon_unregister_notifier);
>  
> +/**
> + * extcon_cable_set_data() - Set the data structure for a cable
> + * @edev:the extcon device
> + * @cable_index: the cable index of the correspondant
> + * @type:type of the data structure
> + * @data:
> + */
> +void extcon_cable_set_data(struct extcon_dev *edev, int cable_index,
> +enum extcon_cable_name type,
> +union extcon_cable_data data)
> +{
> + edev->cables[cable_index].type = type;
> + edev->cables[cable_index].data = data;
> +}
> +
> +/**
> + * extcon_cable_get_data() - Get the data structure for a cable
> + * @edev:the extcon device
> + * @cable_index: the cable index of the correspondant
> + * @type:type of the data structure
> + * @data:the corresponding data structure (e.g., regulator)
> + */
> +void extcon_cable_get_data(struct extcon_dev *edev, int cable_index,
> +enum extcon_cable_name *type,
> +union extcon_cable_data *data)
> +{
> + *type = edev->cables[cable_index].type;
> + *data = edev->cables[cable_index].data;
> +}
> +
>  static struct device_attribute extcon_attrs[] = {
>   __ATTR(state, S_IRUGO | S_IWUSR, state_show, state_store),
>   __ATTR_RO(name),
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index 2c26c14..4556cc5 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -135,6 +135,19 @@ struct extcon_dev {
>   struct device_attribute *d_attrs_muex;
>  };
>  
> +/* FIXME: Is this the right place for this structure definition?
> + * Do we need to move it to power_supply.h?
> + */
> +struct extcon_chrgr_cable_props {
> + unsigned long state;
> + int mA;
> +};

As I said, extcon provider driver didn't provide directly charging current(int 
mA)
and some state(unsigned long state) because the extcon provider driver(Micro
USB interface controller device or other device related to external connector) 
haven't
mechanism which detect dynamically charging current immediately. If you wish to
provide charging current data to extcon consumer driver or framework, you should
use regulator/power_supply framework or other method in extcon provider driver.

The patch suggested by Myungjoo Ham define following struct:
union extcon_cable_data {
struct regualtor *reg;  /* EXTCON_CT_REGULATOR */
struct power_supply *psy; /* EXTCON_CT_PSY */
struct charger_cable *charger; /* EXTCON_CT_CHARGER_MANAGER */
/* Please add accordingly with enum extcon_cable_type */
};

Also if you want to define 'struct extcon_chrgr_cable_props', you should 
certainly show how
detect dynamically charging current or state.

> +
> +union extcon_cable_data {
> + struct extcon_chrgr_cable_props chrgr_cbl_props;
> + /* Please add accordingly*/
> +};
> +
>  /**
>   * struct extcon_cable   - An internal data for each cable of extcon 
> device.
>   * @edev The extcon device
> @@ -143,6 +156,8 @@ struct extcon_dev {
>   * @attr_name"name" sysfs entry
>   * @attr_state   "state" sysfs entry
>   * @attrsArray pointing to attr_name and attr_state for attr_g
> + * @type:The type of @data.
> + * @data:The data structure representing 

Re: [PATCH 03/18] perf tools: Keep group information

[Namhyung Kim]

Hi Arnaldo,

On Thu, 29 Nov 2012 16:09:22 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 30, 2012 at 12:09:11AM +0900, Namhyung Kim escreveu:
>> 2012-11-29 (목), 16:02 +0100, Jiri Olsa:
>> > > You mean adding 'evsel->nr_members > 1' to this function?  For some
>> > > reason, I'd like to treat non-group events as group leaders so I dropped
>> > > that check from the function.
>> > 
>> > nope, the change is ok, I meant updating automated tests in 
>> > tests/parse-events.c
>> 
>> Ah, okay.  Always forgot to update the test. :(  Will add.
>
> Also consider adding more tests, perhaps for the formatting, i.e.
> calling those hpp functions and then checking that the resulting
> formatted string is the one expected.
>
> One thing I need to do is to create a test that uses slang to write a
> line with callchains and then, without updating the screen, check if
> what is buffered to refresh the screen is what we expect, so that we can
> check that that '+' char isn't lost like it happened twice :-)

Yep, will try.

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/

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

[Stephen Rothwell]

Hi Nicholas,

Today's linux-next merge of the target-updates tree got a conflict in
drivers/target/target_core_transport.c between commit 3ea160b3e8f0
("target: Fix handling of aborted commands") from Linus' tree and commit
019c4ca62148 ("target: kill dev->dev_task_attr_type") from the
target-updates tree.

I just use the target-updates tree version and can carry the fix as
necessary (no action is required).

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


pgpoD4vPyEh6f.pgp
Description: PGP signature

Re: Re: Re: Re: Re: Re: Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset

[Yoshihiro YUNOMAE]

Hi Marcelo,


That is, you can't feed distinct instances of guest kernel trace.


I'm not clear for "distinct instances". Is this about SMP or multiple
guests? Would you explain about this?


Distinct boot instances. If the guest reboots TSC can be written to.


OK, I understood.
I'll resend a patch series for this feature.

Thanks!

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.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 2/2] cgroup: remove subsystem files when remounting cgroup

[Gao feng]

Hello Tejun

on 2012/12/01 03:27, Tejun Heo wrote:
> Hello, Gao.
> 
> On Sat, Dec 01, 2012 at 12:21:29AM +0800, Gao feng wrote:
>> cgroup_clear_directroy is called by cgroup_d_remove_dir
>> and cgroup_remount.
>>
>> when we call cgroup_remount to remount the cgroup,the subsystem
>> may be unlinked from cgroupfs_root->subsys_list in rebind_subsystem,this
>> subsystem's files will not be removed in cgroup_clear_directroy.
>> And the system will panic when we try to access these files.
>>
>> this patch fix it.
> 
> I'd really appreciated if you explain how it's fixed.
> 
>> Signed-off-by: Gao feng 
>> ---
>>  kernel/cgroup.c |   86 
>> ++
>>  1 files changed, 54 insertions(+), 32 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index e5233b7..90429d5 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -982,10 +982,14 @@ static void cgroup_clear_directory(struct dentry *dir, 
>> bool base_files,
>> unsigned long subsys_mask)
>>  {
>>  struct cgroup *cgrp = __d_cgrp(dir);
>> -struct cgroup_subsys *ss;
>> +int i;
>>  
>> -for_each_subsys(cgrp->root, ss) {
>> +for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
>>  struct cftype_set *set;
>> +struct cgroup_subsys *ss = subsys[i];
>> +
>> +if (ss == NULL)
>> +continue;
> 
> Ummm... I can't say I like it.  It tries to work around the problem
> that the backing subsys may go away earlier by changing how the
> subsystems are iterated so that the "gone" subsystems can be iterated,
> which really doesn't seem like a good diea.  I mean, what if somebody
> tries to access the files inbetween?  root_cgrp->subsys[] would be
> %NULL and segfault all the same.
> 

Yes,You are right.I didn't consider this problem.

>>  static void drop_parsed_module_refcounts(unsigned long subsys_mask)
>> @@ -1392,23 +1403,34 @@ static int cgroup_remount(struct super_block *sb, 
>> int *flags, char *data)
>>  removed_mask = root->subsys_mask & ~opts.subsys_mask;
>>  
>>  /* Don't allow flags or name to change at remount */
>> +ret = -EINVAL;
>>  if (opts.flags != root->flags ||
>>  (opts.name && strcmp(opts.name, root->name))) {
>> -ret = -EINVAL;
>>  drop_parsed_module_refcounts(opts.subsys_mask);
>>  goto out_unlock;
>>  }
>>  
>> -ret = rebind_subsystems(root, opts.subsys_mask);
>> +/*
>> + * Add the reference of these removed subsystem,we
>> + * need use subsystems to remove their cgroup files.
>> + */
>> +ret = cgroup_get_module_refcounts(removed_mask);
>>  if (ret) {
>>  drop_parsed_module_refcounts(opts.subsys_mask);
>>  goto out_unlock;
>>  }
>>  
>> +ret = rebind_subsystems(root, opts.subsys_mask);
>> +if (ret) {
>> +drop_parsed_module_refcounts(opts.subsys_mask | removed_mask);
>> +goto out_unlock;
>> +}
>> +
>>  /* clear out any existing files and repopulate subsystem files */
>>  cgroup_clear_directory(cgrp->dentry, false, removed_mask);
>>  /* re-populate subsystem files */
>>  cgroup_populate_dir(cgrp, false, added_mask);
>> +drop_parsed_module_refcounts(removed_mask);
> 
> So, how about performing cgroup_clear_directory() *before*
> rebind_subsystems() and then restore it afterwards?
> 

Get it,will fix this problem as you said.

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/

[GIT] Networking

[David Miller]

1) 8139cp leaks memory in error paths, from Francois Romieu.

2) do_tcp_sendpages() cannot handle order > 0 pages, but they can
   certainly arrive there now, fix from Eric Dumazet.

3) Race condition and sysfs fixes in bonding from Nikolay Aleksandrov.

4) Remain-on-Channel fix in mac80211 from Felix Liao.

5) CCK rate calculation fix in iwlwifi, from Emmanuel Grumbach.

Please pull, thanks a lot!

The following changes since commit e9296e89b85604862bd9ec2d54dc43edad775c0d:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-11-28 
21:54:07 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master

for you to fetch changes up to 892a925e42adb8192a3c832ad29cbc780fc466f6:

  8139cp: fix coherent mapping leak in error path. (2012-12-01 20:39:17 -0500)


Emmanuel Grumbach (1):
  iwlwifi: fix the basic CCK rates calculation

Eric Dumazet (1):
  tcp: fix crashes in do_tcp_sendpages()

Johannes Berg (1):
  mac80211: fix remain-on-channel (non-)cancelling

John W. Linville (2):
  Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge branch 'master' of git://git.kernel.org/.../linville/wireless into 
for-davem

françois romieu (1):
  8139cp: fix coherent mapping leak in error path.

niko...@redhat.com (3):
  bonding: fix miimon and arp_interval delayed work race conditions
  bonding: make arp_ip_target parameter checks consistent with sysfs
  bonding: fix race condition in bonding_store_slaves_active

 drivers/net/bonding/bond_main.c | 93 
+--
 drivers/net/bonding/bond_sysfs.c| 36 +-
 drivers/net/ethernet/realtek/8139cp.c   | 11 +---
 drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 -
 net/ipv4/tcp.c  | 15 +--
 net/mac80211/offchannel.c   |  2 --
 6 files changed, 61 insertions(+), 108 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: [GIT] Networking

[David Miller]

From: Linus Torvalds 
Date: Sun, 2 Dec 2012 16:13:30 -0800

> David, Willy pointed me to the recent splice crash fix
> (do_tcp_sendpages and non-0-order pages). It's apparently easily
> user-triggerable.. Should I take the patch directly, or do you have a
> tree to pull. Don't want to make a release with a known oopser..

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