linux-kernel - Re: [PATCH 01/18] Altera FPGA firmware download module.

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] [day] [month] [year] [list]

Date:	Sun, 16 Jan 2011 15:04:07 -0200
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Ben Gamari <bgamari.foss@...il.com>
CC:	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	"Igor M. Liplianin" <liplianin@...by>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, aospan@...up.ru
Subject: Re: [PATCH 01/18] Altera FPGA firmware download module.

Em 07-01-2011 17:31, Ben Gamari escreveu:
> Hi Mauro,
> 
> On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
>> Em 31-12-2010 09:30, Laurent Pinchart escreveu:
>>> Hi Mauro,
>>>
>>> [snip]
>>>
>>> I understand this. However, a complete JTAG state machine in the kernel, plus 
>>> an Altera firmware parser, seems to be a lot of code that could live in 
>>> userspace.
>>
>> Moving it to userspace would mean a kernel driver that would depend on an
>> userspace daemon^Wfirmware loader to work. I would NAK such designs.
>>
>> The way it is is fine from my POV.
> 
> Any furthur comment on this? As I noted, I strongly disagree and would
> point out that there is no shortage of precedent for the use of
> userspace callbacks for loading of firmware, especially when the process
> is as tricky as this.
> 
> I also work with Altera FPGAs and have a strong interest in making this
> work yet from my perspective it seems pretty clear that the best way
> forward both for both maintainability and useability is to keep
> this code in user-space. There is absolutely no reason why this code
> _must_ be in the kernel and punting it out to userspace only requires
> a udev rule.
> 
> Placing this functionality in userspace results in a massive duplication
> of code, as there are already a number of functional user-space JTAG
> implementations.

On all V4L/DVB drivers I'm ware of, firmwares are loaded via request_firmware, when
userspace tries to use the device, or when the driver is loaded (eventually, it might
have some v4l/dvb legacy drivers with some weird implementation, but this is a bad
practice).

There's currently no V4L/DVB load firmware daemon or V4L/DVB udev rules for loading
firmware that I'm ware of, and I don't like the idea of adding an extra complexity
for userspace to use this device.

So, I'll be adding this driver as proposed. Yet, as some points are risen, I'll
be moving those drivers to staging for 2.6.38. This will give you some time for
propose patches and to better discuss this question.
> 
>>> If I understand it correctly the driver assumes the firmware is in an Altera 
>>> proprietary format. If we really want JTAG code in the kernel we should at 
>>> least split the file parser and the TAP access code.
>>>
>>
>> Agreed, but I don't think this would be a good reason to block the code merge
>> for .38.
>>
> Sure, but there should be agreement that a kernel-mode JTAG state
> machine really is the best way forward (i.e. necessary for effective
> firmware upload) before we commit to carry this code around forever.
> 
> - Ben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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