Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755485AbaGWGai (ORCPT ); Wed, 23 Jul 2014 02:30:38 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:62786 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753477AbaGWGaf (ORCPT ); Wed, 23 Jul 2014 02:30:35 -0400 MIME-Version: 1.0 In-Reply-To: <20140709142333.503a9e39@alan.etchedpixels.co.uk> References: <1403781875-5425-1-git-send-email-t.figa@samsung.com> <20140626113939.GP32514@n2100.arm.linux.org.uk> <53AC0BCC.1010608@samsung.com> <20140709142333.503a9e39@alan.etchedpixels.co.uk> Date: Wed, 23 Jul 2014 07:30:33 +0100 Message-ID: Subject: Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs From: Daniel Drake To: One Thousand Gnomes Cc: Tomasz Figa , Russell King - ARM Linux , linux-samsung-soc , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, devicetree@vger.kernel.org, Kukjin Kim , Marek Szyprowski , Rob Herring , Mark Rutland , Greg Kroah-Hartman , Jiri Slaby , Tomasz Figa Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes wrote: >> I like the sound of going to the standard ttyS notation and only >> providing ports for ones that exist, but is this userspace-visible > > ttyS is 8250 compatible UARTS. > > If the Samsung is not an 8250 compatible UART then it doesn't belong as > ttyS from the kernel perspective. OK, thanks for pointing that out. So we stick with the ttySAC namespace. And by doing that, and sticking to the existing and documented behaviour, it seems like we have already addressed Russells's concern: > The problem you're raising is very much the same problem you have when > there are multiple USB serial devices connected to the machine - you > just get a bunch of /dev/ttyUSB* devices which are unordered (they can > change on each boot, or change order if you disconnect and reconnect > them.) In this case, we have a dedicated namespace and the path information is already fully encoded in the device name. The order and number of ports are fixed, they can't be disconnected and reconnected. There is no real risk of an additional serial controller driver coming to play in the ttySAC namespace. So I think Tomasz's approach is good - although I haven't looked at the code in detail. Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/