linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Christian Lamparter <chunkeey@googlemail.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@linux-mips.org,
	Felipe Balbi <felipe.balbi@linux.intel.com>,
	johnyoun@synopsys.com, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	a.seppala@gmail.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4
Date: Tue, 10 May 2016 08:43:11 +1000	[thread overview]
Message-ID: <1462833791.20290.134.camel@kernel.crashing.org> (raw)
In-Reply-To: <2764525.eheC8xZt4u@debian64>

On Mon, 2016-05-09 at 21:06 +0200, Christian Lamparter via Linuxppc-dev wrote:
> 
> I ran into the following issues:
>         - gadget.c uses ioread32_rep [0] & iowrite32_rep [1].
>           This is interesting because both of these functions actually use
>           the __raw_io* on powerpc. This is because powerpc uses the default
>           defines of include/asm-generic/io.h [2].
> 
>           Ideally, this should be done by sth like a writesl_be or writesl(e)
>           function. But I found none so for now: Let's make a ugly hack:
>           to_correct_endian that will work for testing, but will be replaced.

No. The _rep variants always must use native endian. If for some reason
your device requires something different then the device is more broken
than I thought. IE. even with a BE core and an LE device, we use non-
byeswap _rep versions, this isn't just because we use "defaults" on
powerpc for example, it's necessary to work.

Here too, I could suggest you google for my talk on the subject :-) But
if you think closely about it, you'll figure out that FIFOs don't have
an endian per-se, thus what matters is which byte is first in ascending
address order, and that byte must land in memory in the first address
as well.

Interpreting the resulting data might require endian swaps, but
actually transferring to/from the fifo doesn't.

>    - dwc2_readl, dwc2_writel. I have no insight in the craziness that's
>           going on with MIPS and the memory barrier. But it got me thinking
>           rather than CONFIG_MIPS, isn't there a umbrella
>           "ARCH_HAS_NEED_MEMORY_BARRIER_FOR_MMIO" config symbol?
> 
>         - is_little_endian (do we want a separate is_big_endian?)
>           Also, do we want to be able to overwrite the detection code
>           if the endian setting was set in the device tree?. For now
>           it always does auto detection (see dwc2_detect_endiannes() ).

If auto-detect always work, no need to bother with the device-tree. A
single flag is enough, either is_big or is_little, doesn't matter.

"readl" should always be little, readl_be should always be big, though
the latter isn't supported on all archs. However the new accessors in
iomap.h should provide a "be" variant on all archs so switching to
these might be a good idea.

>         ( - 80 character per line issues, is it possible to drop the
>                  hsotg->reg + REGISTER from the dwc2_readl/writel since we
>                  pass the hsotg now anyway and do the reg + REGISTER
>                  calculation in the accessor? I played around with macros
>                  as most functions calling the accessors have the hsotg
>                  variable anyway )

Or just use a temp variable, the compiler should deal with it the same
way.

Ben.
 
> Regards,
> Christian

  parent reply	other threads:[~2016-05-09 22:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-07 22:54 usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4 Christian Lamparter
2016-05-08 10:40 ` Benjamin Herrenschmidt
2016-05-08 11:44   ` Christian Lamparter
2016-05-09  0:23     ` Benjamin Herrenschmidt
2016-05-09 10:36       ` Arnd Bergmann
2016-05-09 10:39         ` Felipe Balbi
2016-05-09 15:08           ` Arnd Bergmann
2016-05-09 19:06             ` Christian Lamparter
2016-05-09 20:10               ` Arnd Bergmann
2016-05-09 22:43               ` Benjamin Herrenschmidt [this message]
2016-05-09 22:37             ` Benjamin Herrenschmidt
2016-05-10  7:23               ` Arnd Bergmann
2016-05-12  9:58                 ` Christian Lamparter
2016-05-12 11:55                   ` Arnd Bergmann
2016-05-12 13:30                     ` Christian Lamparter
2016-05-12 18:40                       ` John Youn
2016-05-12 20:39                         ` Christian Lamparter
2016-05-12 20:50                           ` Arnd Bergmann
2016-05-12 20:55                           ` John Youn
2016-05-14 13:11                         ` Christian Lamparter
2016-05-14 19:45                           ` Arnd Bergmann
2016-05-17 23:50                           ` John Youn
2016-05-18 19:14                             ` Christian Lamparter
2016-05-18 21:09                               ` Arnd Bergmann
2016-05-19  0:36                               ` John Youn
2016-05-12 22:17                   ` Benjamin Herrenschmidt
2016-05-09 22:33           ` Benjamin Herrenschmidt
2016-05-09 14:02         ` Benjamin Herrenschmidt
2016-05-09 20:22         ` John Youn
2016-05-09 20:38           ` Arnd Bergmann
2016-05-09 21:11             ` John Youn
2016-05-09 21:30               ` Arnd Bergmann

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=1462833791.20290.134.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=a.seppala@gmail.com \
    --cc=arnd@arndb.de \
    --cc=chunkeey@googlemail.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johnyoun@synopsys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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;
as well as URLs for NNTP newsgroup(s).