From: Arnd Bergmann <arnd@arndb.de>
To: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-mips@linux-mips.org, 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, Felipe Balbi <balbi@ti.com>,
Douglas Anderson <dianders@chromium.org>,
Gregory Herrero <gregory.herrero@intel.com>,
Mian Yousaf Kaukab <yousaf.kaukab@intel.com>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH] usb: dwc2: fix regression on big-endian PowerPC/ARM systems
Date: Thu, 12 May 2016 13:36:40 +0200 [thread overview]
Message-ID: <2809110.sWekaCNVxS@wuerfel> (raw)
In-Reply-To: <8760ujecw2.fsf@linux.intel.com>
On Thursday 12 May 2016 14:25:49 Felipe Balbi wrote:
> > {
> > u32 value = __raw_readl(addr);
> >
> > - /* In order to preserve endianness __raw_* operation is used. Therefore
> > - * a barrier is needed to ensure IO access is not re-ordered across
> > + /* in order to preserve endianness __raw_* operation is used. therefore
> > + * a barrier is needed to ensure io access is not re-ordered across
> > * reads or writes
> > */
> > mb();
> > @@ -81,15 +93,32 @@ static inline void dwc2_writel(u32 value, void __iomem *addr)
> > __raw_writel(value, addr);
> >
> > /*
> > - * In order to preserve endianness __raw_* operation is used. Therefore
> > - * a barrier is needed to ensure IO access is not re-ordered across
> > + * in order to preserve endianness __raw_* operation is used. therefore
> > + * a barrier is needed to ensure io access is not re-ordered across
> > * reads or writes
> > */
> > mb();
> > -#ifdef DWC2_LOG_WRITES
> > - pr_info("INFO:: wrote %08x to %p\n", value, addr);
> > +#ifdef dwc2_log_writes
> > + pr_info("info:: wrote %08x to %p\n", value, addr);
> > #endif
> > }
> > +#else
Oops, the accidental lowercase conversion is still in here, I'll fix it
up once we agree on the approach.
> I still think this is something that should be handled at MIPS side, no ?
As I explained, there isn't really anything we can do in MIPS code
because of the way they have to handle PCI.
> How many more drivers will we have to 'fix' like this ?
Endianess problems will keep coming up, and we have hundreds or thousands
of drivers that are written with a particular design in mind that could
be wrong as soon as someone chooses to build an SoC that does things
differently. Once that happens, we'll fix them.
Also, Christian has already posted a better version of the patch
that fixes this driver in an architecture independent way, but we still
need a workaround for the stable backports.
Arnd
next prev parent reply other threads:[~2016-05-12 11:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 10:48 [PATCH] usb: dwc2: fix regression on big-endian PowerPC/ARM systems Arnd Bergmann
2016-05-12 11:25 ` Felipe Balbi
2016-05-12 11:36 ` Arnd Bergmann [this message]
2016-05-12 11:43 ` Felipe Balbi
2016-05-12 11:52 ` 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=2809110.sWekaCNVxS@wuerfel \
--to=arnd@arndb.de \
--cc=a.seppala@gmail.com \
--cc=balbi@ti.com \
--cc=benh@kernel.crashing.org \
--cc=chunkeey@googlemail.com \
--cc=dianders@chromium.org \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=gregory.herrero@intel.com \
--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 \
--cc=m.szyprowski@samsung.com \
--cc=yousaf.kaukab@intel.com \
/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