On 10/1/13 6:29 AM, Dan Carpenter wrote:
On Tue, Oct 01, 2013 at 06:22:35AM -0500, Dinh Nguyen wrote:
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.
No. "num_channels" should be the actual number of channels instead of
"number of channels - 1".
Matthijs's fix is the best.
CC: Matthijs
Not sure why my mail client leaves Matthijs's contact out of reply-all.
Dinh
regards,
dan carpenter
--
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
