linux-kernel - Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c

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]

Message-ID: <CAGoCfixT0rabuv-MAhw4vhhCxyeOgzjb3FGbORPTV3JgkhjKdw@mail.gmail.com>
Date:	Tue, 17 Dec 2013 16:25:35 -0500
From:	Devin Heitmueller <dheitmueller@...nellabs.com>
To:	Antti Palosaari <crope@....fi>
Cc:	Connor Behan <connor.behan@...il.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Frederik Himpe <fhimpe@...enet.be>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR:
 i2c_transfer returned: -19

On Tue, Dec 17, 2013 at 4:09 PM, Antti Palosaari <crope@....fi> wrote:
> That shared DVB / V4L2 tuner is one problem that I have also currently (SDR
> is on V4L2 API and DTV is provided via DVB API). I have decided to try model
> where I separate RF tuner totally independent used DVB / V4L2 APIs, just to
> plain I2C driver model. Idea is here to provide needed set of general
> callbacks and communication and device binding is done via I2C driver model.
> I am not sure though if there is any big caveats I haven't realized yet...

It's a tough problem - a more strictly defined API in theory allows
for better uniformity across drivers (although admittedly we've done a
piss-poor job in practice).  However such a strictly defined API makes
it harder to add hacks that are sometimes required by the silicon.

The additional abstractions provided by v4l2 subdev and tuner-core
just make it that much harder to get past those layers and poke the
device directly (which as much as I hate to admit it, is sometimes
required to work around bugs and weird edge cases in the silicon not
addressable via the API).  These problems are exacerbated by cases
where there are order-of-operations requirements that cannot be
accommodated by the API.

All that said though, moving to an entirely I2C based API feels like
to provides "too much flexibility" such that every bridge will talk a
little differently to every tuner.  Given what a crappy job we've done
in the past even with a strict framework, I cringe to think how much
worse the problem would be if every developer took a different
approach.

I'm not against implementing a callback which allows you to feed
arbitrary I2C commands to a device, to be used *sparingly* for those
cases where it is *really* required to do something not supported via
the framework's API.  But I don't see it as a replacement for the
existing frameworks for addressing tuners.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/