From: Johan Hovold <firstname.lastname@example.org>
To: Michal Simek <email@example.com>
Cc: Johan Hovold <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
Shubhrajyoti Datta <firstname.lastname@example.org>
Subject: Re: [PATCHv5] serial-uartlite: Remove ULITE_NR_PORTS macro
Date: Tue, 3 Dec 2019 16:27:38 +0100 [thread overview]
Message-ID: <20191203152738.GF10631@localhost> (raw)
On Fri, Nov 15, 2019 at 09:21:03AM +0100, Michal Simek wrote:
> Hi Johan,
> On 13. 11. 19 16:38, Johan Hovold wrote:
> > On Wed, Nov 13, 2019 at 12:00:08PM +0000, email@example.com wrote:
> >> From: Shubhrajyoti Datta <firstname.lastname@example.org>
> >> This patch is removing ULITE_NR_PORTS macro which limits number of
> >> ports which can be used. Every instance is registering own struct
> >> uart_driver with minor number which corresponds to alias ID (or 0 now).
> >> and with 1 uart port. The same alias ID is saved to
> >> tty_driver->name_base which is key field for creating ttyULX name.
> >> Because name_base and minor number are setup already there is no need to
> >> setup any port->line number because 0 is the right value.
> >> Signed-off-by: Shubhrajyoti Datta <email@example.com>
> >> Signed-off-by: Michal Simek <firstname.lastname@example.org>
> >> ---
> >> v4: patch addition
> >> v5: Merge the patch so that all the patches compile
> > Greg,
> > Please do not merge this. This is a hack which really needs to be
> > reconsidered as I've pointed before
> > https://lkml.kernel.org/r/20190523091839.GC568@localhost
> I think it is quite a good time to start to talk about it.
> Over the time I am aware about only one issue related to one way how to
> handle console which came recently. I was looking at it 2 weeks before
> ELCE but I need to get back on this.
> Anyway I am ready for discussion about it.
> What was said so far is that we shouldn't add Kconfig option for number
> of uarts. We could maybe hardcode any big number in the driver as is
> done for pl011 but still it is limitation and wasting of space for
> allocation structures which none will use.
> Then I have done this concept and it was merged where struct uart_driver
> is allocated for every instance separately and I really tried to get
> feedback on this as we discussed some time ago.
> Anyway we are where we are and if this needs to be fixed then please
> tell me how you think that this should be solved.
As I told you back in May, registering one uart driver per physical
port is precisely what should not be done. Just register a fixed number
of lines like every other tty driver. And if you're worried about
statically allocated memory, you need to address that in the tty layer
and/or serial core instead of hacking every single uart driver to
Specifically, you could move the uart state allocation to port
registration so that all drivers would benefit from this.
This is already causing way more trouble than it's worth, and the big
number you mention above for pl011 is 14! In comparison, usb-serial
currently supports 512 ports just fine by allocating state at
Greg, I reread some of the mails reachable through the above link and
was reminded that this hack also made it into xilinx_uartps. That would
need to be fixed/reverted as well.
next prev parent reply other threads:[~2019-12-03 15:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 12:00 [PATCHv5] serial-uartlite: Remove ULITE_NR_PORTS macro shubhrajyoti.datta
2019-11-13 15:38 ` Johan Hovold
2019-11-13 22:26 ` Greg KH
2019-11-15 8:21 ` Michal Simek
2019-11-25 13:08 ` Michal Simek
2019-12-03 15:27 ` Johan Hovold [this message]
2019-12-12 10:50 ` Greg KH
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).