On Fri, Jan 21, 2005 at 08:12:16AM +, David Woodhouse wrote:
> On Thu, 2005-01-20 at 23:58 -0800, Greg KH wrote:
> > Well, we should be byteswapping all of the fields that need to be
> > swapped, right? I'm guessing that userspace is expecting the fields
> > to be in cpu endian, correct?
>
>
On Thu, 2005-01-20 at 23:58 -0800, Greg KH wrote:
> Well, we should be byteswapping all of the fields that need to be
> swapped, right? I'm guessing that userspace is expecting the fields
> to be in cpu endian, correct?
Userspace varies in that. Nobody expects _all_ the fields to be swapped;
the
On Fri, Jan 21, 2005 at 07:49:08AM +, David Woodhouse wrote:
> On Thu, 2005-01-20 at 16:08 -0800, Greg KH wrote:
> > Doh, sorry for missing this one. I've applied your patch to my trees,
> > and will show up in the next -mm release.
>
> Actually I think John's problem was that the usb core
On Fri, Jan 21, 2005 at 07:49:08AM +, David Woodhouse wrote:
On Thu, 2005-01-20 at 16:08 -0800, Greg KH wrote:
Doh, sorry for missing this one. I've applied your patch to my trees,
and will show up in the next -mm release.
Actually I think John's problem was that the usb core code has
On Thu, 2005-01-20 at 23:58 -0800, Greg KH wrote:
Well, we should be byteswapping all of the fields that need to be
swapped, right? I'm guessing that userspace is expecting the fields
to be in cpu endian, correct?
Userspace varies in that. Nobody expects _all_ the fields to be swapped;
the
On Fri, Jan 21, 2005 at 08:12:16AM +, David Woodhouse wrote:
On Thu, 2005-01-20 at 23:58 -0800, Greg KH wrote:
Well, we should be byteswapping all of the fields that need to be
swapped, right? I'm guessing that userspace is expecting the fields
to be in cpu endian, correct?
On Thu, 2005-01-20 at 16:08 -0800, Greg KH wrote:
> Doh, sorry for missing this one. I've applied your patch to my trees,
> and will show up in the next -mm release.
Actually I think John's problem was that the usb core code has now
_stopped_ doing this byteswapping, and he has a lsusb which is
On Thu, Jan 20, 2005 at 08:40:07AM +, David Woodhouse wrote:
> On Wed, 2005-01-19 at 15:39 -0800, John Mock wrote:
> > New to 2.6.11-rc1 is that 'lsusb' exhibits 'endian' problems on the
> > PowerMac.
>
> Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
> idVendor,
> Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
> idVendor, idProduct, and bcdDevice fields in the device descriptor. It
> should probably swap them back before copying it up to userspace.
Yes, it happens with 2.6.11-rc1 on my PowerPC, but not with 2.6.10 (or
before), or on
On Wed, 2005-01-19 at 15:39 -0800, John Mock wrote:
> New to 2.6.11-rc1 is that 'lsusb' exhibits 'endian' problems on the
> PowerMac.
Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
idVendor, idProduct, and bcdDevice fields in the device descriptor. It
should probably swap
On Wed, 2005-01-19 at 15:39 -0800, John Mock wrote:
New to 2.6.11-rc1 is that 'lsusb' exhibits 'endian' problems on the
PowerMac.
Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
idVendor, idProduct, and bcdDevice fields in the device descriptor. It
should probably swap them
Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
idVendor, idProduct, and bcdDevice fields in the device descriptor. It
should probably swap them back before copying it up to userspace.
Yes, it happens with 2.6.11-rc1 on my PowerPC, but not with 2.6.10 (or
before), or on my
On Thu, Jan 20, 2005 at 08:40:07AM +, David Woodhouse wrote:
On Wed, 2005-01-19 at 15:39 -0800, John Mock wrote:
New to 2.6.11-rc1 is that 'lsusb' exhibits 'endian' problems on the
PowerMac.
Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
idVendor, idProduct, and
On Thu, 2005-01-20 at 16:08 -0800, Greg KH wrote:
Doh, sorry for missing this one. I've applied your patch to my trees,
and will show up in the next -mm release.
Actually I think John's problem was that the usb core code has now
_stopped_ doing this byteswapping, and he has a lsusb which is
First, thanks to those involved in the 2.6.10 effort, as that's the first
kernel in quite some time that seems stable on my PowerMac 8500/G3. It is
not quite as good on the Sony VAIO laptop, due to software suspend problems
(mostly USB related).
2.6.11-rc1 seemed to help with the VAIO laptop's
First, thanks to those involved in the 2.6.10 effort, as that's the first
kernel in quite some time that seems stable on my PowerMac 8500/G3. It is
not quite as good on the Sony VAIO laptop, due to software suspend problems
(mostly USB related).
2.6.11-rc1 seemed to help with the VAIO laptop's
16 matches
Mail list logo
