lkml.org 
[lkml]   [2019]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Staging: greybus: Fix spinlock_t definition without comment
On Fri, Apr 05, 2019 at 11:53:04PM +0300, Dan Carpenter wrote:
> On Fri, Apr 05, 2019 at 03:00:46PM -0500, Madhumitha Prabakaran wrote:
> > Fix spinlock_t definition without comment.
> >
> > Signed-off-by: Madhumitha Prabakaran <madhumithabiw@gmail.com>
> > ---
> > drivers/staging/greybus/connection.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/greybus/connection.h b/drivers/staging/greybus/connection.h
> > index 5ca3befc0636..0aedd246e94a 100644
> > --- a/drivers/staging/greybus/connection.h
> > +++ b/drivers/staging/greybus/connection.h
> > @@ -47,7 +47,7 @@ struct gb_connection {
> > unsigned long flags;
> >
> > struct mutex mutex;
> > - spinlock_t lock;
> > + spinlock_t lock; /* Protect structure fields */
> > enum gb_connection_state state;
>
> What does the mutex do then? Why can't we just use the spinlock for
> everything?

Here, mutexes protect spinlock_t for gb_connection_state fields and
gb_connection_state fields itself in struct gb_connection.

However, I wasn't sure then and now exactly, how to find out which resources in the
structure, the spinlock or mutex is performing kernel synchronization.

>
> I did glance at the code and it wasn't immediately obvious to me.

Thanks for reviewing it.

>
> regards,
> dan carpenter
>

\
 
 \ /
  Last update: 2019-04-07 00:56    [W:0.064 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site