From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934758AbdEVS1P (ORCPT ); Mon, 22 May 2017 14:27:15 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:49970 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933452AbdEVS1M (ORCPT ); Mon, 22 May 2017 14:27:12 -0400 Date: Mon, 22 May 2017 19:26:36 +0100 From: Alan Cox To: Michal Simek Cc: Sam Povilus , , , , , , Subject: Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts Message-ID: <20170522192636.5b578d89@alans-desktop> In-Reply-To: <517d864d-d230-3abc-eb3c-4b628dc4625f@xilinx.com> References: <20170520022154.6766-1-kernel.development@povil.us> <20170520172008.5a979e8a@alans-desktop> <517d864d-d230-3abc-eb3c-4b628dc4625f@xilinx.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > We have in soc vendor tree similar patch but the reason is different. > > tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option. > > This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow > the user to provide the Max number of uart ports information. > If multiple cards (or) PL UARTS are present, the default limit > of 2 ports should be increased. > > I haven't checked all drivers but in our case we have added this as > quick fix for scenarios where you use serial aliases where alias is > pointed to serial2 or more. > In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr > which is required to be passed. > > What's the best driver to look at dynamic allocation? So there are quite a few that dynamically allocate the objects as they are enumerated (eg max3100), but have a maximum set that is just pointers (so for the max number of ports cheaper than the dynamic code) The other question is why is it a CONFIG_ option. I'm assuming these platforms are all ARM and in that case you could just pass the value in the device tree, or hard code a safe maximum number of pointers to a value which is the worst case and then install them as they are enumerated. There are lots of options better than breaking the "one kernel many platforms" model. Alan