Hi Matthijs,
On 10/1/13 6:08 AM, Matthijs Kooijman wrote:
Hi Dinh,
Somehow I assumed that was fixed by the hardware, but I see now that you
are right. Yes, making the definition larger is better than moving the
+ 1.
This was my original fix to the problem, but I thought that it would
be confusing when reading the code. I also thought about the "+1"
for host_channels was strange too. For debug outputs, it would be
more accurate to display 16 channels, in code-wise, I see that
host_channels is used in 2 for loops. Does it make sense to just fix
the for loops to include channels 0-15?
I think that fixing this in the places where the value is used is moving
the complexity the wrong way. Not sure if I'm understanding you
correctly, thoguh.
- for (i = 0; i < num_channels; i++) {
+ for (i = 0; i <= num_channels; i++) {
This way you can keep the host_channels at 4 bits, to more accurately
represent the hardware.
Dinh, do you want to do that? The other option is that Matthijs could
fix it and give you the Reported-by credit.
I'm fine with that, if Matthijs wants to submit the fix. I can test
it on my hardware too.
I'll prepare a patch in a few hours. Would be great if you could test,
since my hardware only has a meagre 4 host channels ;-)
Sure...
Dinh
Gr.
Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
