lkml.org 
[lkml]   [2017]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
Em Sun, 3 Sep 2017 22:05:23 +0200
Honza Petrouš <jpetrous@gmail.com> escreveu:

> > There is still a gap at the CA API, as there are three ioctls that are used
> > only by a few drivers and whose structs are not properly documented:
> > CA_GET_MSG, CA_SEND_MSG and CA_SET_DESCR.
> >
> > The first two ones seem to be related to a way that a few drivers
> > provide to send/receive messages.
>
> I never seen usage of such R/W ioctls, all drivers I have access to
> are using read()/write() variant of communication.

Yeah, the normal usage is to use R/W syscalls.

> BTW, I just remembered dvblast app, part of videolan.org:
>
> http://www.videolan.org/projects/dvblast.html
>
> which is using CA_GET_MSG/CA_SEND_MSG:
>
> https://code.videolan.org/videolan/dvblast/blob/master/en50221.c

From the ca_msg struct:

/* a message to/from a CI-CAM */
struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
};

It only uses length and msg fields. Describing those seem
quite obvious. However, what "index" and "type" means?

Within the Kernel, only two drivers implement it:

$ git grep -l ca_msg drivers/
drivers/media/firewire/firedtv-ci.c
drivers/media/pci/bt8xx/dst_ca.c

At the dst_ca driver, checking for those fields don't give any
useful result:
$ grep index drivers/media/pci/bt8xx/dst_ca.c
(nothing)
$ grep type drivers/media/pci/bt8xx/dst_ca.c
// Copy application_type, application_manufacturer and manufacturer_code
p_ca_caps->slot_type = 1;
p_ca_caps->descr_type = 1;
p_ca_slot_info->type = CA_CI;
p_ca_slot_info->type = CA_CI;

(btw, using "1" for slot_type and descr_type there seems a very bad
thing)

The code at ca_get_message(), handle_dst_tag(), ca_set_pmt(), etc also
doesn't seem to be using neither one of those fields.

The same happens at firedtv-ci: it also doesn't seem to be using
none of those fields.

It should be noticed that, the dst_ca seems to allow more than one
descrambler:

p_ca_caps->descr_num = slot_cap[7];

Yet, the index is not used. So, it doesn't seem to be related to
the descrambler index (or there's an implementation bug there - and
at dvblast - as none uses it).

What *I* suspect is that this were meant to be used for either
CA index/type or DESCR index/type, but, when this got implemented,
people discovered that this would be useless and never actually
used those fields. Yet, I may be completely wrong and those were
added to mean something else.

If so, then we could just change the struct to:

struct ca_msg {
unsigned int reserved[2];
unsigned int length;
unsigned char msg[256];
};

And document just length and msg.

Thanks,
Mauro

\
 
 \ /
  Last update: 2017-09-04 03:19    [W:0.158 / U:0.300 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site