From: Of Bjørn Mork
> Rafal Milecki <zajec5@xxxxxxxxx> writes:
>
> > Hi,
> >
> > This is report from my Samsung NP700G7A-S01PL. This notebook has two
> > USB 2.0 ports and two 3.0 ports.
> >
> > Starting with the following commit:
> >
> > commit 7dd09a1af2c7150269350aaa567a11b06e831003
> > Author: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
> > Date: Fri Nov 15 05:34:09 2013 +0200
> >
> > xhci: replace xhci_write_64() with writeq()
> >
> > my USB 3.0 ports don't work anymore. I connect device but don't see
> > any info about new USB device in dmesg. I tried USB 3.0 ports with
> > mouse, serial console adapter, pendrive and hard drive.
>
> Maybe I misunderstand something, but won't that commit end up replacing
> the previous pair of writel() with a single native writeq() on 64bit
> platforms?
>
> Judging by the comment in front of the xhci_write_64(), that might not
> necessarily be supported on all xHCI implementations:
>
> * Some xHCI implementations may support 64-bit address pointers. Registers
> * with 64-bit address pointers should be written to with dword accesses by
> * writing the low dword first (ptr[0]), then the high dword (ptr[1]) second.
> * xHCI implementations that do not support 64-bit address pointers will ignore
> * the high dword, and write order is irrelevant.
>
> I wonder if (some of) these implementations actually depend on this
> two-cycle write, making __raw_writeq() fail?
I think this is a 32bit kernel on hardware that would support a 64bit one.
So the xhci controller supports 64 bits addressing (etc) but the cpu doesn't
have a 64bit write, so writeq() will do two 32bit accesses.
ISTR that these are in the correct order.
I assume the required compiler barrier is present.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
