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.
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
