[linux-dvb] [PATCH] add device node locking possibility to dvbcore

Markus Rechberger mrechberger at gmail.com
Fri Aug 17 20:30:39 CEST 2007


On 8/17/07, Oliver Endriss <o.endriss at gmx.de> wrote:
> Markus Rechberger wrote:
> > On 8/17/07, Oliver Endriss <o.endriss at gmx.de> wrote:
> > > Steven Toth wrote:
> > > > The ts_bus_ctrl function pointer / callback is already in the
> mainline,
> > > > check dvb_frontend.c for more details. You shouldn't need a patch from
> me.
> > >
> > > ACK, should be enough to do this kind of locking.
> > >
> > > Furthermore, with this callback, the dvb_frontend_active() routine from
> > > '[linux-dvb] [PATCH] function for checking if the dvb framework is idle'
> > > is not required at all. The callback is aware whether the frontend is
> > > running or not...
> > >
> > As far as I've seen the callback will be called as soon as the device
> > gets closed, even though the thread might still be spinning in the
> > background and the subsystem might still access DVB components, this
> > is why dvb_frontend_active is  still needed.
> > Closing the devicenode and that callback doesn't mean that the device is
> idle.
>
> Ok, this should be fixed. What about this patch:
>
> diff -r dd58780b6fb4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c	Thu Aug 09 16:30:39
> 2007 +0200
> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c	Fri Aug 17 20:07:28
> 2007 +0200
> @@ -596,6 +596,10 @@ restart:
>  	mb();
>
>  	dvb_frontend_wakeup(fe);
> +
> +	if (fe->ops.ts_bus_ctrl)
> +		fe->ops.ts_bus_ctrl (fe, 0);
> +
>  	return 0;
>  }

as I wrote earlier the thread can be idle/closed even before the node
gets closed (you can test that with kaffeine, and you can test the
other case with the scan utility)

>
> @@ -1101,9 +1105,10 @@ static int dvb_frontend_release(struct i
>
>  	if ((file->f_flags & O_ACCMODE) != O_RDONLY)
>  		fepriv->release_jiffies = jiffies;
> -
> -	if (fe->ops.ts_bus_ctrl)
> -		fe->ops.ts_bus_ctrl (fe, 0);
> +	else {
> +		if (fe->ops.ts_bus_ctrl)
> +			fe->ops.ts_bus_ctrl (fe, 0);
> +	}
>

can you explain this? to me it doesn't look right. Before it always
called ts_bus_ctrl and afterwards it has a dependency to the access
mode bits?

Markus



More information about the linux-dvb mailing list