Re: [Libusbx-devel] [PATCH] Add topology calls, v3

2012-05-24 Thread Pete Batard
On 2012.05.24 14:12, Xiaofan Chen wrote: > I am not so sure if gerrit is good for libusbx or not. From the OpenOCD > side it seems to be a success mostly. But it does prevent some users > from posting patches as well. OpenOCD is considered to be a big > project whereas libusb/libusbx are much small

Re: [Libusbx-devel] [PATCH] Add topology calls, v3

2012-05-24 Thread Pete Batard
On 2012.05.24 14:17, Xiaofan Chen wrote: > One git question first, how to revert the v2 patch and then apply > this patch? If you just applied a patch, "git reset HEAD" should do the job... I think (I'd have to look up the command, since with TGit I'm just doing that in a couple of clicks by acc

Re: [Libusbx-devel] [PATCH] Add topology calls, v3

2012-05-24 Thread Xiaofan Chen
On Thu, May 24, 2012 at 9:17 PM, Xiaofan Chen wrote: > On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen wrote: >> On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote: >>> Finally got around looking further at the Darwin issue. It looks like the >>> main problem was that process_new_device() was main

Re: [Libusbx-devel] [PATCH] Add topology calls, v3

2012-05-24 Thread Xiaofan Chen
On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen wrote: > On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote: >> Finally got around looking further at the Darwin issue. It looks like the >> main problem was that process_new_device() was maintaining a static device >> pointer for the last device seen

Re: [Libusbx-devel] [PATCH] Add topology calls, v3

2012-05-24 Thread Xiaofan Chen
On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote: > Finally got around looking further at the Darwin issue. It looks like the > main problem was that process_new_device() was maintaining a static device > pointer for the last device seen (last_dev), and the value wasn't reset as > it should when

Re: [Libusbx-devel] [PATCH] Add topology calls, v3

2012-05-24 Thread Pete Batard
Finally got around looking further at the Darwin issue. It looks like the main problem was that process_new_device() was maintaining a static device pointer for the last device seen (last_dev), and the value wasn't reset as it should when calling get_device_list(), resulting in a bad pointer re