Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp651869ybb; Fri, 3 Apr 2020 09:21:10 -0700 (PDT) X-Google-Smtp-Source: APiQypJNVpLzM8W5bI0VqyLfnzJDoni9NYMq4vuG5qWJ6rniFR0FU54e7JJUSuOF/qDzZRQ2/TnF X-Received: by 2002:aca:cd0e:: with SMTP id d14mr3393983oig.167.1585930870240; Fri, 03 Apr 2020 09:21:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585930870; cv=none; d=google.com; s=arc-20160816; b=SOqQZ9SD9vDz98HuUvT0YErztBRHq0XEmrdwPWUS26sfRflKBGMa4W89vZQX90uQOa ra2YCD+gVX7O3cjV/8HEbMWR9qghiyLFQ/CVtjt5atdurNnnLojUlp/AFSM1BqdftD91 z2yFoyPdd7xkY2YdfpMUYbRKh+wMXQWWfhLo2EN5dRVj8np3pq9lPijOrl7B7kExZkLt N8cfYAE21iHdCTGelGzdQ+VJXsCXt7VsRQCGlo1hhuUXuxdT56sCuzINa6UWVxarNtGV M04rSqiCABV34QGWWmGgknDLbi4PuBMDX+JkY9FngnsPrG4qmEsdL5NX/+L2dWiHXIg8 PFkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=JeQ++QeKNPkQfRqpkDQZcuL1Onhxk/qOnK68fXzkntA=; b=i0zI6QnUUWFWFA7mqdKYKb4aeTtlpkwyvMLy2Ox3WuCgTvX8vAjdtAt6CuLV2Cj1Hm jE4r/ywIq3rSKbU9fR1EdEHSG6Esjt3UqhGmlxx6g+TkoGgHUl65eNRy9h60OjVn6Ukf qcMeGADQhY4JJqWJwESLXa+Tcwu7T74IGJMhS9xB6x9UBkORXgPEM6Vx4iP9wSCdq1bj zCtvLW00t0fkAyY86E8NT6ey2fptlebPeS8+Y2q4ZrM7VgAVseFUvhqOlCP9sIyX+9xx sMjaKEdGkR2pdnJpLt7+hn136sDFwkcwFi8oNtfvc+WezraRysGdu/Uxi182HKPN/t6d vTtA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1si534194oti.125.2020.04.03.09.20.57; Fri, 03 Apr 2020 09:21:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404229AbgDCQTT (ORCPT + 99 others); Fri, 3 Apr 2020 12:19:19 -0400 Received: from fieber.vanmierlo.com ([84.243.197.177]:48688 "EHLO kerio9.vanmierlo.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2404084AbgDCQTS (ORCPT ); Fri, 3 Apr 2020 12:19:18 -0400 X-Greylist: delayed 1805 seconds by postgrey-1.27 at vger.kernel.org; Fri, 03 Apr 2020 12:19:18 EDT X-Footer: dmFubWllcmxvLmNvbQ== Received: from roundcube.vanmierlo.com ([192.168.37.37]) (authenticated user m.brock@vanmierlo.com) by kerio9.vanmierlo.com (Kerio Connect 9.2.11 beta 1) with ESMTPA; Fri, 3 Apr 2020 17:48:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 03 Apr 2020 17:48:42 +0200 From: Maarten Brock To: Michal Simek Cc: Greg KH , johan@kernel.org, linux-kernel@vger.kernel.org, monstr@monstr.eu, git@xilinx.com, Jiri Slaby , linux-arm-kernel@lists.infradead.org, linux-serial@vger.kernel.org, linux-serial-owner@vger.kernel.org Subject: Re: [PATCH 0/7] serial: uartps: Revert dynamic port allocation In-Reply-To: <2983dbe2-16e6-4b7b-73a6-49d8c3d70510@xilinx.com> References: <20200403093216.GA3746303@kroah.com> <20200403094427.GA3754220@kroah.com> <2983dbe2-16e6-4b7b-73a6-49d8c3d70510@xilinx.com> Message-ID: <211f564d5594994fc677d3fea4222997@vanmierlo.com> X-Sender: m.brock@vanmierlo.com User-Agent: Roundcube Webmail/1.3.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-04-03 11:51, Michal Simek wrote: > > 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. I would argue that the trouble originates from every uart driver using its own naming scheme and thereby creating separate namespaces. If all uarts would register as /dev/ttySnn then the serialN alias method would work. These non-overlapping namespaces is something the linux kernel driver community has allowed to happen. If the namespaces are not abandoned and disallowed, then the serialN alias method must no longer be used for any driver that does not create /dev/ttySnn devices. Every namespace will require its own alias base. Or forget about deriving the number from an alias and set the number in a property in the device tree node itself. The latter has my preference. Maarten