From: Andre Przywara <andre.przywara@arm.com>
To: Timur Tabi <timur@codeaurora.org>, Jun Nie <jun.nie@linaro.org>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"peter@hurleysoftware.com" <peter@hurleysoftware.com>,
"jason.liu@linaro.org" <jason.liu@linaro.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Andrew Jackson <Andrew.Jackson@arm.com>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
"wan.zhijun@zte.com.cn" <wan.zhijun@zte.com.cn>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v13 5/5] uart: pl011: Add support to ZTE ZX296702 uart
Date: Mon, 26 Oct 2015 14:42:23 +0000 [thread overview]
Message-ID: <562E3BCF.7010000@arm.com> (raw)
In-Reply-To: <562E33AE.2020608@codeaurora.org>
Hi,
On 26/10/15 14:07, Timur Tabi wrote:
> Andre Przywara wrote:
>
>> Yeah, I was interested in that scenario too, because the SBSA spec
>> actually speaks of 32-bit registers and vendors may implement it
>> strictly as that. Still waiting for actual failure reports on this
>> before I wanted to push a fix, though.
>
> What do you mean by failure reports? Our hardware generates an SError
> if you try to access the PL011 registers with 8-bit or 16-bit reads or
> writes.
I meant that if some hardware does not work with an upstream kernel, I'd
expect some kind of failure report or a patch on the public mailing
list. I may have missed it, but I couldn't find anything on the list so far.
As mentioned earlier, I didn't want to change code without good reasons,
that's why I was waiting for people to scream.
So I just take this as a scream, then ;-)
Can you elaborate on that? Is your UART a PL011 one (using the arm,pl011
DT binding or AMBA ID registers) or are you using the SBSA subset only?
Is there some means to identify this particular UART?
>>> We have an internal patch
>>> that replaces all of the read/write routines with vendor function calls.
>>> I would need to refactor our patch on top of yours.
>>
>> But wouldn't Jun's patch address this more easily, because it wraps
>> every call already? TBH I found this change the most interesting.
>
> Yes, but I think it changes a lot of things unnecessarily, like the
> register names.
Which is unfortunate, but cannot be changed anymore. And as much as I
dislike this myself, I guess we cannot ignore this hardware just because
it doesn't go easily with our driver code. So instead of having just
another driver which is strikingly similar, I'd rather have this in the
one-and-only PL011 driver which is much less subject to bit-rot.
So my idea here was to split Jun's series into introducing the
readl/writel wrappers first, and adding the register address mangling on
top of that. Given that those changed register addresses seem to be a
mishap to me, we could just get away with a ZTE specific translate
function, which takes a PL011 register number and returns the actual
register offset to use. That isn't very generic, but would hide this
ugliness without spoiling the whole driver.
So both you and me could benefit from the wrapper functions already,
while Jun has some patches less to care about.
Cheers,
Andre.
next prev parent reply other threads:[~2015-10-26 14:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1438328959-16177-1-git-send-email-jun.nie@linaro.org>
[not found] ` <1438328959-16177-3-git-send-email-jun.nie@linaro.org>
2015-09-18 10:51 ` [PATCH v13 2/5] uart: pl011: Introduce register accessor Andre Przywara
2015-09-19 6:46 ` Jun Nie
2015-09-19 21:45 ` Andre Przywara
2015-10-22 23:36 ` Timur Tabi
2015-10-28 14:22 ` Peter Hurley
2015-10-28 14:51 ` Timur Tabi
2015-10-28 15:08 ` Peter Hurley
[not found] ` <1438328959-16177-5-git-send-email-jun.nie@linaro.org>
2015-09-18 10:58 ` [PATCH v13 4/5] uart: pl011: Improve LCRH register access decision Andre Przywara
[not found] ` <1438328959-16177-6-git-send-email-jun.nie@linaro.org>
2015-09-18 13:50 ` [PATCH v13 5/5] uart: pl011: Add support to ZTE ZX296702 uart Andre Przywara
2015-09-18 13:59 ` Russell King - ARM Linux
2015-09-19 6:47 ` Jun Nie
2015-09-19 6:54 ` Jun Nie
2015-10-23 21:54 ` Timur Tabi
2015-10-24 3:23 ` Jun Nie
2015-10-24 3:32 ` Timur Tabi
2015-10-26 1:27 ` Jun Nie
2015-10-27 13:31 ` Peter Hurley
2015-10-26 9:59 ` Andre Przywara
2015-10-26 12:46 ` Timur Tabi
2015-10-26 14:00 ` Andre Przywara
2015-10-26 14:07 ` Timur Tabi
2015-10-26 14:42 ` Andre Przywara [this message]
2015-10-26 14:47 ` Timur Tabi
2015-10-26 15:19 ` Andre Przywara
2015-10-26 15:31 ` Timur Tabi
2015-10-27 22:54 ` Timur Tabi
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=562E3BCF.7010000@arm.com \
--to=andre.przywara@arm.com \
--cc=Andrew.Jackson@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jason.liu@linaro.org \
--cc=jun.nie@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=peter@hurleysoftware.com \
--cc=shawn.guo@linaro.org \
--cc=timur@codeaurora.org \
--cc=wan.zhijun@zte.com.cn \
/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).