Hi,
Alan Stern wrote:
> On Sun, 16 Apr 2006, Andre Draszik wrote:
>>
>> Alan Stern wrote:
>
> You can rely on kmalloc always providing buffers whose actual length is
> divisible by 4. On the other hand, I/O buffers don't always start at the
> beginning of the kmalloc-ed buffer they belong to.
On Sun, 16 Apr 2006, Andre Draszik wrote:
> Hi,
>
> Alan Stern wrote:
> > On Tue, 11 Apr 2006, Andre' Draszik wrote:
> >
> > (1) You shouldn't need to change a class-based device driver such as
> > usb-storage to work with your special host controller. Besides,
> > if you need to c
Hi,
Alan Stern wrote:
> On Tue, 11 Apr 2006, Andre' Draszik wrote:
>
> (1) You shouldn't need to change a class-based device driver such as
> usb-storage to work with your special host controller. Besides,
> if you need to change one then you need to change them all, and
>
Hi,
David Brownell wrote:
> On Tuesday 11 April 2006 8:56 am, Andre' Draszik wrote:
>> I am working on an OHCI driver for a SOC that expects all but control
>> transfers to the root hub to be big endian.
Now, after having more insight into the linux USB code, the reason is of
course, the virtual
On Tue, 11 Apr 2006, Andre' Draszik wrote:
> Hi,
>
> I am working on an OHCI driver for a SOC that expects all but control
> transfers to the root hub to be big endian. Also, it swaps incoming data.
>
> Therefore, I placed some byteswapping code into
> storage/transport.c:usb_stor_bulk_transfer_
On Tuesday 11 April 2006 8:56 am, Andre' Draszik wrote:
> Hi,
>
> I am working on an OHCI driver for a SOC that expects all but control
> transfers to the root hub to be big endian. Also, it swaps incoming data.
Sounds buggy as all get-out. What policy could it use to swap incoming
data bytes?
Hi,
I am working on an OHCI driver for a SOC that expects all but control
transfers to the root hub to be big endian. Also, it swaps incoming data.
Therefore, I placed some byteswapping code into
storage/transport.c:usb_stor_bulk_transfer_sglist(),
host/ohci-q.c:finish_urb(), and
include/linux/us