[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180425122315.GS4615@localhost>
Date: Wed, 25 Apr 2018 14:23:15 +0200
From: Johan Hovold <johan@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Johan Hovold <johan@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Andreas Kemnade <andreas@...nade.info>,
Arnd Bergmann <arnd@...db.de>,
"H . Nikolaus Schaller" <hns@...delico.com>,
Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 1/7] gnss: add GNSS receiver subsystem
On Wed, Apr 25, 2018 at 12:56:45PM +0200, Johan Hovold wrote:
> On Wed, Apr 25, 2018 at 10:56:49AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 24, 2018 at 06:34:52PM +0200, Johan Hovold wrote:
> > > +static int gnss_open(struct inode *inode, struct file *file)
> > > +{
> > > + struct gnss_device *gdev;
> > > + int ret = 0;
> > > +
> > > + gdev = container_of(inode->i_cdev, struct gnss_device, cdev);
> > > +
> > > + get_device(&gdev->dev);
> > > +
> > > + nonseekable_open(inode, file);
> > > + file->private_data = gdev;
> > > +
> > > + down_write(&gdev->rwsem);
> >
> > Just curious, why a rwsem? They can be slower than a normal semaphore,
> > is this really a contentious lock?
>
> I use the rwsem to deal with hotplugging; the underlying device can go
> away at any time and the core makes sure that no further calls into the
> corresponding driver is made once all currently executing callbacks
> return.
I just did find one access to the gnss ops which was unsafe however; the
existence check for a write_raw callback in write() needs to be replaced
by a device flag.
Thanks,
Johan
Powered by blists - more mailing lists