From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Antti Palosaari <crope@iki.fi>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
Date: Wed, 27 Jul 2011 17:06:19 -0300 [thread overview]
Message-ID: <4E306FBB.3030904@redhat.com> (raw)
In-Reply-To: <4E306BAE.1020302@iki.fi>
Em 27-07-2011 16:49, Antti Palosaari escreveu:
> On 07/27/2011 10:06 PM, Mauro Carvalho Chehab wrote:
>
>>> + for (i = 0; i<= x; i++) {
>>> + ret = adap->props.frontend_attach(adap);
>>> + if (ret || adap->fe[i] == NULL) {
>>> + /* only print error when there is no FE at all */
>>> + if (i == 0)
>>> + err("no frontend was attached by '%s'",
>>> + adap->dev->desc->name);
>>
>> This doesn't seem right. One thing is to accept adap->fe[1] to be
>> NULL. Another thing is to accept an error at the attach. IMO, the
>> logic should be something like:
>>
>> if (ret< 0)
>> return ret;
>>
>> if (!i&& !adap->fe[0]) {
>> err("no adapter!");
>> return -ENODEV;
>> }
>
> Heh, I tried to keep it functioning as earlier not to break anything! Only thing it does now differently is that it keeps
> silent when 2nd FE attach fails since we don't know always before fe attach if there is fe or not.
>
> So since it *does not change old behaviour* it must be OK. Let fix old problems later. There is millions of DVB USB
> callbacks failing silently - like tuner_attach etc.
>
> Surely I want also fix many old issues but it is always too risky.
I'm talking about adding another bad behavior: let MFE to have one of the FE's
failing.
>
>
>>> + if (dvb_register_frontend(&adap->dvb_adap, adap->fe[i])) {
>>> + err("Frontend %d registration failed.", i);
>>> + dvb_frontend_detach(adap->fe[i]);
>>
>> There is a special case here: for DRX-K, we can't call dvb_frontend_detach().
>> as just one drxk_attach() returns the two pointers. While this is not fixed,
>> we need to add some logic here to check if the adapter were attached.
>
> There is currently no DVB USB driver using DRX-K thus it is not problem. If someone will add such support can fix DRX-K driver.
I agree. I was just rising the question. The glue should be bound together with the first
dvb-usb DRX-K driver.
> Also take into account it is possible to register only 1 FE using DVB USB and manually register 2nd FE as it have been those days.
>
>
>>> + adap->fe[i] = NULL;
>>> + /* In error case, do not try register more FEs,
>>> + * still leaving already registered FEs alive. */
>>
>> I think that the proper thing to do is to detach everything, if one of
>> the attach fails. There isn't much sense on keeping the device partially
>> initialized.
> It is not attach which fails here, it is dvb_register_frontend registration.
Yes, sure. I've miss-named.
> And I thought that too since it is rather major problem. But as it seems to be very easy to do it like that I did. Not big issue though.
Core functions should be more strict than drivers. So, I think it should really
enforce an all-or-nothing behavior here.
>>> + /* use exclusive FE lock if there is multiple shared FEs */
>>> + if (adap->fe[1])
>>> + adap->dvb_adap.mfe_shared = 1;
>>
>> Why? multiple FE doesn't mean that they're mutually exclusive.
>
> And again we ran same MFE discussion..... But if you look DVB USB you can see its main idea
> have been to register multiple adapters in case of not exclusive frontends. That have been
> most likely implemented like that from day-0 of DVB USB.
>
> Another point is that it is not that patch which adds support for MFE. It is old issue and
> I am not responsible of it. See patch where this decision is made in year 2008:
>
> commit 59b1842da1c6f33ad2e8da82d3dfb3445751d964
> Author: Darron Broad <darron@kewl.org>
> Date: Sat Oct 11 11:44:05 2008 -0300
>
> V4L/DVB (9227): MFE: Add multi-frontend mutual exclusion
>
>
> Why to change again old behaviour?
>
>
> Could you now read all with care. As I pointed out almost all your findings are are decisions made *earlier*.
>
> Only thing which is not coming from oldies is that you suggest to unregister all frontends if one register fails.
You miss-understood me. I'm not saying that we should drop support for mfe_shared flag.
I'm just saying that dvb-usb core should not assume that a driver with more than one
FE have them into a mutually exclusive configuration.
If you look at dvb-core, the default for it is mfe_shared = 0. We should keep the same
default for dvb-usb.
In other words, it should be up to the drivers to change mfe_shared flag to 1, and not
to the core.
Cheers,
Mauro
next prev parent reply other threads:[~2011-07-27 20:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-26 0:17 [PATCH 2/3] dvb-usb: multi-frontend support (MFE) Antti Palosaari
2011-07-27 19:06 ` Mauro Carvalho Chehab
2011-07-27 19:49 ` Antti Palosaari
2011-07-27 20:06 ` Mauro Carvalho Chehab [this message]
2011-07-27 20:19 ` Antti Palosaari
2011-08-01 0:46 ` Mauro Carvalho Chehab
2011-08-01 1:22 ` Antti Palosaari
2011-08-01 2:24 ` Mauro Carvalho Chehab
2011-09-07 16:51 ` Antti Palosaari
2011-09-07 17:41 ` Michael Krufky
2011-09-07 17:45 ` Michael Krufky
2011-09-07 18:04 ` Michael Krufky
2011-09-07 18:20 ` Antti Palosaari
2011-09-07 18:36 ` Michael Krufky
2011-09-07 21:10 ` Antti Palosaari
2011-09-07 21:32 ` Michael Krufky
2011-07-27 22:07 ` Malcolm Priestley
2011-07-27 22:23 ` Antti Palosaari
2011-07-31 18:28 ` Patrick Boettcher
2011-08-01 1:28 ` Antti Palosaari
-- strict thread matches above, loose matches on Subject: below --
2011-07-28 21:35 Antti Palosaari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E306FBB.3030904@redhat.com \
--to=mchehab@redhat.com \
--cc=crope@iki.fi \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.