[PATCH] tty: xilinx_uartps: Really fix id assignment

[Michal Simek]

On 22. 07. 20 18:50, Maarten Brock wrote:
> On 2020-07-22 09:18, Michal Simek wrote:
>> On 13. 07. 20 18:08, Maarten Brock wrote:
>>> On 2020-07-13 14:10, Helmut Grohne wrote:
>>>> Hi Michal,
>>>>
>>>> On Mon, Jul 13, 2020 at 01:49:38PM +0200, Michal Simek wrote:
>>>>> On 13. 07. 20 9:11, Helmut Grohne wrote:
>>>>> > Let me try to enumerate those I know:
>>>>> >
>>>>> > uart0    | uart1    | console | remark
>>>>> > ---------+----------+---------+----------
>>>>> > serial0  | serial1  | ttyPS0  | regular case
>>>>> > serial0  | serial1  | ttyPS1  | normal assignment, second console
>>>>> > serial1  | serial0  | ttyPS0  | -> Jan Kiszka, broken since revert
>>>>> > disabled | serial0  | ttyPS0  | use only uart1 as serial0
>>>>> > serial0  | disabled | ttyPS0  | regular case with uart1 disabled
>>>>> >
>>>>> > Out of these, I'm actively using configurations 3 and 4.
>>>>> >
>>>>> > Which of these scenarios do you test already?
>>>>>
>>>>> For above we are missing also others
>>>>> serial1 | serial0 | ttyPS1
>>>>> disabled| serial1 | ttyPS1
>>>>
>>>> Is it actually possible to have ttyPS1, but no ttyPS0? I think I tried
>>>> doing that earlier and it resulted in there being ttyPS0, but no
>>>> ttyPS1.
>>>
>>> What if you also have a 16550 (in the PL) and give it the serial0 alias?
>>> Or a UARTlite? The serialN alias is inappropriate to set the number for
>>> ttyPSn. How are you supposed to create all of ttyPS0, ttyS0 and ttyUL0
>>> using a single serial0 alias?
>>
>> yes this combination is not possible and I don't think this is xilinx
>> specific issue.
>> I expect the same problem you have with ttyAMA, ttyS and others.
> 
> Well, it is very easy to add a 16550 in the programmable logic of a Zynq.

agree.

> Worse, it's impossible to only add uartps devices as the IP for it is
> not available to the public.

I expect you mean to PL. It is cadence IP and Xilinx is not the right
company who should releasing this paid IP to public.

> It is less easy to add a 16550 to a CPU with ttyAMA but no external bus.

Nope. Xilinx latest SoC called versal is using pl011/sbsa uart instead
of cadence one that's why it is as simple as was on zynq/zynqmp.

On Xilinx devices you can regularly see mixing devices with ttyPS, ttyS,
ttyAMA and ttyUL.
There could be others but they are more rare cases.

> But if you add e.g. an I2C/SPI based SC16IS7xx which generates ttySCx you
> might have the same problems.

yes and a lot of other examples are also present.

> 
> But the problem is worse. What happens if you give the serial0 alias to
> a xilinx_uartps and the 16550 driver has already taken ttyS0? (Or vice
> versa?) Will the uartps still use ttyPS0 or will it ignore the serial0
> alias? I predict the latter.

yes and this issue is around I expect from time where the first !ttyS
was created.
I my series to this driver (which is reverted now as incorrect design) I
was using bitmaps to find the highest free alias at least for this driver.
But for quite a long time there is commit 351d224f64af ("of: base: add
function to get highest id of an alias stem") which return the highest
ID for certain device type which could be used.

DT alias list is stable it means if driver supports it all the time you
should get order based on it.
It means you shouldn't never reach situation that you will have ttyS0
and ttyPS0 because only one device have serial0 alias.

If uart IP is not listed in alias list you should get highest id and
starts to count from there.
But there is issue related to this too which is that every driver has
NR_PORTS defined. In this case we have 16 in the driver.
When you have serial16 = &uart0 then you can't register it as ttyPS16.

My series was trying to solve it but it was reverted and I haven't had a
time to take a look at it again.

> 
> I see only two ways out.
> * Let uartps generate ttySx device names, or

It is not just about uartps but about all drivers and just use ttySx.
(not sure if this should be also for ttyUSBx devices)

> * Do not use serialN alias to set the number.

If this support is removed I expect it will caused a lot of issues for
others SOCs.


> It was already stated that it is impossible to have ttyPS1 and no ttyPS0.
> That would mean we cannot give serial0 to ttyS0 and serial1 to ttyPS1.
> This makes me wonder if the opposite is valid: to give serial0 to ttyPS0
> and serial1 to ttyS1. Probably not either.

Please take a look at Helmut's reply where he retest this scenario and
having ttyPS1 without ttyPS0 is possible.

> 
> There really needs to be a way to create deterministic names for the
> devices!

If you have alias list described for all devices you have deterministic
names already.
But the highest ID in name is limited by every driver which seems to
limitation which shouldn't be there.
If I write for example serial1000 = &whatever_uart; then I would expect
that I will get ttyX1000 which points to this device.

And as was also confirmed alias list is stable for base dts file. When
you start to work with device tree overlays alias list can't be extended
with newly added devices which has to use dynamic ID assignment.


>>>>> serial1 | disables | ttyPS0
>>>>
>>>> I'm not sure what this is supposed to mean. When there is no serial0
>>>> alias, I'd expect ttyPS0 to be missing. However as indicated above that
>>>> is not what happens in practice. So either of these two configurations
>>>> seems invalid to me.
>>>>
>>>>> All of these above are just not setting any console= on bootargs.
>>>>
>>>> We usually set the console= assignment on bootargs.
>>>>
>>>>> It means mix of these combinations is tested regularly but not all of
>>>>> them. Do you see any other combination which is not supported?
>>>>
>>>> I'm not aware of further relevant combinations.
>>>>
>>>> Can we maybe trim down the matrix somehow? In my context, the need for
>>>> swapping the serial aliases arises from a limitation in u-boot-xlnx and
>>>> the desire to use one dtb for both linux and u-boot. It requires that
>>>> the serial0 alias is the console. Are there other reasons to swap them?
>>>> If not, maybe fixing u-boot would be an option?
>>>>
>>>> Helmut
>>>
>>> I think that it would be better if u-boot used a "console" alias.
>>
>> console is defined in bootargs which is OS specific feature. U-Boot has
>> no idea what ttyPS, ttyS, etc means. That's why I don't think there is
>> something wrong in this in u-boot. But please elaborate more on this
>> because I am not aware about any issue on u-boot configuration.
>>
>> Thanks,
>> Michal
> 
> What I meant to say is that apparently U-boot requires serial0 to point to
> the user-interface. This limits your options when assigning aliases. If
> U-boot would use a different entry (e.g. "console" or better yet
> "earlycon") things might be easier. serial0 should not be special IMHO.
> 
> But let's not diverge too much here.

U-Boot is using stdout path and I am not aware about limitation to have
serial0 alias filled. If stdout is pointing to serial444 then u-boot
should be using it as console without any issue.
If you see any issue in u-boot please send email to u-boot mailing list
and CC me and we can take a look at it but as of today I am not aware
about any issue related to this.

Even serial uclass records serial alias (req) for drivers properly.

	aliases {
		serial0 = &uart0;
		serial1 = &uart1;
		serial2 = &dcc;
		serial1000 = &uartlite;
	};

uclass 80: serial
0     dcc @ 7deb8230, seq -1, (req 2)
1   * serial at ff000000 @ 7deb9db0, seq 0, (req 0)
2     serial at ff010000 @ 7deb9e80, seq -1, (req 1)
3     serial at 800c0000 @ 7deba960, seq -1, (req 1000)


Thanks,
Michal