From: Michal Simek <michal.simek@xilinx.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Michal Simek <michal.simek@xilinx.com>
Cc: johan@kernel.org, linux-kernel@vger.kernel.org, monstr@monstr.eu,
git@xilinx.com, Jiri Slaby <jslaby@suse.com>,
linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH 0/7] serial: uartps: Revert dynamic port allocation
Date: Fri, 3 Apr 2020 11:51:32 +0200 [thread overview]
Message-ID: <2983dbe2-16e6-4b7b-73a6-49d8c3d70510@xilinx.com> (raw)
In-Reply-To: <20200403094427.GA3754220@kroah.com>
On 03. 04. 20 11:44, Greg KH wrote:
> On Fri, Apr 03, 2020 at 11:37:46AM +0200, Michal Simek wrote:
>> On 03. 04. 20 11:32, Greg KH wrote:
>>> On Fri, Apr 03, 2020 at 11:24:29AM +0200, Michal Simek wrote:
>>>> Hi,
>>>>
>>>> there were several changes done in past in uartps drivers which have been
>>>> also done in uartlite driver.
>>>> Here is the thread about it
>>>> https://lore.kernel.org/linux-serial/20191203152738.GF10631@localhost/
>>>>
>>>> This series reverts all patches which enabled dynamic port allocation and
>>>> returning driver to the previous state. There were added some features in
>>>> meantime which are not affected by this series.
>>>
>>> Should this go into 5.7-final as it's causing problems now, and
>>> backported as well? Or can it wait until 5.8-rc1?
>>
>> These patches have been added to v4.20. It means all version from that
>> are affected.
>>
>> The issue I am aware of is when you setup stdout-path =
>> "serialX:115200n8" where X is not 0.
>>
>> But as was discussed the concept is based on Johan wrong that's why it
>> can be consider as bug fix.
>
> Ok, I'll queue these up after 5.7-rc1 is out, for inclusion in
> 5.7-final, and cc: for stable, as I agree, they should all be reverted.
> Thanks for doing the work.
Thanks. I am definitely interested to hear more how this could be done
differently because that hardcoded limits are painful.
On FPGAs you can have a lot of uarts for whatever reason and users are
using DT aliases to have consistent naming.
Specifically on Xilinx devices we are using uartps which is ttyPS,
uartlite which is ttyUL, ns16500 which is ttyS and also pl011 which is
ttyAMA.
Only ttyAMA or ttyPS on one chip are possible.
And right now you can't have serial0 alias pointed ttyPS0 and another
serial0 pointed to ttyUL0 or ttyS0. That's why others are shifted and we
can reach that hardcoded NR_UART limit easily.
And this was the reason why I have done these patches in past to remove
any limit from these drivers and if user asks for serial100 alias you
simply get ttyPS100 node.
Johan mentioned any solution use in USB stack but I haven't really had a
time to take a look at it how feasible it is to bring back to all drivers.
Thanks,
Michal
next prev parent reply other threads:[~2020-04-03 9:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 9:24 Michal Simek
2020-04-03 9:24 ` [PATCH 1/7] Revert "serial: uartps: Fix uartps_major handling" Michal Simek
2020-04-03 9:24 ` [PATCH 2/7] Revert "serial: uartps: Use the same dynamic major number for all ports" Michal Simek
2020-04-03 9:24 ` [PATCH 3/7] Revert "serial: uartps: Fix error path when alloc failed" Michal Simek
2020-04-03 9:24 ` [PATCH 4/7] Revert "serial: uartps: Do not allow use aliases >= MAX_UART_INSTANCES" Michal Simek
2020-04-03 9:24 ` [PATCH 5/7] Revert "serial: uartps: Change uart ID port allocation" Michal Simek
2020-04-03 9:24 ` [PATCH 6/7] Revert "serial: uartps: Move Port ID to device data structure" Michal Simek
2020-04-03 9:24 ` [PATCH 7/7] Revert "serial: uartps: Register own uart console and driver structures" Michal Simek
2020-04-03 9:32 ` [PATCH 0/7] serial: uartps: Revert dynamic port allocation Greg KH
2020-04-03 9:37 ` Michal Simek
2020-04-03 9:44 ` Greg KH
2020-04-03 9:51 ` Michal Simek [this message]
2020-04-03 15:48 ` Maarten Brock
2020-04-03 15:56 ` Michal Simek
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=2983dbe2-16e6-4b7b-73a6-49d8c3d70510@xilinx.com \
--to=michal.simek@xilinx.com \
--cc=git@xilinx.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=jslaby@suse.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=monstr@monstr.eu \
/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
all inboxes | Powered by JetHome®