Hi,
The error handling in usblp_write in linux-2.6.18.1 is broken. I suspect
its also broken in 2.6.21 because the code of usblp_write didn't change
since 2.6.18.
If I use blocking IO and any error happens which makes writeurb_status
nonzero the usblp driver will end up in an endless loop sending
> > #define big_endian_descriptors()
> > #define big_endian_registers()
>
> Sounds reasonable. Please submit code when you get it working. :)
Se below. Its untested and I'm not convinced that we really need
special readl_be and writel_be for every architecture. Everybody
will add its r
Hi,
I need an OHCI with Register and DMA descriptor byteorder separate
switchable.
A PCI machine has little endian OHCI registers and little endian Endpoint
and transfer descriptors. For a non PCI OHCI (Netsilicon NS9750 ARM). I need
big endian OHCI registers with little endian DMA descriptors.
T
Hi,
> All architectures support unaligned access, including ARM. Some do it by
> the way of trap processing. It"s just your particular kernel is broken
> for some reason. Talk to your supplier about it.
Yes the arm fixes this misalignment. I did't say that anything doesn't work.
But alignment fixu
Hi,
It seems to be the conversion to a pointer and back that makes
le16_to_cpus to loose the __attribute__((packed)). In my opinion
the compiler should warn that it discards the attribute.
I suspect it does something wrong on other architectures too, but most
support non aligned access. I used gcc-
Hi,
> > Under Big Endian ARM linux-2.6.11.12 the following code from
usb/core/hub.c
> > triggers an alignment exception:
> >
> > le16_to_cpus(&hub->descriptor->wHubCharacteristics); /* This triggers
two
> > alignment exceptions */
> struct usb_hub_descriptor {
> __u8 bDescLength;
> _
Hi,
Under Big Endian ARM linux-2.6.11.12 the following code from usb/core/hub.c
triggers an alignment exception:
le16_to_cpus(&hub->descriptor->wHubCharacteristics); /* This triggers two
alignment exceptions */
if (hub->descriptor->wHubCharacteristics & HUB_CHAR_COMPOUND) { /* This
works */
Th
Hi,
> > The problem that happens with NS9750 is that if you set HC to state
> > operational during reset is still in progress the NS9750 still pulls
> > down both data lines.
> > It then interprets the level on the data lines as a low speed device.
>
> That seems buglike ... it reports low-speed e
Hi,
> The Linux OHCI driver doesn"t keep the timing requirements for the USB
Reset
> in the function hc_reset
> In Linux 2.6 there"s an msleep(50) ... however, in a non-default driver
mode,
> it might power down the root hub ports before sleeping.
> I"m guessing you"re talking about a 2.4 ke
Hi,
The Linux OHCI driver doesn't keep the timing requirements for the USB Reset
in the function hc_reset. At the end of the function hcReset the Host
Controller
is set to state UsbReset:
writel (ohci->hc_control, &ohci->regs->control);
The OpenHCI documentation says that UsbReset state must be m
10 matches
Mail list logo
