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

From: Ben Gamari
Date: Fri Jan 07 2011 - 14:31:59 EST


Hi Mauro,

On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> 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.

> > 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/