linux-kernel - Re: [RFC PATCH][DO NOT COMMIT] media: dvb_frontend: Support concurrent DVB-T/DVB-T2 scan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 14 Dec 2021 16:06:52 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Marc Gonzalez <marc.w.gonzalez@...e.fr>
Cc:     Sean Young <sean@...s.org>, Brad Love <brad@...tdimension.cc>,
        linux-media <linux-media@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Antti Palosaari <crope@....fi>,
        Jan Pieter van Woerkom <jp@...w.nl>
Subject: Re: [RFC PATCH][DO NOT COMMIT] media: dvb_frontend: Support
 concurrent DVB-T/DVB-T2 scan

Em Thu, 11 Jun 2020 13:57:13 +0200
Marc Gonzalez <marc.w.gonzalez@...e.fr> escreveu:

> Some demodulators (e.g. si2168) are able to scan for DVB-T and DVB-T2
> signals concurrently. Use SYS_DVBT_AUTO for this purpose.
> ---
> This is a Request For Comments from media maintainers and users :-)

Sorry for taking so long to answer... Somehow, this one got stuck in the
middle of the pile of patches.

I don't think this patch is needed. The same also happens with DVB-S/S2
cards: when some of those are set to the second gen, it may report both
1st and 2nd gen channels.

The main issue is actually how to report that a scanned channel is
DVB-T during a DVB-T2 scan: the driver should likely identify those
and set the properties accordingly.

> 
> One issue: suppose DVB Project publishes DVB-T3 in a few years.
> Today's demods might handle T/T2, but they won't handle T3, while users
> may expect SYS_DVBT_AUTO to mean "all DVB-T standards".
> 
> Therefore, perhaps the delsys name should be explicit,
> like SYS_DVBT_DVBT2 or SYS_DVBT_1_2.
> Then if/when DVB_T3 appears, we can add SYS_DVBT_1_2_3 ???
> 
> Or maybe use the FE_CAN_2G_MODULATION and hypothetical FE_CAN_3G_MODULATION
> 
> Or maybe, with several standards having a v2 and possibly v3 in the future,
> delivery system might move to a bitmask approach? (API issues though)
> 
> Reference to related implementation:
> https://patchwork.kernel.org/patch/10744999/
> ---
>  drivers/media/dvb-frontends/si2168.c | 2 +-
>  include/uapi/linux/dvb/frontend.h    | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c
> index 14b93a7d3358..8578b8917955 100644
> --- a/drivers/media/dvb-frontends/si2168.c
> +++ b/drivers/media/dvb-frontends/si2168.c
> @@ -624,7 +624,7 @@ static int si2168_deselect(struct i2c_mux_core *muxc, u32 chan)
>  }
>  
>  static const struct dvb_frontend_ops si2168_ops = {
> -	.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
> +	.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBT_AUTO, SYS_DVBC_ANNEX_A},
>  	.info = {
>  		.name = "Silicon Labs Si2168",
>  		.frequency_min_hz      =  48 * MHz,
> diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h
> index 4f9b4551c534..3a6348748041 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -600,6 +600,8 @@ enum fe_rolloff {
>   *	Terrestrial TV: DVB-T
>   * @SYS_DVBT2:
>   *	Terrestrial TV: DVB-T2
> + * @SYS_DVBT_AUTO:
> + *	Terrestrial TV: Autodetect DVB-T gen
>   * @SYS_ISDBT:
>   *	Terrestrial TV: ISDB-T
>   * @SYS_ATSC:
> @@ -645,6 +647,7 @@ enum fe_delivery_system {
>  	SYS_DVBT2,
>  	SYS_TURBO,
>  	SYS_DVBC_ANNEX_C,
> +	SYS_DVBT_AUTO,
>  };
>  
>  /* backward compatibility definitions for delivery systems */



Thanks,
Mauro