Hi,
I came across a problem with an USB SD card reader apparently causing
USB resets and corrupting data on the card.
The reader in question is a very cheap:
14cd:1212 Super Top microSD card reader (SY-T18)
The card is an old SDHC, 32 GB, Sandisk brand.
The problems don't seem to exist now if I
Arnd Bergmann writes:
> This addresses both issues by moving all the definitions into the
> pxa25x_udc driver itself. It turns out the only difference between
> them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> was incorrectly copied from pxa25x to ixp4xx.
>
> Signed-off-by: Arn
Arnd Bergmann writes:
> The unclear part here is for IXP4xx, which supports both big-endian
> and little-endian configurations. So far, the driver has done
> no byteswap in either case. I suspect that is wrong and it would
> actually need to swap in one or the other case, but I don't know
> which
Arnd Bergmann writes:
>> Anyway, I think readl()/writel() do the right thing: in BE mode they
>> swap PCI accesses and don't swap normal registers, in LE mode nothing is
>> swapped.
>
> This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but
> not otherwise. For the indirect variant, wr
Arnd Bergmann writes:
> I consider the use of __raw_* accessors a bug, I don't think we should
> ever do that because it hides how the hardware actually works, it doesn't
> work with spinlocks, and it can lead to the compiler splitting up accesses
> into byte sized ones (not on ARM with the curre
Arnd Bergmann writes:
> The barriers on a spinlock synchronize between CPUs but not an external
> bus, so (on some architectures) a spinlock protecting an MMIO register
> does not guarantee that two CPUs doing
>
> spin_lock();
> __raw_writel(address);
> __raw_writel(data);
>
Arnd Bergmann writes:
> Both writes leave the CPU core within the spinlock but are not serialized
> with anything else, so there is no ordering between the CPUs when they
> enter the shared bus, other than having address before data. You'd
> expect to see address0, data0, address1, data1, but it
Arnd Bergmann writes:
> ixp4xx is really special in that it performs hardware swapping for
> internal devices based on CPU endianess but not on PCI devices.
Again, IXP4xx does not perform hardware (nor any other) swapping for
registers of on-chip devices. The registers are connected 1:1,
bit 0 t
Arnd Bergmann writes:
> Ok, so I guess what this means is that ixp4xx (or xscale in general)
> implements its big-endian mode by adding a byteswap on its DRAM
> and PCI interfaces in be32 mode, rather than by changing the behavior of
> the load/store operations (as be8 mode does) or by having the
