Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4244555imm; Mon, 8 Oct 2018 18:08:08 -0700 (PDT) X-Google-Smtp-Source: ACcGV62pu4SXhqdv7hT1j0mA8pAKxWmFOL8PRObHCSwRNyGq6FTNgP96YSPquf5UX5t2KhucoqC2 X-Received: by 2002:a63:4047:: with SMTP id n68-v6mr18937613pga.224.1539047288179; Mon, 08 Oct 2018 18:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539047288; cv=none; d=google.com; s=arc-20160816; b=BL7vS330WKFRkhqUUoWeNdOz4kVZ7yVNxFysYWDFFpo1JlLoIeFmfI9OGG0ZpmxR6p AcnoVDW4E6byT2s3nO7hH+H4MFG0H0JfH2HvbqNrrI+fKs6eKk1eAeD2b1saszIp8gV7 RsF2hz27W5wGlp0TywZxN/yqy7XaiKbwRLGj0MVfGuVtLkCpmGlD+BRH9F5gASHaceio nTyKP/Oik1q0aGEjx7S5hzUtvmLl1HoV93wcbfSnkptwN1tBOqPnhhtVgZmwDiFsHQP8 W3qw4R7Ru/SCMGsK24fjciBMdt9KEuPe2R/zhZOaL8l7TawwoksWVL+VS6D3x6cPZf90 kn/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=zMjslepzakTLo3e6QKPDkzI3w1kDi1qg8wBr+Kn9rJk=; b=b46ADNnkJmu4tpmEbJxpRTCMGv0VxuIxQaeF4yIUHQpQEbPrtQKMK9SpQxRfhy6TW0 oY5F1qDhuxJMVORSq8vvqXCtPLbZTvcg4OS9Nho2DMOYBT9N4G9P82SOqtUXr32e6xgg jaLC0g1gawiVCvoWuB0rnJVSntTLI3Mp2XLrRWLSetF2km5uRe2xsRdzV4KVmppS6XOi cZzQLqA0ERIYgzIKWQvTzRqNKNec6/DSGoC1NaO4BQufw6qPeK94icSA6LmYdPeoCywJ xjoktmaRJnNzQN+44UlLZPk5IyiG0Kjn2uA3PaWHQDSYT7r4jKJRdS2E4tcU7K4XrN7g TtRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=OycQHvQx; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a34-v6si19802558pld.149.2018.10.08.18.07.52; Mon, 08 Oct 2018 18:08:08 -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; dkim=pass header.i=@chromium.org header.s=google header.b=OycQHvQx; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726741AbeJIIVj (ORCPT + 99 others); Tue, 9 Oct 2018 04:21:39 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:35218 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725898AbeJIIVj (ORCPT ); Tue, 9 Oct 2018 04:21:39 -0400 Received: by mail-pf1-f194.google.com with SMTP id l17-v6so4788394pff.2 for ; Mon, 08 Oct 2018 18:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zMjslepzakTLo3e6QKPDkzI3w1kDi1qg8wBr+Kn9rJk=; b=OycQHvQxh7F6wT1ZKUL+PBdNqQZjRdIIGaCndb78uyL53gludte9HqEvsAs/OxTw0P okqlouidCri/pJ4QzpyfKXj4p9Vv38oUaHfcJOVhOoiN0omRT1hh/0IwTvnTBjawF3Gv pn9VdI5VjSZ3jIM4D7PqdbITptlbSvb19dY1U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zMjslepzakTLo3e6QKPDkzI3w1kDi1qg8wBr+Kn9rJk=; b=Jk6RjY8pcyM5ze3Jr804mz21RbTWqWcLxVFCHnRi/O6SvlfvWDEPQIzMMLim1OgbbB KHbtCIX3st2T13OS3cWaqhWATpTrC0xX8oOKHK854Jk9/xyyHJXoelituOZnbSXOica0 zE7RtOeVUmOxoZhf0W19EjrKocp3z1n1l5N6KNodJ4s5Pasi+x4RQvOlo0gPdoCTkmls c3N/uN7vzW85XF1L6GYhDPUjagJ9TPGNddFUoWx0bAc2TjGouoAcgkKo/T9KJUaw1TcR angUCDl8vMiTYkVrVNBtwZY9WdwODVynwlamKnRJ4G0OZCnlchD6nRmWhYhioP0V56AU 8knA== X-Gm-Message-State: ABuFfoiKsN1wyXjw+Hq/SsC8O04O0fuCzNxFzUEADPt2tWvDTstqPG/o x8orYSGEqdVl4HXqJxNjM2Megg== X-Received: by 2002:a63:6d83:: with SMTP id i125-v6mr22741818pgc.215.1539047236053; Mon, 08 Oct 2018 18:07:16 -0700 (PDT) Received: from ban.mtv.corp.google.com ([2620:15c:202:1:299d:6b87:5478:d28a]) by smtp.gmail.com with ESMTPSA id h88-v6sm43113399pfa.184.2018.10.08.18.07.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Oct 2018 18:07:15 -0700 (PDT) Date: Mon, 8 Oct 2018 18:07:13 -0700 From: Brian Norris To: Matthias Kaehlcke Cc: Rob Herring , Mark Rutland , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, linux-spi@vger.kernel.org, netdev@vger.kernel.org, Stephen Boyd , Florian Fainelli Subject: Re: [PATCH] dt-bindings: Add bindings for aliases node Message-ID: <20181009010711.GA1577@ban.mtv.corp.google.com> References: <20180925210255.172734-1-mka@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180925210255.172734-1-mka@chromium.org> User-Agent: Mutt/1.10.1+48 (1f3a9df87d11) (2018-07-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org + linux-spi, linux-wireless, netdev + others from previous conversations Hi, On Tue, Sep 25, 2018 at 02:02:55PM -0700, Matthias Kaehlcke wrote: > Add a global binding for the 'aliases' node. This includes an initial list > of standardized alias names for some hardware components that are commonly > found in 'aliases'. > > Signed-off-by: Matthias Kaehlcke > --- > Documentation/devicetree/bindings/aliases.txt | 47 +++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 Documentation/devicetree/bindings/aliases.txt > > diff --git a/Documentation/devicetree/bindings/aliases.txt b/Documentation/devicetree/bindings/aliases.txt > new file mode 100644 > index 000000000000..d64ed1c7eb34 > --- /dev/null > +++ b/Documentation/devicetree/bindings/aliases.txt > @@ -0,0 +1,47 @@ > +The aliases node > +---------------- I like the idea in general, and it might be good to note (e.g., commit message) that this was inspired by this thread: https://lore.kernel.org/lkml/20180815221601.GB24830@rob-hp-laptop/ where we were interested in firmware-to-device-tree path stability -- and the answer was basically: don't memorize paths, just use aliases instead. But then, it was clear that aliases were not documented very formally at all. So here we are! > + > +The aliases node contains properties that represent aliases to device tree > +nodes. The name of the property is the alias name, the value is the path of > +a the device tree node that corresponds to the alias. The path may be > +specified as a string or a phandle. > + > +Alias names are often suffixed with a numeric ID, especially when there may > +be multiple instances of the same type. The ID typically corresponds to the > +hardware layout, it may also be used by drivers for a stable mapping of > +device names and hardware entities. > + > +Alias names > +----------- > + > +The devicetree specification doesn't require the use of specific alias > +names to refer to hardware entities of a given type, however the Linux > +kernel aims for a certain level of consistency. > + > +The following standardized alias names shall be used for their > +corresponding hardware components: > + > + bluetoothN Bluetooth controller > + ethernetN Ethernet interface > + gpioN GPIO controller > + i2cN i2c bus > + mmcN MMC bus > + rtcN Real time clock > + serialN UART port > + spiN SPI bus > + wifiN Wireless network interface For the network-device-related names (bluetooth, ethernet, and wifi), I think there's a clear documented reason for this (supporting MAC address plumbing from a DT-aware bootloader). I'm not quite as sure about all the others, and unfortunately, I'm aware of at least one subsystem owner that explicitly does NOT like the aliases usage that is currently supported (spi), and shot down a patch where I tried to use it in a DTS file (despite its regular usage in many other DTS files). So I guess I'm saying: perhaps we should get buy-in from various subsystems before we include them? So maybe it's wiser to start small(er) and only add once we're sure they are useful? Or perhaps Rob has other thoughts. > + > +The above list is not exhaustive and will be extended over time. Please > +send patches to devicetree@vger.kernel.org if you think a hardware > +component and its alias name should be on the list. > + > +Example > +------- > + > +aliases { > + bluetooth0 = "/soc/serial@fdf01000/bluetooth"; > + rtc0 = &rtc0; > + wifi0 = &wlcore; > +}; > + > +(based on arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts) What is the relevance of this line? This doesn't look anything like that hikey DTS. Maybe the "based on" line should just be removed? The example seems fine though. Anyway, perhaps with a trimmed list of supported alias names: Reviewed-by: Brian Norris