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

2015-02-25 Thread 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 libftdi+unsubscr...@developer.intra2net.com   
 

-- 
Robin Haberkorn
Developer

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

haberk...@metratec.com
www.metratec.com


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   From a3508896c3823d11dd9340e975d3918687a70cdc Mon Sep 17 00:00:00 2001
From: Robin Haberkorn haberk...@metratec.com
Date: Tue, 27 Jan 2015 22:53:41 +0100
Subject: [PATCH] ftdi_eeprom: added --device option to specify FTDI device

 * previously, the device could only be selected using the vendor_id,
   product_id and default_pid config file options.
   This did not guarantee that a device could be uniquely identified
   (e.g. there could be multiple devices with the same VID/PID).
   Also this severely limited the possibilities of changing a device's
   VID/PID using ftdi_eeprom - this only worked if the device happened
   to have FTDI's VID 0x0403 and a PID equal to default_pid.
 * If the --device option is omitted, ftdi_eeprom defaults to the
   old behaviour of using the config file options.
 * The order of arguments is insignificant. If multiple
   'command' options (--read-eeprom, --erase-eeprom, --flash-eeprom)
   are given, only the last one will determine the action.
---
 ftdi_eeprom/main.c | 109 -
 1 file changed, 75 insertions(+), 34 deletions(-)

diff --git a/ftdi_eeprom/main.c b/ftdi_eeprom/main.c
index c19d111..5799c71 100644
--- a/ftdi_eeprom/main.c
+++ b/ftdi_eeprom/main.c
@@ -145,6 +145,20 @@ static void eeprom_get_value(struct ftdi_context *ftdi, enum ftdi_eeprom_value v
 }
 }
 
+static void usage(const char *program)
+{
+fprintf(stderr, Syntax: %s [...options...] config-file\n, program);
+fprintf(stderr, Valid Options:\n);
+fprintf(stderr, --device description  Specify device to open by decription string. One of:\n);
+fprintf(stderr,  d:devicenode\n);
+fprintf(stderr,  i:vendor:product\n);
+fprintf(stderr,  i:vendor:product:index\n);
+fprintf(stderr,  s:vendor:product:serial\n);
+fprintf(stderr, --read-eeprom   Read eeprom and write to -filename- from config-file\n);
+fprintf(stderr, --erase-eeprom  Erase eeprom\n);
+fprintf(stderr, --flash-eeprom  Flash eeprom\n);
+}
+
 int main(int argc, char *argv[])
 {
 /*
@@ -205,14 +219,20 @@ int main(int argc, char *argv[])
 /*
 normal variables
 */
-int _read = 0, _erase = 0, _flash = 0;
+enum {
+COMMAND_READ = 1,
+COMMAND_ERASE,
+COMMAND_FLASH
+} command = 0;
+const char *cfg_filename = NULL;
+const char *device_description = NULL;
 
 const int max_eeprom_size = 256;
 int my_eeprom_size = 0;
 unsigned char *eeprom_buf = NULL;
 char *filename;
 int size_check;
-int i, argc_filename;
+int i;
 

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

2015-01-29 Thread 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 libftdi+unsubscr...@developer.intra2net.com   



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

2015-01-28 Thread 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

haberk...@metratec.com
www.metratec.com

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com