Quantcast

[PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Robin Haberkorn
Hello,

ftdi_eeprom currently does not allow you to specify the FTDI device
reliably/uniquely, nor is reflashing of the VID/PID allowed in every case.

I attached a patch (02-ftdi_eeprom_device_selection.patch) fixing this.
It applies on top of the last patch I sent, which I'm attaching here
again for convenience (01-cbusx.patch).

Best regards,
Robin

btw.: Hosting a Github mirror of the libftdi repository could boost free
software contributions to libftdi. With a Github repository, I could
create a fork and maintain my "patches" on a public branch, while
sending you pull requests. You could then merge it into the mirror
repository and pull changes from the mirror into the upstream repository.

--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

[hidden email]
www.metratec.com


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

01-cbusx.patch (16K) Download Attachment
02-ftdi_eeprom_device_selection.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Paul Fertser
Hi,

On Tue, Jan 27, 2015 at 11:21:17PM +0100, Robin Haberkorn wrote:
> btw.: Hosting a Github mirror of the libftdi repository could boost free
> software contributions to libftdi. With a Github repository, I could
> create a fork and maintain my "patches" on a public branch, while
> sending you pull requests.

How is it different from the current situation? Anybody can fork
current git repo, maintain public branches anywhere he or she would
prefer and send pull requests.

Unless when you say "pull request" you do not mean git-request-pull(1)
but the unique non-standard proprietary github "pullrequest" which
would force the maintainers to use github webui to do their work and
depend on a single commercial entity.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[hidden email]

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Robin Haberkorn
Hi,

On 28.01.2015 07:42, Paul Fertser wrote:
> Hi,
>
> ...
>
> Unless when you say "pull request" you do not mean git-request-pull(1)
> but the unique non-standard proprietary github "pullrequest" which
> would force the maintainers to use github webui to do their work and
> depend on a single commercial entity.
>
Yes, that's exactly what I mean. It's a little bit more convenient with
Github and you get a ticket system. Sending "git-request-pull" mails or
patches does of course work as well. It would also still work if you had
a Github mirror. It would be just another way to receive contributions
and draw attention to the project.
But this is not very important to me. It was only a suggestion.

Best regards,
Robin

--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

[hidden email]
www.metratec.com

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Thomas Jarosch
Hi Robin,

On 01/28/2015 06:41 PM, Robin Haberkorn wrote:

>> Unless when you say "pull request" you do not mean git-request-pull(1)
>> but the unique non-standard proprietary github "pullrequest" which
>> would force the maintainers to use github webui to do their work and
>> depend on a single commercial entity.
>>
> Yes, that's exactly what I mean. It's a little bit more convenient with
> Github and you get a ticket system. Sending "git-request-pull" mails or
> patches does of course work as well. It would also still work if you had
> a Github mirror. It would be just another way to receive contributions
> and draw attention to the project.
> But this is not very important to me. It was only a suggestion.

libftdi already has 62 contributors (see AUTHORS),
so I would say it's a pretty active project :)

The problem with github's ticket system and other
"convenience" features is the vendor lock-in. The easiest way
to send patches is to create them with "git format-patch" and friends.
That way the code changes can be reviewed on the mailinglist,
probably even offline once downloaded. The linux kernel is
developed this way, so it scales pretty good.

Unfortunately I can't do much work this week
since I have to stay in bed :( Sorry 'bout that.

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Thomas Jarosch
In reply to this post by Robin Haberkorn
Hi Robin,

On 01/27/2015 11:21 PM, Robin Haberkorn wrote:
> ftdi_eeprom currently does not allow you to specify the FTDI device
> reliably/uniquely, nor is reflashing of the VID/PID allowed in every case.
>
> I attached a patch (02-ftdi_eeprom_device_selection.patch) fixing this.
> It applies on top of the last patch I sent, which I'm attaching here
> again for convenience (01-cbusx.patch).

I've reviewed and applied the 01-cbusx.patch.
Thanks for this high quality contribution.

How did you generate the patch file? Using "Write commit to file" in gitk?
Please use "git format-patch HEAD~XXX" the next time. Then I can just
apply them via "git am" without manually copying the commit msg etc. over.

Regarding the ftdi_eeprom patch: It alters the current behavior.
If someone uses "--erase" together with "--flash", it is no longer possible.
Imagine someone wants to flash a shorter eeprom than
the one that's currently on the chip, then "--erase"
is really helpful to ensure there's no garbage left.

What do you think?

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Robin Haberkorn
Hi Thomas,

On 12.02.2015 22:39, Thomas Jarosch wrote:
> ...
>
> I've reviewed and applied the 01-cbusx.patch.
> Thanks for this high quality contribution.
>
Thank you for applying it!

> How did you generate the patch file? Using "Write commit to file" in gitk?
> Please use "git format-patch HEAD~XXX" the next time. Then I can just
> apply them via "git am" without manually copying the commit msg etc. over.
>
No, I'm not using stupid Git GUIs :-)
Simply used `git show >foo.patch`, assuming you want to apply it like a
regular patch file.
I rebased the ftdi_eeprom "--device" patch on top of libftdi's current
master branch and I'm attaching it here again in git-format-patch style.

> Regarding the ftdi_eeprom patch: It alters the current behavior.
> If someone uses "--erase" together with "--flash", it is no longer possible.
> Imagine someone wants to flash a shorter eeprom than
> the one that's currently on the chip, then "--erase"
> is really helpful to ensure there's no garbage left.
>
> What do you think?
>
I'm not sure if erasing before flashing makes any sense. Is it even
possible for the EEPROM size to change on one chip?

Nevertheless, my patch does not really affect ftdi_eeprom's behaviour in
this regard as ftdi_eeprom used the following check on command-line
arguments in 1162549f which effectively limits you to performing a
single command per ftdi_eeprom invocation:

    if (argc != 2 && argc != 3)
    {
        printf("Syntax: %s [commands] config-file\n", argv[0]);
        printf("Valid commands:\n");
        printf("--read-eeprom  Read eeprom and write to -filename- from
config-file\n");
        printf("--erase-eeprom  Erase eeprom\n");
        printf("--flash-eeprom  Flash eeprom\n");
        exit (-1);
    }

What the patch changes is allowing an arbitrary number of parameters so
that the optional "--device" option can be supported.

So I see no reason not to apply it.

> Cheers,
> Thomas
>
Regards,
Robin

>
> --
> libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> To unsubscribe send a mail to [hidden email]  
>

--
Robin Haberkorn
Developer

metraTec GmbH
Werner-Heisenberg-Str. 1
39106 Magdeburg
Germany

[hidden email]
www.metratec.com


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

0001-ftdi_eeprom-added-device-option.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [PATCH] ftdi_eeprom: reliable device selection and flashing of new VID/PIDs

Thomas Jarosch
On Wednesday, 25. February 2015 20:56:58 Robin Haberkorn wrote:

> Nevertheless, my patch does not really affect ftdi_eeprom's behaviour in
> this regard as ftdi_eeprom used the following check on command-line
> arguments in 1162549f which effectively limits you to performing a
> single command per ftdi_eeprom invocation:
>
>     if (argc != 2 && argc != 3)
>     {
>         printf("Syntax: %s [commands] config-file\n", argv[0]);
>         printf("Valid commands:\n");
>         printf("--read-eeprom  Read eeprom and write to -filename- from
> config-file\n");
>         printf("--erase-eeprom  Erase eeprom\n");
>         printf("--flash-eeprom  Flash eeprom\n");
>         exit (-1);
>     }
>
> What the patch changes is allowing an arbitrary number of parameters so
> that the optional "--device" option can be supported.

Good point. I've applied your patch with a minor typo fix.

Thanks,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Loading...