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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 23 Jun 2021 09:33:12 +0200
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     YP WU <yp.wu@...iatek.com>
Cc:     <leo.hsiao@...iatek.com>, <Lecopzer.Chen@...iatek.com>,
        <gustavoars@...nel.org>, <hverkuil-cisco@...all.nl>,
        <linux-media@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <Jason-BF.Huang@...iatek.com>, <francis.lee@...iatek.com>
Subject: Re: How to use "DTV_FE_CAPABILITY" command for Frontend.h of Linux
 DVB

Hi,

Em Wed, 23 Jun 2021 14:15:51 +0800
YP WU <yp.wu@...iatek.com> escreveu:

> Hello, dvb frontend maintainer:
> 	I work at mediatek company. Currently I develop TV with Linux DVB system.    
> 	I would like to implement the following LNB use cases: user space would like to know if frontend device node have LNB or not.


I need to understand more about the use case.

The main scenario of userspace needing to know about LNB is on Satellite 
systems. For those, knowing that the standard is DVB-S/S2, ISDB-S, ... is
enough to know that a LNB should be controlled.

However, userspace needs more than the Kernel can provide, as the LNB is
an external component, located at the satellite dish.

Such kind of LNB may implement DiSEqC in order to allow certain control
from the device powering them, but there are several LNB types that
don't provide any control.

Even when those that implement DiSEqC 1.x, there's no way to query the 
LNB properties.

Only after DiSEqC 2.x, there's a way for the LNB to send data back to
the digital TV receiver.

Also, some satellite systems are configured as multipoint. On those,
the LNBf power/control can be done by a centralized equipment. Depending
on the type of arrangement, the LNB control can be set to OFF, as all
channels are received on different intermediate frequencies.

Due to such huge differences, and the lack of a way for the Kernel
to retrieve the satellite configuration, what happens is the
other way around: it should be up to userspace to tell the Kernel 
about it, asking it to turn on/off the LNB power, set the DC voltage
and send/receive DiSEqC commands.

-

That's said, a few devices may have a low noise amplifier that
could be turned on in order to boost the signal gain. The
DTV_LNA is meant to control it.

Currently, the only way to know if LNA is there is to try to
set it, and check for the return code.


> I want to use "DTV_FE_CAPABILITY" to represent above LNB capability, but I am afraid that my usage is not suitable to the original definition.    
> So I would like to consult the following quesitons: 
> 1. The use case for DTV_FE_CAPABILITY in DVB property command.
> 2. Does it have any restriction for using this command?
> 3. What’s your suggestion for using this command?
> 
> File path: include/uapi/linux/dvb/Frontend.h
> #define DTV_FE_CAPABILITY	16
> 

We need to better implement DVB capabilities at the subsystem.

The DTV_FE_CAPABILITY property is meant to duplicate the DVBv3
FE_GET_INFO capabilites (fe_caps), but there are very few bits
left there. They aren't enough to provide all possible capabilities
of a DVB system.

I mean, for instance a DVB-S2 device may support only a subset
of DVB-S2 modulation types. They may eventually not support PLP,
and so on. The number of possible combinations is a way larger
than a 32-bits caps could possible support.

We had some upstream discussions about how to improve it in the
past, but nothing got merged.

IMO, if you're willing to work on a better way to report the
device's capabilities, we should probably implement a new DTV
property.

Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ