From 3626479e482aa3247aac03724094ba6c13ea1e46 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 17 Apr 2012 18:32:19 -0300 Subject: [media] dvb_frontend: Fix a regression when switching back to DVB-S There are some softwares (Kaffeine and likely xine) that uses a DVBv5 call to switch to DVB-S2, but expects that a DVBv3 call to switch back to DVB-S. Well, this is not right, as a DVBv3 call doesn't know anything about delivery systems. However, as, by accident, this used to work, we need to restore its behavior, in order to avoid regressions with those softwares. Reported on this Fedora 16 bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=812895 Reported-by: Dieter Roever Cc: stable@kernel.org # for version 3.3 Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb/dvb-core/dvb_frontend.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) (limited to 'drivers/media/dvb') diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index 39696c6a4ed7..0f64d7182657 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -1446,6 +1446,28 @@ static int set_delivery_system(struct dvb_frontend *fe, u32 desired_system) __func__); return -EINVAL; } + /* + * Get a delivery system that is compatible with DVBv3 + * NOTE: in order for this to work with softwares like Kaffeine that + * uses a DVBv5 call for DVB-S2 and a DVBv3 call to go back to + * DVB-S, drivers that support both should put the SYS_DVBS entry + * before the SYS_DVBS2, otherwise it won't switch back to DVB-S. + * The real fix is that userspace applications should not use DVBv3 + * and not trust on calling FE_SET_FRONTEND to switch the delivery + * system. + */ + ncaps = 0; + while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) { + if (fe->ops.delsys[ncaps] == desired_system) { + delsys = desired_system; + break; + } + ncaps++; + } + if (delsys == SYS_UNDEFINED) { + dprintk("%s() Couldn't find a delivery system that matches %d\n", + __func__, desired_system); + } } else { /* * This is a DVBv5 call. So, it likely knows the supported @@ -1494,9 +1516,10 @@ static int set_delivery_system(struct dvb_frontend *fe, u32 desired_system) __func__); return -EINVAL; } - c->delivery_system = delsys; } + c->delivery_system = delsys; + /* * The DVBv3 or DVBv5 call is requesting a different system. So, * emulation is needed. -- cgit v1.2.3 From e4459e1682c107d7ee1bf102c1ba534230e9b50b Mon Sep 17 00:00:00 2001 From: Alexey Khoroshilov Date: Thu, 5 Apr 2012 18:53:20 -0300 Subject: [media] drxk: Does not unlock mutex if sanity check failed in scu_command() If sanity check fails in scu_command(), goto error leads to unlock of an unheld mutex. The check should not fail in reality, but it nevertheless worth fixing. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb/frontends/drxk_hard.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'drivers/media/dvb') diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index 36d11756492f..a414b1f2b6a5 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -1520,8 +1520,10 @@ static int scu_command(struct drxk_state *state, dprintk(1, "\n"); if ((cmd == 0) || ((parameterLen > 0) && (parameter == NULL)) || - ((resultLen > 0) && (result == NULL))) - goto error; + ((resultLen > 0) && (result == NULL))) { + printk(KERN_ERR "drxk: Error %d on %s\n", status, __func__); + return status; + } mutex_lock(&state->mutex); -- cgit v1.2.3