From: Greg KH on
On Tue, Mar 09, 2010 at 10:28:28AM +1100, Stephen Rothwell wrote:
> I have been carrying this patch in linux-next for some time and now
> mainline needs it.

Well, it's not required, but it is nice to have. I didn't merge the
"convert the driver core semaphore to a mutex" patch as it was causing
too many false-positive lockdep warnings.

Hopefully the lockdep core will be tweaked to handle the locking tree
that the device core requires and then when that happens, I will merge
the patch that will require this fix in order to keep the build from
breaking.

But for now, it's not a requirement, although, it does make my life
easier.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Rothwell on
Hi Greg,

On Mon, 8 Mar 2010 15:59:53 -0800 Greg KH <greg(a)kroah.com> wrote:
>
> On Tue, Mar 09, 2010 at 10:28:28AM +1100, Stephen Rothwell wrote:
> > I have been carrying this patch in linux-next for some time and now
> > mainline needs it.
>
> Well, it's not required, but it is nice to have. I didn't merge the
> "convert the driver core semaphore to a mutex" patch as it was causing
> too many false-positive lockdep warnings.

Ah, I missed that, sorry.

Strangely, I was assuming that what was in linux-next would get merged :-)
--
Cheers,
Stephen Rothwell sfr(a)canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Greg KH on
On Tue, Mar 09, 2010 at 12:50:37PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 8 Mar 2010 15:59:53 -0800 Greg KH <greg(a)kroah.com> wrote:
> >
> > On Tue, Mar 09, 2010 at 10:28:28AM +1100, Stephen Rothwell wrote:
> > > I have been carrying this patch in linux-next for some time and now
> > > mainline needs it.
> >
> > Well, it's not required, but it is nice to have. I didn't merge the
> > "convert the driver core semaphore to a mutex" patch as it was causing
> > too many false-positive lockdep warnings.
>
> Ah, I missed that, sorry.
>
> Strangely, I was assuming that what was in linux-next would get merged :-)

That is normally the case, but when patches are found to have problems,
due to the testing that happens with linux-next, they can then be not
sent to Linus, right?

That's what happened here, we need more infrastructure to be able to
accept them. I see it as a validation that our development model is
working properly that this happened :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jean Delvare on
On Tue, 9 Mar 2010 10:28:28 +1100, Stephen Rothwell wrote:
> I have been carrying this patch in linux-next for some time and now
> mainline needs it.
>
> Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
> ---
> drivers/i2c/i2c-smbus.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
> index 333527c..52aa775 100644
> --- a/drivers/i2c/i2c-smbus.c
> +++ b/drivers/i2c/i2c-smbus.c
> @@ -27,6 +27,7 @@
> #include <linux/workqueue.h>
> #include <linux/i2c.h>
> #include <linux/i2c-smbus.h>
> +#include <linux/mutex.h>
>
> struct i2c_smbus_alert {
> unsigned int alert_edge_triggered:1;
> @@ -55,7 +56,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
> * Drivers should either disable alerts, or provide at least
> * a minimal handler. Lock so client->driver won't change.
> */
> - down(&dev->sem);
> + device_lock(dev);
> if (client->driver) {
> if (client->driver->alert)
> client->driver->alert(client, data->flag);
> @@ -63,7 +64,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
> dev_warn(&client->dev, "no driver alert()!\n");
> } else
> dev_dbg(&client->dev, "alert with no driver\n");
> - up(&dev->sem);
> + device_unlock(dev);
>
> /* Stop iterating after we find the device */
> return -EBUSY;

Thanks for the reminder Stephen. I was only waiting for device_lock()
to become usable in mainline. Now that it happened, I will take the
patch above in my i2c tree, and send it to Linus in my next batch.

--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Rothwell on
Hi Jean,

On Tue, 9 Mar 2010 09:25:08 +0100 Jean Delvare <khali(a)linux-fr.org> wrote:
>
> Thanks for the reminder Stephen. I was only waiting for device_lock()
> to become usable in mainline. Now that it happened, I will take the
> patch above in my i2c tree, and send it to Linus in my next batch.

Thanks. The include of mutex.h is not actually needed yet as Greg didn't
send the semaphore to mutex change to Linus due to other issues. The
device_lock/unlock part would be useful, though for when the change does
happen.

--
Cheers,
Stephen Rothwell sfr(a)canb.auug.org.au
http://www.canb.auug.org.au/~sfr/