mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Samuel Holland <samuel@sholland.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] usb: xhci: fix Immediate Data Transfer endianness
Date: Wed, 23 Oct 2019 13:05:54 +0300	[thread overview]
Message-ID: <f5029323-9b3b-1c66-3c89-c3230d5a24ea@linux.intel.com> (raw)
In-Reply-To: <20191020015313.4558-1-samuel@sholland.org>

On 20.10.2019 4.53, Samuel Holland wrote:
> The arguments to queue_trb are always byteswapped to LE for placement in
> the ring, but this should not happen in the case of immediate data; the
> bytes copied out of transfer_buffer are already in the correct order.
> Add a complementary byteswap so the bytes end up in the ring correctly.
> 
> This was observed on BE ppc64 with a "Texas Instruments TUSB73x0
> SuperSpeed USB 3.0 xHCI Host Controller [104c:8241]" as a ch341
> usb-serial adapter ("1a86:7523 QinHeng Electronics HL-340 USB-Serial
> adapter") always transmitting the same character (generally NUL) over
> the serial link regardless of the key pressed.
> 

Thanks, nice catch.

It's unfortunate that we ended up with a situation where this fix is the
least intrusive one.
With IDT we would just want to memcpy() bytes an not care about endianness,
but on BE we end up storing data bytes in a u64, and start with a complementary u64
byteswap to counter a later u32 byteswap done after splitting the u64 to upper
and lower 32 bit parts.

This because that TRB field is normally used for 64bit data buffer pointers,
and all code is written to support that

adding to queue

-Mathias

      reply	other threads:[~2019-10-23 10:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-20  1:53 Samuel Holland
2019-10-23 10:05 ` Mathias Nyman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f5029323-9b3b-1c66-3c89-c3230d5a24ea@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=samuel@sholland.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®