the kAPI for a frontend can use 3 different tuning methods:
1. The hardware tracks internally frequency shifts via its
own internal zigzag logic;
2. The hardware has a custom zigzag method, implemented via
fe search() ops;
3. The hardware doesn't have any internal zigzag logic. So,
the Kernel needs to implement it.
Drivers that use the in-kernel software zigzag are required to
provide some parameters for the zigzag code to work. Failing
to do that will just make the Kernel to tune several times
to the very same frequency, delaying the tuning time for
no good reason. This is actually a kAPI violation
(and an uAPI one, as the frequency shift is exported to the
uAPI).
Emit a warning on such case, as the driver needs to be fixed.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx>
---
drivers/media/dvb-core/dvb_frontend.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
index 6aaa4d5a504d..0c0af4bd2256 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -481,6 +481,11 @@ static void dvb_frontend_swzigzag(struct dvb_frontend *fe)
struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache, tmp;
+
+ if (fepriv->max_drift)
+ dev_warn_once(fe->dvb->device,
+ "Frontend requested software zigzag, but didn't set the frequency step size\n");
+
/* if we've got no parameters, just keep idling */
if (fepriv->state & FESTATE_IDLE) {
fepriv->delay = 3 * HZ;
--
2.30.2
