twitter: linux.kernel - 25 new messages in 11 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

==============================================================================
TOPIC: vhost: fix get_user_pages_fast error handling
http://groups.google.com/group/linux.kernel/t/6d34842811e8cad6?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 11:10 pm
From: David Miller

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 24 Feb 2010 07:37:37 +0200

> Dave, so while Rusty's on vacation, what's the best way to get vhost
> infrastructure fixes in? Are you ok with getting pull requests and
> merging them into net-next? That should keep the clutter in your inbox
> to the minimum.
>
> Of course network changes would still go the usual way.

Well, who is providing oversight of vhost work while he's
gone? Has he, implicitly or explicitly, appointed a maintainer
while he's away?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: mqueue: remove unneeded info->messages initialization
http://groups.google.com/group/linux.kernel/t/c6dc8b3858bd90e9?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Feb 23 2010 11:20 pm
From: André Goddard Rosa

... and abort earlier if we couldn't allocate the message pointers array,
avoiding the u->mq_bytes accounting logic.

It reduces code size:
text data bss dec hex filename
9949 72 16 10037 2735 ipc/mqueue-BEFORE.o
9941 72 16 10029 272d ipc/mqueue-AFTER.o

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
---
ipc/mqueue.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index c79bd57..2d76647 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -134,7 +134,6 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
init_waitqueue_head(&info->wait_q);
INIT_LIST_HEAD(&info->e_wait_q[0].list);
INIT_LIST_HEAD(&info->e_wait_q[1].list);
- info->messages = NULL;
info->notify_owner = NULL;
info->qsize = 0;
info->user = NULL; /* set when all is ok */
@@ -146,6 +145,10 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
info->attr.mq_msgsize = attr->mq_msgsize;
}
mq_msg_tblsz = info->attr.mq_maxmsg * sizeof(struct msg_msg *);
+ info->messages = kmalloc(mq_msg_tblsz, GFP_KERNEL);
+ if (!info->messages)
+ goto out_inode;
+
mq_bytes = (mq_msg_tblsz +
(info->attr.mq_maxmsg * info->attr.mq_msgsize));

@@ -154,18 +157,12 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
u->mq_bytes + mq_bytes >
p->signal->rlim[RLIMIT_MSGQUEUE].rlim_cur) {
spin_unlock(&mq_lock);
+ kfree(info->messages);
goto out_inode;
}
u->mq_bytes += mq_bytes;
spin_unlock(&mq_lock);

- info->messages = kmalloc(mq_msg_tblsz, GFP_KERNEL);
- if (!info->messages) {
- spin_lock(&mq_lock);
- u->mq_bytes -= mq_bytes;
- spin_unlock(&mq_lock);
- goto out_inode;
- }
/* all is ok */
info->user = get_uid(u);
} else if (S_ISDIR(mode)) {
--
1.7.0.87.g0901d

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

== 2 of 4 ==
Date: Tues, Feb 23 2010 11:20 pm
From: André Goddard Rosa

It can be triggered by the following test program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <mqueue.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/stat.h>
#include <sys/resource.h>

int main(int argc, char *argv[])
{
struct rlimit limit;
char queue_name[] = "/mq_open/bug";
char tmp_name[] = "/tmp/tmp";
int fd, i = 1;

if (getrlimit(RLIMIT_NOFILE, &limit) != 0) {
printf("%s\n", "Failed to get RLIMIT_NOFILE");
return EXIT_FAILURE;
}
printf("Max number of open files is: %d\n", limit.rlim_cur);

while (i <= limit.rlim_cur) {
mqd_t queue;

errno = 0;
queue = mq_open(queue_name, O_CREAT |O_RDWR, S_IRUSR | S_IWUSR
, NULL);
if (queue != (mqd_t)-1) {
/* Success opening mqueue, no leak will happen */
printf("Successfully opened an mqueue[%d]\n", queue);
printf("mq_close(%d) = %d\n", queue, mq_close(queue));
return EXIT_SUCCESS;
}
/* Failed to open mqueue, maybe a leak is happening... */
if (errno == EMFILE)
{
printf("\nRun out of file descriptors");
break;
}
printf("\rLeaking [%d] files?!?!", i++);
fflush(stdout);
usleep(500);
}
/* Double check that no file descriptor is available anymore indeed */
putchar('\n');
errno = 0;
fd = open(tmp_name, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if (fd == -1) {
printf("open() failed: %s\n", strerror(errno));
if (errno == EMFILE) {
printf("%s\n", "Cannot open new files, fds exhausted");
return EXIT_FAILURE;
}
} else
printf("close(%d) = %d\n", fd, close(fd));
printf("%s\n", "Expected output: kernel is not leaking any fds!");

return EXIT_SUCCESS;
}

## Preparing for testing

$ touch /tmp/tmp
$ gcc -g main_mq_open_fd_leak.c -lrt

## Linux kernel with the fix applied:

$ ./a.out
Max number of open files is: 1024
Leaking [1024] files?!?!
close(3) = 0
Expected output: kernel is not leaking any fds!

## Linux kernel without the fix:

## Shell execution:

$ ./a.out
Max number of open files is: 1024
Leaking [1019] files?!?!
Run out of file descriptors
Segmentation fault

## Valgrind execution:

$ valgrind --track-fds=yes ./a.out
==2895== Memcheck, a memory error detector
==2895== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2895== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==2895== Command: ./a.out
==2895==
Max number of open files is: 1024
Leaking [1024] files?!?!
open() failed: Too many open files
Cannot open new files, fds exhausted
==2895==
==2895== FILE DESCRIPTORS: 5 open at exit.
==2895== Open file descriptor 13:
==2895== <inherited from parent>
==2895==
==2895== Open file descriptor 12:
==2895== <inherited from parent>
==2895==
==2895== Open file descriptor 2: /dev/pts/1
==2895== <inherited from parent>
==2895==
==2895== Open file descriptor 1: /dev/pts/1
==2895== <inherited from parent>
==2895==
==2895== Open file descriptor 0: /dev/pts/1
==2895== <inherited from parent>
==2895==
==2895==
==2895== HEAP SUMMARY:
==2895== in use at exit: 0 bytes in 0 blocks
==2895== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2895==
==2895== All heap blocks were freed -- no leaks are possible
==2895==
==2895== For counts of detected and suppressed errors, rerun with: -v
==2895== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

When not running valgrind, user-space program segfaults trying to execute
strerror(errno). With valgrind, it executes successfully and prints the
5 open files: stdin, stdout, stderr, pipe[0] and pipe[1].

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
---
ipc/mqueue.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index e47c9eb..b6cb064 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -710,7 +710,7 @@ SYSCALL_DEFINE4(mq_open, const char __user *, u_name, int, oflag, mode_t, mode,
dentry = lookup_one_len(name, ipc_ns->mq_mnt->mnt_root, strlen(name));
if (IS_ERR(dentry)) {
error = PTR_ERR(dentry);
- goto out_err;
+ goto out_putfd;
}
mntget(ipc_ns->mq_mnt);

@@ -749,7 +749,6 @@ out:
mntput(ipc_ns->mq_mnt);
out_putfd:
put_unused_fd(fd);
-out_err:
fd = error;
out_upsem:
mutex_unlock(&ipc_ns->mq_mnt->mnt_root->d_inode->i_mutex);
--
1.7.0.87.g0901d

== 3 of 4 ==
Date: Tues, Feb 23 2010 11:20 pm
From: André Goddard Rosa

Code size reduction:
text data bss dec hex filename
9941 72 16 10029 272d ipc/mqueue-BEFORE.o
9925 72 16 10013 271d ipc/mqueue-AFTER.o

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
---
ipc/mqueue.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 2d76647..04403fd 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -261,8 +261,9 @@ static void mqueue_delete_inode(struct inode *inode)

clear_inode(inode);

- mq_bytes = (info->attr.mq_maxmsg * sizeof(struct msg_msg *) +
- (info->attr.mq_maxmsg * info->attr.mq_msgsize));
+ /* Total amount of bytes accounted for the mqueue */
+ mq_bytes = info->attr.mq_maxmsg * (sizeof(struct msg_msg *)
+ + info->attr.mq_msgsize);
user = info->user;
if (user) {
spin_lock(&mq_lock);
@@ -601,8 +602,8 @@ static int mq_attr_ok(struct ipc_namespace *ipc_ns, struct mq_attr *attr)
/* check for overflow */
if (attr->mq_msgsize > ULONG_MAX/attr->mq_maxmsg)
return 0;
- if ((unsigned long)(attr->mq_maxmsg * attr->mq_msgsize) +
- (attr->mq_maxmsg * sizeof (struct msg_msg *)) <
+ if ((unsigned long)(attr->mq_maxmsg * (attr->mq_msgsize
+ + sizeof (struct msg_msg *))) <
(unsigned long)(attr->mq_maxmsg * attr->mq_msgsize))
return 0;
return 1;
--
1.7.0.87.g0901d

== 4 of 4 ==
Date: Tues, Feb 23 2010 11:20 pm
From: André Goddard Rosa

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
---
ipc/mqueue.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 906e873..e47c9eb 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -1297,7 +1297,7 @@ static int __init init_mqueue_fs(void)
if (mqueue_inode_cachep == NULL)
return -ENOMEM;

- /* ignore failues - they are not fatal */
+ /* ignore failures - they are not fatal */
mq_sysctl_table = mq_register_sysctl_table();

error = register_filesystem(&mqueue_fs_type);
--
1.7.0.87.g0901d

==============================================================================
TOPIC: per-bdi flushing model improvements. reiser4
http://groups.google.com/group/linux.kernel/t/c5d460904329cbb2?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 11:20 pm
From: Christian Kujau

On Mon, 22 Feb 2010 at 08:47, Johannes Buchner wrote:
> It'd be great if someone could solve this, as the reiser4 patch is
> not usable in its current state, with or without my illfated attempts
> to fix it.

FWIW, I'm running Linus' latest -git with refs/heads/reiser4 on top[0], no
issues during 2.6.33-git so far. Try it, if you don't like
manually applying patches either :-)

Christian.

[0] http://git.zen-kernel.org/?p=kernel/zen.git;a=shortlog;h=refs/heads/reiser4
--
BOFH excuse #275:

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

==============================================================================
TOPIC: USB mass storage and ARM cache coherency
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 11:20 pm
From: Oliver Neukum

Am Mittwoch, 24. Februar 2010 03:48:09 schrieb Benjamin Herrenschmidt:
> On Fri, 2010-02-19 at 21:53 +0100, Oliver Neukum wrote:
> > Am Freitag, 19. Februar 2010 18:36:51 schrieb Catalin Marinas:
> > > If a page is already mapped in user space, flush_dcache_page() on ARM
> > > does the flushing rather than deferring it to update_mmu_cache(). The
> > > PIO HCD drivers, however, don't call flush_dcache_page(). Is it possible
> > > that the HCD could transfer data into a page cache page already mapped
> > > in user space? My understanding is that the scenario above is possible.
> >
> > Yes, video drivers do that.
>
> In which case it would be up to the video driver to call
> flush_dcache_page() (though if it's v4l you are talking about, maybe it
> might make sense to push it into the v4l layer itself).

I don't know. The issue seems quite complex. It would seem better to
centralize it as far as practical. Do you have a wrapper drivers could
call?

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

==============================================================================
TOPIC: latency_hist: fix small memory leak
http://groups.google.com/group/linux.kernel/t/5a89e5a484626839?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 11:20 pm
From: Carsten Emde

On 02/22/2010 02:27 PM, Dan Carpenter wrote:
> index_ptr needs to be freed on the error path.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/kernel/trace/latency_hist.c b/kernel/trace/latency_hist.c
> index b3b5ea2..8edc70c 100644
> --- a/kernel/trace/latency_hist.c
> +++ b/kernel/trace/latency_hist.c
> @@ -204,8 +204,10 @@ static void *l_start(struct seq_file *m, loff_t *pos)
> , my_hist->beyond_hist_bound_samples
> , MAX_ENTRY_NUM, "samples");
> }
> - if (index >= MAX_ENTRY_NUM)
> + if (index >= MAX_ENTRY_NUM) {
> + kfree(index_ptr);
> return NULL;
> + }
>
> *index_ptr = index;
> return index_ptr;
Thanks a lot for spotting this leak. We even don't need to allocate the
memory, if index >= MAX_ENTRY_NUM.

This patch applies to 2.6.31.12-rt21 and 2.6.33-rc8-rt (rt/head).

Signed-off-by: Carsten Emde <C.Emde@osadl.org>

Index: head/kernel/trace/latency_hist.c
===================================================================
--- head.orig/kernel/trace/latency_hist.c
+++ head/kernel/trace/latency_hist.c
@@ -218,13 +218,10 @@ void notrace latency_hist(int latency_ty

static void *l_start(struct seq_file *m, loff_t *pos)
{
- loff_t *index_ptr = kmalloc(sizeof(loff_t), GFP_KERNEL);
+ loff_t *index_ptr = NULL;
loff_t index = *pos;
struct hist_data *my_hist = m->private;

- if (!index_ptr)
- return NULL;
-
if (index == 0) {
char minstr[32], avgstr[32], maxstr[32];

@@ -263,10 +260,12 @@ static void *l_start(struct seq_file *m,
MAX_ENTRY_NUM - my_hist->offset,
"samples");
}
- if (index >= MAX_ENTRY_NUM)
- return NULL;
+ if (index < MAX_ENTRY_NUM) {
+ index_ptr = kmalloc(sizeof(loff_t), GFP_KERNEL);
+ if (index_ptr)
+ *index_ptr = index;
+ }

- *index_ptr = index;
return index_ptr;
}

== 2 of 2 ==
Date: Tues, Feb 23 2010 11:30 pm
From: Carsten Emde

On 02/22/2010 02:29 PM, Dan Carpenter wrote:
> kernel/trace/latency_hist.c
> 373 static ssize_t
> 374 latency_hist_show_maxlatproc(struct file *filp, char __user *ubuf,
> 375 size_t cnt, loff_t *ppos)
> 376 {
> 377 char buf[1024];
>
> This is a large buffer to put on the stack.
Thanks!

Remove stack allocation of buffer space, use dyn memory instead.
Use a better assumption to estimate the required buffer space.

Signed-off-by: Carsten Emde <C.Emde@osadl.org>

==============================================================================
TOPIC: tracing: Remove CONFIG_TRACE_POWER from kernel config
http://groups.google.com/group/linux.kernel/t/6c13be7f7a5cc344?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 11:30 pm
From: Li Zefan

The power tracer has been converted to power trace events.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
kernel/trace/Kconfig | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 928b289..745d01c 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -341,15 +341,6 @@ config BRANCH_TRACER

Say N if unsure.

-config POWER_TRACER
- bool "Trace power consumption behavior"
- depends on X86
- select GENERIC_TRACER
- help
- This tracer helps developers to analyze and optimize the kernel's
- power management decisions, specifically the C-state and P-state
- behavior.
-
config KSYM_TRACER
bool "Trace read and write access on kernel memory locations"
depends on HAVE_HW_BREAKPOINT
--
1.6.3

==============================================================================
TOPIC: from mr pedrosinger
http://groups.google.com/group/linux.kernel/t/1db1e04394bb34eb?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 11:30 pm
From: pedrosinger

from mr pedrosinger

Greeting from Burkina Faso
This brief introductory letter may come to you as a big surprise, but I believe it is only a day that people meet and become great friends and business partners. I am Mr. pedrosinger, currently Head of Corporate affairs with a reputable bank here in Burkina Faso , West Africa . And would like to enter into a confidential business deal with you upon your acceptance to co-operate with me I will let you know the details.
Thanking you in advance and waiting for your urgent reply.
please call me if you are interested
Tel: +226-7698-4378
Regards,
Mr. pedrosinger.

==============================================================================
TOPIC: linux-next requirements
http://groups.google.com/group/linux.kernel/t/68d372e561eb8d5e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 11:30 pm
From: Stephen Rothwell

[I have removed linux-tip-commits from the cc list]

Hi Ingo,

On Tue, 23 Feb 2010 09:45:52 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> Developers simply cannot be expected to build for 22 architectures, and they
> shouldnt be.

I have agreed with this point of yours several times. Why do you keep
stating it?

> The thing is, last i checked you didnt even _test_ x86 as the first step in
> your linux-next build tests. Most of your generic build bug reports are
> against PowerPC. They create the appearance that x86 is a second class citizen
> in linux-next.

Lets see. Over the last 60 days, I have reported 37 build errors. Of
these, 16 were reported against x86, 14 against ppc, 7 against other
archs. Of the ppc reports, 10 would not affect x86 builds (due to being
ppc specific problems or dependencies on implicit includes that do happen on
x86). None of the reports against other arches would affect x86 builds.

I also reported 31 warnings. 15 against x86, 15 against ppc and 1 against
both. Of those only reported against ppc, 13 did not affect x86.

So of my "generic" reports, 4 errors and 2 warnings were reported against
ppc, 16 errors and 15 warnings again x86.

Also, I am not sure how reports of 37 build errors and 32 warnings over
60 days can tax the resources of our developer base. Most of these are
fairly trivial to fix (as is shown by how quick they are fixed. Usually
the developer has just forgotten to test the !CONFIG_SOMETHING case or
used some function without explicitly including the file that declares it.

As to my perceived pro-PowerPC and anti-x86 bias, you are the only one who
has even mentioned it to me.

Anyway, I sick of these discussions. If people see the way I do
linux-next as a problem, then they can find someone else. That is not
the impression I gained at the Kernel Summit and (apart from these
occasional "discussions") I am quite happy to continue.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: Regulators: lp3971 - fail if platform data was not supplied
http://groups.google.com/group/linux.kernel/t/9b85fe4e35c44d4b?hl=en
==============================================================================

== 1 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

There is no point in completing probe if platform data is missing so
let's abort loading early.

Also, use kcalloc when allocating several instances of the same data
structure and mark setup_regulators() as __devinit since it is only
called from lp3971_i2c_probe() which is __devinit.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/lp3971.c | 58 ++++++++++++++++++++++----------------------
1 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/regulator/lp3971.c b/drivers/regulator/lp3971.c
index 3ea639f..f5532ed 100644
--- a/drivers/regulator/lp3971.c
+++ b/drivers/regulator/lp3971.c
@@ -431,20 +431,20 @@ static int lp3971_set_bits(struct lp3971 *lp3971, u8 reg, u16 mask, u16 val)
return ret;
}

-static int setup_regulators(struct lp3971 *lp3971,
- struct lp3971_platform_data *pdata)
+static int __devinit setup_regulators(struct lp3971 *lp3971,
+ struct lp3971_platform_data *pdata)
{
int i, err;
- int num_regulators = pdata->num_regulators;
- lp3971->num_regulators = num_regulators;
- lp3971->rdev = kzalloc(sizeof(struct regulator_dev *) * num_regulators,
- GFP_KERNEL);
+
+ lp3971->num_regulators = pdata->num_regulators;
+ lp3971->rdev = kcalloc(pdata->num_regulators,
+ sizeof(struct regulator_dev *), GFP_KERNEL);

/* Instantiate the regulators */
- for (i = 0; i < num_regulators; i++) {
- int id = pdata->regulators[i].id;
- lp3971->rdev[i] = regulator_register(&regulators[id],
- lp3971->dev, pdata->regulators[i].initdata, lp3971);
+ for (i = 0; i < pdata->num_regulators; i++) {
+ struct lp3971_regulator_subdev *reg = &pdata->regulators[i];
+ lp3971->rdev[i] = regulator_register(&regulators[reg->id],
+ lp3971->dev, reg->initdata, lp3971);

if (IS_ERR(lp3971->rdev[i])) {
err = PTR_ERR(lp3971->rdev[i]);
@@ -455,10 +455,10 @@ static int setup_regulators(struct lp3971 *lp3971,
}

return 0;
+
error:
- for (i = 0; i < num_regulators; i++)
- if (lp3971->rdev[i])
- regulator_unregister(lp3971->rdev[i]);
+ while (--i >= 0)
+ regulator_unregister(lp3971->rdev[i]);
kfree(lp3971->rdev);
lp3971->rdev = NULL;
return err;
@@ -472,15 +472,17 @@ static int __devinit lp3971_i2c_probe(struct i2c_client *i2c,
int ret;
u16 val;

- lp3971 = kzalloc(sizeof(struct lp3971), GFP_KERNEL);
- if (lp3971 == NULL) {
- ret = -ENOMEM;
- goto err;
+ if (!pdata) {
+ dev_dbg(&i2c->dev, "No platform init data supplied\n");
+ return -ENODEV;
}

+ lp3971 = kzalloc(sizeof(struct lp3971), GFP_KERNEL);
+ if (lp3971 == NULL)
+ return -ENOMEM;
+
lp3971->i2c = i2c;
lp3971->dev = &i2c->dev;
- i2c_set_clientdata(i2c, lp3971);

mutex_init(&lp3971->io_lock);

@@ -493,19 +495,15 @@ static int __devinit lp3971_i2c_probe(struct i2c_client *i2c,
goto err_detect;
}

- if (pdata) {
- ret = setup_regulators(lp3971, pdata);
- if (ret < 0)
- goto err_detect;
- } else
- dev_warn(lp3971->dev, "No platform init data supplied\n");
+ ret = setup_regulators(lp3971, pdata);
+ if (ret < 0)
+ goto err_detect;

+ i2c_set_clientdata(i2c, lp3971);
return 0;

err_detect:
- i2c_set_clientdata(i2c, NULL);
kfree(lp3971);
-err:
return ret;
}

@@ -513,11 +511,13 @@ static int __devexit lp3971_i2c_remove(struct i2c_client *i2c)
{
struct lp3971 *lp3971 = i2c_get_clientdata(i2c);
int i;
+
+ i2c_set_clientdata(i2c, NULL);
+
for (i = 0; i < lp3971->num_regulators; i++)
- if (lp3971->rdev[i])
- regulator_unregister(lp3971->rdev[i]);
+ regulator_unregister(lp3971->rdev[i]);
+
kfree(lp3971->rdev);
- i2c_set_clientdata(i2c, NULL);
kfree(lp3971);

return 0;

== 2 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

It is a good tone to reset driver data after unbinding the device.
Also set up drivers owner.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/wm831x-dcdc.c | 12 ++++++++++++
drivers/regulator/wm831x-isink.c | 3 +++
drivers/regulator/wm831x-ldo.c | 5 +++++
3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index 0a65775..6e18e56 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -600,6 +600,8 @@ static __devexit int wm831x_buckv_remove(struct platform_device *pdev)
struct wm831x_dcdc *dcdc = platform_get_drvdata(pdev);
struct wm831x *wm831x = dcdc->wm831x;

+ platform_set_drvdata(pdev, NULL);
+
wm831x_free_irq(wm831x, platform_get_irq_byname(pdev, "HC"), dcdc);
wm831x_free_irq(wm831x, platform_get_irq_byname(pdev, "UV"), dcdc);
regulator_unregister(dcdc->regulator);
@@ -615,6 +617,7 @@ static struct platform_driver wm831x_buckv_driver = {
.remove = __devexit_p(wm831x_buckv_remove),
.driver = {
.name = "wm831x-buckv",
+ .owner = THIS_MODULE,
},
};

@@ -769,6 +772,8 @@ static __devexit int wm831x_buckp_remove(struct platform_device *pdev)
struct wm831x_dcdc *dcdc = platform_get_drvdata(pdev);
struct wm831x *wm831x = dcdc->wm831x;

+ platform_set_drvdata(pdev, NULL);
+
wm831x_free_irq(wm831x, platform_get_irq_byname(pdev, "UV"), dcdc);
regulator_unregister(dcdc->regulator);
kfree(dcdc);
@@ -781,6 +786,7 @@ static struct platform_driver wm831x_buckp_driver = {
.remove = __devexit_p(wm831x_buckp_remove),
.driver = {
.name = "wm831x-buckp",
+ .owner = THIS_MODULE,
},
};

@@ -895,6 +901,8 @@ static __devexit int wm831x_boostp_remove(struct platform_device *pdev)
struct wm831x_dcdc *dcdc = platform_get_drvdata(pdev);
struct wm831x *wm831x = dcdc->wm831x;

+ platform_set_drvdata(pdev, NULL);
+
wm831x_free_irq(wm831x, platform_get_irq_byname(pdev, "UV"), dcdc);
regulator_unregister(dcdc->regulator);
kfree(dcdc);
@@ -907,6 +915,7 @@ static struct platform_driver wm831x_boostp_driver = {
.remove = __devexit_p(wm831x_boostp_remove),
.driver = {
.name = "wm831x-boostp",
+ .owner = THIS_MODULE,
},
};

@@ -979,6 +988,8 @@ static __devexit int wm831x_epe_remove(struct platform_device *pdev)
{
struct wm831x_dcdc *dcdc = platform_get_drvdata(pdev);

+ platform_set_drvdata(pdev, NULL);
+
regulator_unregister(dcdc->regulator);
kfree(dcdc);

@@ -990,6 +1001,7 @@ static struct platform_driver wm831x_epe_driver = {
.remove = __devexit_p(wm831x_epe_remove),
.driver = {
.name = "wm831x-epe",
+ .owner = THIS_MODULE,
},
};

diff --git a/drivers/regulator/wm831x-isink.c b/drivers/regulator/wm831x-isink.c
index 4885700..ca0f6b6 100644
--- a/drivers/regulator/wm831x-isink.c
+++ b/drivers/regulator/wm831x-isink.c
@@ -222,6 +222,8 @@ static __devexit int wm831x_isink_remove(struct platform_device *pdev)
struct wm831x_isink *isink = platform_get_drvdata(pdev);
struct wm831x *wm831x = isink->wm831x;

+ platform_set_drvdata(pdev, NULL);
+
wm831x_free_irq(wm831x, platform_get_irq(pdev, 0), isink);

regulator_unregister(isink->regulator);
@@ -235,6 +237,7 @@ static struct platform_driver wm831x_isink_driver = {
.remove = __devexit_p(wm831x_isink_remove),
.driver = {
.name = "wm831x-isink",
+ .owner = THIS_MODULE,
},
};

diff --git a/drivers/regulator/wm831x-ldo.c b/drivers/regulator/wm831x-ldo.c
index 61e02ac..d2406c1 100644
--- a/drivers/regulator/wm831x-ldo.c
+++ b/drivers/regulator/wm831x-ldo.c
@@ -371,6 +371,8 @@ static __devexit int wm831x_gp_ldo_remove(struct platform_device *pdev)
struct wm831x_ldo *ldo = platform_get_drvdata(pdev);
struct wm831x *wm831x = ldo->wm831x;

+ platform_set_drvdata(pdev, NULL);
+
wm831x_free_irq(wm831x, platform_get_irq_byname(pdev, "UV"), ldo);
regulator_unregister(ldo->regulator);
kfree(ldo);
@@ -383,6 +385,7 @@ static struct platform_driver wm831x_gp_ldo_driver = {
.remove = __devexit_p(wm831x_gp_ldo_remove),
.driver = {
.name = "wm831x-ldo",
+ .owner = THIS_MODULE,
},
};

@@ -640,6 +643,7 @@ static struct platform_driver wm831x_aldo_driver = {
.remove = __devexit_p(wm831x_aldo_remove),
.driver = {
.name = "wm831x-aldo",
+ .owner = THIS_MODULE,
},
};

@@ -811,6 +815,7 @@ static struct platform_driver wm831x_alive_ldo_driver = {
.remove = __devexit_p(wm831x_alive_ldo_remove),
.driver = {
.name = "wm831x-alive-ldo",
+ .owner = THIS_MODULE,
},
};

== 3 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/max8660.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index acc2fb7..f12f1bb 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -345,8 +345,8 @@ static struct regulator_desc max8660_reg[] = {
},
};

-static int max8660_probe(struct i2c_client *client,
- const struct i2c_device_id *i2c_id)
+static int __devinit max8660_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
{
struct regulator_dev **rdev;
struct max8660_platform_data *pdata = client->dev.platform_data;
@@ -354,7 +354,7 @@ static int max8660_probe(struct i2c_client *client,
int boot_on, i, id, ret = -EINVAL;

if (pdata->num_subdevs > MAX8660_V_END) {
- dev_err(&client->dev, "Too much regulators found!\n");
+ dev_err(&client->dev, "Too many regulators found!\n");
goto out;
}

@@ -462,7 +462,7 @@ out:
return ret;
}

-static int max8660_remove(struct i2c_client *client)
+static int __devexit max8660_remove(struct i2c_client *client)
{
struct regulator_dev **rdev = i2c_get_clientdata(client);
int i;
@@ -485,9 +485,10 @@ MODULE_DEVICE_TABLE(i2c, max8660_id);

static struct i2c_driver max8660_driver = {
.probe = max8660_probe,
- .remove = max8660_remove,
+ .remove = __devexit_p(max8660_remove),
.driver = {
.name = "max8660",
+ .owner = THIS_MODULE,
},
.id_table = max8660_id,
};

== 4 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/max1586.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 2c082d3..a49fc95 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -179,8 +179,8 @@ static struct regulator_desc max1586_reg[] = {
},
};

-static int max1586_pmic_probe(struct i2c_client *client,
- const struct i2c_device_id *i2c_id)
+static int __devinit max1586_pmic_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
{
struct regulator_dev **rdev;
struct max1586_platform_data *pdata = client->dev.platform_data;
@@ -235,7 +235,7 @@ out:
return ret;
}

-static int max1586_pmic_remove(struct i2c_client *client)
+static int __devexit max1586_pmic_remove(struct i2c_client *client)
{
struct regulator_dev **rdev = i2c_get_clientdata(client);
int i;
@@ -257,9 +257,10 @@ MODULE_DEVICE_TABLE(i2c, max1586_id);

static struct i2c_driver max1586_pmic_driver = {
.probe = max1586_pmic_probe,
- .remove = max1586_pmic_remove,
+ .remove = __devexit_p(max1586_pmic_remove),
.driver = {
.name = "max1586",
+ .owner = THIS_MODULE,
},
.id_table = max1586_id,
};

== 5 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

It is a good tone to reset driver data after unbinding the device.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/pcap-regulator.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/pcap-regulator.c b/drivers/regulator/pcap-regulator.c
index 33d7d89..29d0566 100644
--- a/drivers/regulator/pcap-regulator.c
+++ b/drivers/regulator/pcap-regulator.c
@@ -288,16 +288,18 @@ static int __devexit pcap_regulator_remove(struct platform_device *pdev)
struct regulator_dev *rdev = platform_get_drvdata(pdev);

regulator_unregister(rdev);
+ platform_set_drvdata(pdev, NULL);

return 0;
}

static struct platform_driver pcap_regulator_driver = {
.driver = {
- .name = "pcap-regulator",
+ .name = "pcap-regulator",
+ .owner = THIS_MODULE,
},
- .probe = pcap_regulator_probe,
- .remove = __devexit_p(pcap_regulator_remove),
+ .probe = pcap_regulator_probe,
+ .remove = __devexit_p(pcap_regulator_remove),
};

static int __init pcap_regulator_init(void)

== 6 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

It is a good tone to reset driver data after unbinding the device.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/wm8994-regulator.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/wm8994-regulator.c b/drivers/regulator/wm8994-regulator.c
index d09e018..95454a4 100644
--- a/drivers/regulator/wm8994-regulator.c
+++ b/drivers/regulator/wm8994-regulator.c
@@ -26,7 +26,7 @@

struct wm8994_ldo {
int enable;
- int is_enabled;
+ bool is_enabled;
struct regulator_dev *regulator;
struct wm8994 *wm8994;
};
@@ -43,7 +43,7 @@ static int wm8994_ldo_enable(struct regulator_dev *rdev)
return 0;

gpio_set_value(ldo->enable, 1);
- ldo->is_enabled = 1;
+ ldo->is_enabled = true;

return 0;
}
@@ -57,7 +57,7 @@ static int wm8994_ldo_disable(struct regulator_dev *rdev)
return -EINVAL;

gpio_set_value(ldo->enable, 0);
- ldo->is_enabled = 0;
+ ldo->is_enabled = false;

return 0;
}
@@ -218,7 +218,7 @@ static __devinit int wm8994_ldo_probe(struct platform_device *pdev)

ldo->wm8994 = wm8994;

- ldo->is_enabled = 1;
+ ldo->is_enabled = true;

if (pdata->ldo[id].enable && gpio_is_valid(pdata->ldo[id].enable)) {
ldo->enable = pdata->ldo[id].enable;
@@ -263,6 +263,8 @@ static __devexit int wm8994_ldo_remove(struct platform_device *pdev)
{
struct wm8994_ldo *ldo = platform_get_drvdata(pdev);

+ platform_set_drvdata(pdev, NULL);
+
regulator_unregister(ldo->regulator);
if (gpio_is_valid(ldo->enable))
gpio_free(ldo->enable);
@@ -276,6 +278,7 @@ static struct platform_driver wm8994_ldo_driver = {
.remove = __devexit_p(wm8994_ldo_remove),
.driver = {
.name = "wm8994-ldo",
+ .owner = THIS_MODULE,
},
};

== 7 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

Also move error handling in probe() out of line and do not bother
to reset fields in structures that are about to be freed.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/tps65023-regulator.c | 35 +++++++++++++++-----------------
1 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/regulator/tps65023-regulator.c b/drivers/regulator/tps65023-regulator.c
index 07fda0a..1f18354 100644
--- a/drivers/regulator/tps65023-regulator.c
+++ b/drivers/regulator/tps65023-regulator.c
@@ -457,8 +457,8 @@ static struct regulator_ops tps65023_ldo_ops = {
.list_voltage = tps65023_ldo_list_voltage,
};

-static
-int tps_65023_probe(struct i2c_client *client, const struct i2c_device_id *id)
+static int __devinit tps_65023_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
static int desc_id;
const struct tps_info *info = (void *)id->driver_data;
@@ -466,6 +466,7 @@ int tps_65023_probe(struct i2c_client *client, const struct i2c_device_id *id)
struct regulator_dev *rdev;
struct tps_pmic *tps;
int i;
+ int error;

if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
@@ -475,7 +476,6 @@ int tps_65023_probe(struct i2c_client *client, const struct i2c_device_id *id)
* coming from the board-evm file.
*/
init_data = client->dev.platform_data;
-
if (!init_data)
return -EIO;

@@ -502,21 +502,12 @@ int tps_65023_probe(struct i2c_client *client, const struct i2c_device_id *id)

/* Register the regulators */
rdev = regulator_register(&tps->desc[i], &client->dev,
- init_data, tps);
+ init_data, tps);
if (IS_ERR(rdev)) {
dev_err(&client->dev, "failed to register %s\n",
id->name);
-
- /* Unregister */
- while (i)
- regulator_unregister(tps->rdev[--i]);
-
- tps->client = NULL;
-
- /* clear the client data in i2c */
- i2c_set_clientdata(client, NULL);
- kfree(tps);
- return PTR_ERR(rdev);
+ error = PTR_ERR(rdev);
+ goto fail;
}

/* Save regulator for cleanup */
@@ -526,6 +517,13 @@ int tps_65023_probe(struct i2c_client *client, const struct i2c_device_id *id)
i2c_set_clientdata(client, tps);

return 0;
+
+ fail:
+ while (--i >= 0)
+ regulator_unregister(tps->rdev[i]);
+
+ kfree(tps);
+ return error;
}

/**
@@ -539,13 +537,12 @@ static int __devexit tps_65023_remove(struct i2c_client *client)
struct tps_pmic *tps = i2c_get_clientdata(client);
int i;

+ /* clear the client data in i2c */
+ i2c_set_clientdata(client, NULL);
+
for (i = 0; i < TPS65023_NUM_REGULATOR; i++)
regulator_unregister(tps->rdev[i]);

- tps->client = NULL;
-
- /* clear the client data in i2c */
- i2c_set_clientdata(client, NULL);
kfree(tps);

return 0;

== 8 of 8 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

Instead of open-coding sysfs attribute group use canned solution.
Also add __devinit/__devexit markups for probe and remove methods
and use 'bool' where it makes sense.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/virtual.c | 64 ++++++++++++++++++++++---------------------
1 files changed, 33 insertions(+), 31 deletions(-)

diff --git a/drivers/regulator/virtual.c b/drivers/regulator/virtual.c
index addc032..d96ceca 100644
--- a/drivers/regulator/virtual.c
+++ b/drivers/regulator/virtual.c
@@ -19,7 +19,7 @@
struct virtual_consumer_data {
struct mutex lock;
struct regulator *regulator;
- int enabled;
+ bool enabled;
int min_uV;
int max_uV;
int min_uA;
@@ -49,7 +49,7 @@ static void update_voltage_constraints(struct device *dev,
dev_dbg(dev, "Enabling regulator\n");
ret = regulator_enable(data->regulator);
if (ret == 0)
- data->enabled = 1;
+ data->enabled = true;
else
dev_err(dev, "regulator_enable() failed: %d\n",
ret);
@@ -59,7 +59,7 @@ static void update_voltage_constraints(struct device *dev,
dev_dbg(dev, "Disabling regulator\n");
ret = regulator_disable(data->regulator);
if (ret == 0)
- data->enabled = 0;
+ data->enabled = false;
else
dev_err(dev, "regulator_disable() failed: %d\n",
ret);
@@ -89,7 +89,7 @@ static void update_current_limit_constraints(struct device *dev,
dev_dbg(dev, "Enabling regulator\n");
ret = regulator_enable(data->regulator);
if (ret == 0)
- data->enabled = 1;
+ data->enabled = true;
else
dev_err(dev, "regulator_enable() failed: %d\n",
ret);
@@ -99,7 +99,7 @@ static void update_current_limit_constraints(struct device *dev,
dev_dbg(dev, "Disabling regulator\n");
ret = regulator_disable(data->regulator);
if (ret == 0)
- data->enabled = 0;
+ data->enabled = false;
else
dev_err(dev, "regulator_disable() failed: %d\n",
ret);
@@ -270,24 +270,28 @@ static DEVICE_ATTR(min_microamps, 0666, show_min_uA, set_min_uA);
static DEVICE_ATTR(max_microamps, 0666, show_max_uA, set_max_uA);
static DEVICE_ATTR(mode, 0666, show_mode, set_mode);

-static struct device_attribute *attributes[] = {
- &dev_attr_min_microvolts,
- &dev_attr_max_microvolts,
- &dev_attr_min_microamps,
- &dev_attr_max_microamps,
- &dev_attr_mode,
+static struct attribute *regulator_virtual_attributes[] = {
+ &dev_attr_min_microvolts.attr,
+ &dev_attr_max_microvolts.attr,
+ &dev_attr_min_microamps.attr,
+ &dev_attr_max_microamps.attr,
+ &dev_attr_mode.attr,
+ NULL
};

-static int regulator_virtual_consumer_probe(struct platform_device *pdev)
+static const struct attribute_group regulator_virtual_attr_group = {
+ .attrs = regulator_virtual_attributes,
+};
+
+static int __devinit regulator_virtual_probe(struct platform_device *pdev)
{
char *reg_id = pdev->dev.platform_data;
struct virtual_consumer_data *drvdata;
- int ret, i;
+ int ret;

drvdata = kzalloc(sizeof(struct virtual_consumer_data), GFP_KERNEL);
- if (drvdata == NULL) {
+ if (drvdata == NULL)
return -ENOMEM;
- }

mutex_init(&drvdata->lock);

@@ -299,13 +303,12 @@ static int regulator_virtual_consumer_probe(struct platform_device *pdev)
goto err;
}

- for (i = 0; i < ARRAY_SIZE(attributes); i++) {
- ret = device_create_file(&pdev->dev, attributes[i]);
- if (ret != 0) {
- dev_err(&pdev->dev, "Failed to create attr %d: %d\n",
- i, ret);
- goto err_regulator;
- }
+ ret = sysfs_create_group(&pdev->dev.kobj,
+ &regulator_virtual_attr_group);
+ if (ret != 0) {
+ dev_err(&pdev->dev,
+ "Failed to create attribute group: %d\n", ret);
+ goto err_regulator;
}

drvdata->mode = regulator_get_mode(drvdata->regulator);
@@ -317,37 +320,36 @@ static int regulator_virtual_consumer_probe(struct platform_device *pdev)
err_regulator:
regulator_put(drvdata->regulator);
err:
- for (i = 0; i < ARRAY_SIZE(attributes); i++)
- device_remove_file(&pdev->dev, attributes[i]);
kfree(drvdata);
return ret;
}

-static int regulator_virtual_consumer_remove(struct platform_device *pdev)
+static int __devexit regulator_virtual_remove(struct platform_device *pdev)
{
struct virtual_consumer_data *drvdata = platform_get_drvdata(pdev);
- int i;

- for (i = 0; i < ARRAY_SIZE(attributes); i++)
- device_remove_file(&pdev->dev, attributes[i]);
+ sysfs_remove_group(&pdev->dev.kobj, &regulator_virtual_attr_group);
+
if (drvdata->enabled)
regulator_disable(drvdata->regulator);
regulator_put(drvdata->regulator);

kfree(drvdata);

+ platform_set_drvdata(pdev, NULL);
+
return 0;
}

static struct platform_driver regulator_virtual_consumer_driver = {
- .probe = regulator_virtual_consumer_probe,
- .remove = regulator_virtual_consumer_remove,
+ .probe = regulator_virtual_probe,
+ .remove = __devexit_p(regulator_virtual_remove),
.driver = {
.name = "reg-virt-consumer",
+ .owner = THIS_MODULE,
},
};

-
static int __init regulator_virtual_consumer_init(void)
{
return platform_driver_register(&regulator_virtual_consumer_driver);

==============================================================================
TOPIC: windfarm: init sysfs attributes
http://groups.google.com/group/linux.kernel/t/8667019ee9a5d536?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Américo Wang

On Wed, Feb 24, 2010 at 3:32 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2010-02-24 at 13:49 +1100, Benjamin Herrenschmidt wrote:
>> On Sat, 2010-02-20 at 16:43 +0100, Johannes Berg wrote:
>> > This is required for lockdep.
>>
>> Please CC linuxppc-dev@ozlabs.org or it doesn't get caught by
>> patchwork.
>
> Eh, sure, but I think it needs to be part of Eric's series?
>

Yeah, that's why we are Cc'ing Greg, since he took Eric's patches already.

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

== 2 of 2 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Johannes Berg

On Wed, 2010-02-24 at 13:49 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2010-02-20 at 16:43 +0100, Johannes Berg wrote:
> > This is required for lockdep.
>
> Please CC linuxppc-dev@ozlabs.org or it doesn't get caught by
> patchwork.

Eh, sure, but I think it needs to be part of Eric's series?

> I'll fwd that one myself.

Thanks.

johannes

==============================================================================
TOPIC: Assorted small patches for regulators
http://groups.google.com/group/linux.kernel/t/8f3f33cbcc66f2b6?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

Hi Liam,

I happend to peek into drivers/regulator and saw a bunch of small issues, so
here goes. The patches are against linux-next, compile-tested only since I
don't have the hardware,

Please consider applying.

Thanks,

Dmitry

---

Dmitry Torokhov (14):
Regulators: max8925-regulator - clean up driver data after removal
Regulators: wm8400 - cleanup platform driver data handling
Regulators: wm8994 - clean up driver data after removal
Regulators: wm831x-xxx - clean up driver data after removal
Regulators: pcap-regulator - clean up driver data after removal
Regulators: max8660 - annotate probe and remove methods
Regulators: max1586 - annotate probe and remove methods
Regulators: lp3971 - fail if platform data was not supplied
Regulators: tps6507x-regulator - mark probe method as __devinit
Regulators: tps65023-regulator - mark probe method as __devinit
Regulators: twl-regulator - mark probe function as __devinit
Regulators: fixed - annotate probe and remove methods
Regulators: ab3100 - fix probe and remove annotations
Regulators: virtual - use sysfs attribute groups

drivers/regulator/ab3100.c | 6 ++-
drivers/regulator/fixed.c | 19 +++++-----
drivers/regulator/lp3971.c | 58 +++++++++++++++--------------
drivers/regulator/max1586.c | 9 +++--
drivers/regulator/max8660.c | 11 +++---
drivers/regulator/max8925-regulator.c | 6 ++-
drivers/regulator/pcap-regulator.c | 8 +++-
drivers/regulator/tps65023-regulator.c | 35 ++++++++----------
drivers/regulator/tps6507x-regulator.c | 34 ++++++++---------
drivers/regulator/twl-regulator.c | 2 +
drivers/regulator/virtual.c | 64 +++++++++++++++++---------------
drivers/regulator/wm831x-dcdc.c | 12 ++++++
drivers/regulator/wm831x-isink.c | 3 ++
drivers/regulator/wm831x-ldo.c | 5 +++
drivers/regulator/wm8400-regulator.c | 13 ++++---
drivers/regulator/wm8994-regulator.c | 11 ++++--
include/linux/mfd/wm8400.h | 4 ++
17 files changed, 164 insertions(+), 136 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

Also move error handling in probe() out of line and do not bother
to reset fields in structures that are about to be freed.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/tps6507x-regulator.c | 34 ++++++++++++++------------------
1 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index f8a6dfb..c2a9539 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -538,8 +538,8 @@ static struct regulator_ops tps6507x_ldo_ops = {
.list_voltage = tps6507x_ldo_list_voltage,
};

-static
-int tps_6507x_probe(struct i2c_client *client, const struct i2c_device_id *id)
+static int __devinit tps_6507x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
static int desc_id;
const struct tps_info *info = (void *)id->driver_data;
@@ -547,6 +547,7 @@ int tps_6507x_probe(struct i2c_client *client, const struct i2c_device_id *id)
struct regulator_dev *rdev;
struct tps_pmic *tps;
int i;
+ int error;

if (!i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_BYTE_DATA))
@@ -557,7 +558,6 @@ int tps_6507x_probe(struct i2c_client *client, const struct i2c_device_id *id)
* coming from the board-evm file.
*/
init_data = client->dev.platform_data;
-
if (!init_data)
return -EIO;

@@ -586,18 +586,8 @@ int tps_6507x_probe(struct i2c_client *client, const struct i2c_device_id *id)
if (IS_ERR(rdev)) {
dev_err(&client->dev, "failed to register %s\n",
id->name);
-
- /* Unregister */
- while (i)
- regulator_unregister(tps->rdev[--i]);
-
- tps->client = NULL;
-
- /* clear the client data in i2c */
- i2c_set_clientdata(client, NULL);
-
- kfree(tps);
- return PTR_ERR(rdev);
+ error = PTR_ERR(rdev);
+ goto fail;
}

/* Save regulator for cleanup */
@@ -607,6 +597,13 @@ int tps_6507x_probe(struct i2c_client *client, const struct i2c_device_id *id)
i2c_set_clientdata(client, tps);

return 0;
+
+fail:
+ while (--i >= 0)
+ regulator_unregister(tps->rdev[i]);
+
+ kfree(tps);
+ return error;
}

/**
@@ -620,13 +617,12 @@ static int __devexit tps_6507x_remove(struct i2c_client *client)
struct tps_pmic *tps = i2c_get_clientdata(client);
int i;

+ /* clear the client data in i2c */
+ i2c_set_clientdata(client, NULL);
+
for (i = 0; i < TPS6507X_NUM_REGULATOR; i++)
regulator_unregister(tps->rdev[i]);

- tps->client = NULL;
-
- /* clear the client data in i2c */
- i2c_set_clientdata(client, NULL);
kfree(tps);

return 0;

== 3 of 3 ==
Date: Tues, Feb 23 2010 11:40 pm
From: Dmitry Torokhov

It is a good tone to reset driver data after unbinding the device.
Also change find_regulator_info() fro inline to __devinit - let compiler
figure out if it wants it to be inlined or not.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

drivers/regulator/max8925-regulator.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/max8925-regulator.c b/drivers/regulator/max8925-regulator.c
index 67873f0..b6218f1 100644
--- a/drivers/regulator/max8925-regulator.c
+++ b/drivers/regulator/max8925-regulator.c
@@ -230,7 +230,7 @@ static struct max8925_regulator_info max8925_regulator_info[] = {
MAX8925_LDO(20, 750, 3900, 50),
};

-static inline struct max8925_regulator_info *find_regulator_info(int id)
+static struct max8925_regulator_info * __devinit find_regulator_info(int id)
{
struct max8925_regulator_info *ri;
int i;
@@ -247,7 +247,7 @@ static int __devinit max8925_regulator_probe(struct platform_device *pdev)
{
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
struct max8925_platform_data *pdata = chip->dev->platform_data;
- struct max8925_regulator_info *ri = NULL;
+ struct max8925_regulator_info *ri;
struct regulator_dev *rdev;

ri = find_regulator_info(pdev->id);
@@ -274,7 +274,9 @@ static int __devexit max8925_regulator_remove(struct platform_device *pdev)
{
struct regulator_dev *rdev = platform_get_drvdata(pdev);

+ platform_set_drvdata(pdev, NULL);
regulator_unregister(rdev);
+
return 0;
}

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, February 23, 2010

linux.kernel - 25 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts