linux-kernel - Re: [linux-dvb] [PATCH] Userspace tuner

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: <d9def9db0709130932o2ca847f0xd4eb9c24560eb3ff@mail.gmail.com>
Date:	Thu, 13 Sep 2007 18:32:57 +0200
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Manu Abraham" <abraham.manu@...il.com>
Cc:	"Johannes Stezenbach" <js@...uxtv.org>,
	linux-kernel@...r.kernel.org, video4linux-list@...hat.com,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>,
	akpm@...ux-foundation.org
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

On 9/13/07, Manu Abraham <abraham.manu@...il.com> wrote:
> Markus Rechberger wrote:
> > On 9/13/07, Manu Abraham <abraham.manu@...il.com> wrote:
> >>> It's only a step in development, I do not intend to keep the kernel
> >>> stub in the end, but I do intend to keep and use the userspace drivers
> >>> with i2c-dev in the long run, this requires a v4l/dvb library at the
> front
> >>> of everything.
> >> Well, this was what adq and myself did with libdvbapi and mti, (much
> >> before UIO was announced at LK.) It is not tied to I2C either.
> >>
> >
> > I2C is the main communication path for it, although there are callback
> > mechanisms available which add the possibility for different configuration
> > paths.
>
> Sorry, i must say that what you said is wrong.
>
> The example implementation in libdvbapi/mti is I2C only with a STV0299
> on the TTPCI, if that was what you meant.
> But if you need examples for every possible interface, then probably you
> are out of luck.
>

I didn't comment the libdvbapi/mti driver.
I'm quite confident that non I2C protocols can be handled by a callback
function. In the end it's either a usb control command or pci mmio writes
in the current usual cases and such calls could be handled behind a
callback function which is implemented in the driver.

Markus
-
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/