summaryrefslogtreecommitdiffstats
path: root/crypto/rmd128.c
diff options
context:
space:
mode:
authorMauro Carvalho Chehab <mchehab@redhat.com>2011-12-22 08:56:48 -0300
committerMauro Carvalho Chehab <mchehab@redhat.com>2011-12-31 09:08:14 -0200
commiteeacf1477b4460e2dbc37c9164bb46a65ab8f084 (patch)
treeb130913f6fc7a55619f2b14dd387be83aa32f16d /crypto/rmd128.c
parent14d24d148c7521b2b88b396652e36f55d061e195 (diff)
[media] dvb-core: allow demods to specify the supported delsys
The dvb were originally written for DVB-T/C/S and ATSC. So, the original frontend struct has fields to describe only those three standards. While 2nd gen standards are similar to these, new standards like DSS, ISDB and CTTB don't fit on any of the above types. While there's a way for the drivers to explicitly change whatever default DELSYS were filled inside the core, still a fake value is needed there, and a "compat" code to allow DVBv3 applications to work with those delivery systems is needed. This is good for a short term solution, while applications aren't using DVBv5 directly. However, at long term, this is bad, as the compat code runs even if the application is using DVBv5. Also, the compat code is not perfect, and only works when the frontend is capable of auto-detecting the parameters that aren't visible by the faked delivery systems. So, let the frontend fill the supported delivery systems at the device properties directly. The future plan is that the drivers will stop filling ops->info.type, filling, instead, ops->delsys. This will allow multi-frontend devices like drx-k to use just one frontend structure for all supported delivery systems. Of course, the core will keep using it, in order to keep allowing DVBv3 calls. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'crypto/rmd128.c')
0 files changed, 0 insertions, 0 deletions