[PATCH v13 5/5] uart: pl011: Add support to ZTE ZX296702 uart

[Timur Tabi]

Andre Przywara wrote:
> 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.

We have an internal patch that I'm trying to upstream, but I need the 
amba-pl011 driver to stabilize first.

> 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 use ACPI bindings.  It's our ARM64 server-class SOC.  We use the ACPI 
subtype 13 to identify it.

>> >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.

I guess we'll have to agree to disagree.  I'd rather have the other 
driver subjected to bit rot.  I don't understand why Jun's obscure 
hardware is so great that it needs to complicate things for all the 
other ARM vendors.

> 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.

I'll have to see the code to form an opinion.

> So both you and me could benefit from the wrapper functions already,
> while Jun has some patches less to care about.

Then I suggest that we focus on the wrapper functions now, and then let 
Jun add support for his stuff later.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.