Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1968967ybl; Thu, 30 Jan 2020 09:08:10 -0800 (PST) X-Google-Smtp-Source: APXvYqw/wD0tJcbrjSNG8aDWtWZeC0AckjzZaXjYdoaEqatmH1YrK4vMn+KwrToXEWIHtvIyIGV3 X-Received: by 2002:a9d:6f0a:: with SMTP id n10mr4522845otq.54.1580404090578; Thu, 30 Jan 2020 09:08:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580404090; cv=none; d=google.com; s=arc-20160816; b=FhRF7snZfnJrZSV427EnXwJ7ltA0IPe90BUyGVJ21Xk6akUNaE223JJBednwFzXVHv rPc+r2SdthzyWZHov5jeYoI6nz4t2kkFV+x5GA6fGWWzuA9CWY09f0xSKMVXk2X3wgEs cUlhNcVs2xxt4NolApDvIiMPqRcsrZopLe11mwLp3GATVjusW8kD5KUqZ79Dc6ZdIEhs EDY4mL0ozNbgRxtOqkTEwh73+DpgnE4KSZ0oIcyMhomMocD6QkZt+s9TTrB8sVJOhNax 3tbItnN7sRuYRqBeWtiTqdVtd7nyuLttYyEG5Zor/MluilGItk38pi/rKmTNXI8CHs62 HBbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=P48/j6OovYg0vHXL5ly/6KR+04ndq8pUGCQSlj9lCpk=; b=fNvQ73I9UkFSB+odx5gNZRrpHh1zX0MnTV7nsrrBWm2ReupeBW5rAO3b8BRVHM0dv2 fQBWfn2qE9AkMah86V6qyulQXYB/1/tlbGmfFo/pjCktL8Ew+UtNBTj55f8uywW2HucL j4iGsD0EitCX7FlGtKQZnWJPDXudKmHARBBhrn2+UQIa0S1WVahcnIRp7TobfeCBGWw3 ilm+hqo9mvIZWT1vdQlRy8oS1vh9R4a5KSsi6LTRAihhB/+VMPjIAoq+OtJZNhTcPTm9 VL6a7Pmr0SF87uYkPiVwSow6gCRnvZDWgcqxl1EtbTgg6++jF2DW3ewloKOo2gvEWcPz pd1w== 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 z73si3120241oia.40.2020.01.30.09.07.56; Thu, 30 Jan 2020 09:08:10 -0800 (PST) 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 S1727445AbgA3RGc convert rfc822-to-8bit (ORCPT + 99 others); Thu, 30 Jan 2020 12:06:32 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:59262 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727158AbgA3RGb (ORCPT ); Thu, 30 Jan 2020 12:06:31 -0500 Received: by unicorn.mansr.com (Postfix, from userid 51770) id 7B0BB1B0DC; Thu, 30 Jan 2020 17:06:29 +0000 (GMT) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Rob Herring Cc: Greg Kroah-Hartman , Mark Rutland , Linux USB List , devicetree@vger.kernel.org, "linux-kernel\@vger.kernel.org" Subject: Re: [RESEND][PATCH 1/2] dt-bindings: usb: add non-removable-ports hub property References: <20200124152504.23411-1-mans@mansr.com> <20200127153506.GA4589@bogus> <20200128134745.GA3048749@kroah.com> <20200128152818.GB3437093@kroah.com> <20200128165243.GC3666045@kroah.com> Date: Thu, 30 Jan 2020 17:06:29 +0000 In-Reply-To: (Rob Herring's message of "Tue, 28 Jan 2020 12:21:32 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rob Herring writes: > n Tue, Jan 28, 2020 at 10:52 AM Greg Kroah-Hartman > wrote: >> >> On Tue, Jan 28, 2020 at 04:28:18PM +0100, Greg Kroah-Hartman wrote: >> > On Tue, Jan 28, 2020 at 03:15:11PM +0000, M?ns Rullg?rd wrote: >> > > Greg Kroah-Hartman writes: >> > > >> > > > On Mon, Jan 27, 2020 at 04:56:15PM +0000, M?ns Rullg?rd wrote: >> > > >> Rob Herring writes: >> > > >> >> > > >> > On Fri, Jan 24, 2020 at 03:25:03PM +0000, Mans Rullgard wrote: >> > > >> >> Add a non-removable-ports property that lists the hardwired downstream >> > > >> >> ports of a hub. Although hubs can provide this information, they are >> > > >> >> not always configured correctly. An alternate means of indicating this >> > > >> >> for built-in USB devices is thus useful. >> > > >> >> >> > > >> >> Signed-off-by: Mans Rullgard >> > > >> > >> > > >> > I reviewed this already, but since you didn't add my reviewed-by, I'm >> > > >> > looking at it again and having 2nd thoughts. >> > > >> > >> > > >> >> --- >> > > >> >> Documentation/devicetree/bindings/usb/usb-device.txt | 4 ++++ >> > > >> >> 1 file changed, 4 insertions(+) >> > > >> >> >> > > >> >> diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt >> > > >> >> index 036be172b1ae..92d863cc96b6 100644 >> > > >> >> --- a/Documentation/devicetree/bindings/usb/usb-device.txt >> > > >> >> +++ b/Documentation/devicetree/bindings/usb/usb-device.txt >> > > >> >> @@ -66,6 +66,10 @@ Required properties for host-controller nodes with device nodes: >> > > >> >> - #size-cells: shall be 0 >> > > >> >> >> > > >> >> >> > > >> >> +Optional properties for hub and host-controller nodes: >> > > >> >> +- non-removable-ports: list of hardwired downstream ports >> > > >> > >> > > >> > If you have a hardwired device and need to know that, doesn't that imply >> > > >> > there's some other stuff you need to describe beyond what a standard USB >> > > >> > device has. Such as a power supply that's not Vbus from the hub. >> > > >> >> > > >> I suppose there could be, but there isn't in my actual situation. >> > > >> >> > > >> > At a minimum, I think this should be a per port property. >> > > >> >> > > >> That's what I suggested first. Greg told me to do it like this instead. >> > > > >> > > > I said that? I do not remember discussing this at all, when did that >> > > > happen? >> > > >> > > https://lore.kernel.org/lkml/20190228155241.GC12050@kroah.com/ >> > >> > Almost a full year ago! Hah, I can't remember what I wrote last week. >> >> Ah, ok, all I said was "do what ACPI does here", as that's a model of >> what has already been agreed apon by a whole huge number of people and >> standardized. No need for DT to come up with something totally >> different instead, making a mess of things :) >> >> If this is doing what ACPI does, fine, if not, it should. It was here >> first. > > That's not always possible as ACPI and DT work in different ways. The > DT (Open Firmware) USB binding originated in 1998[1]. While ancient, > that is what defines the node structure of USB hubs, ports, and > devices that we use today. > > However, after a quick read of ACPI sec 9.14, I'd say what I suggested > is more aligned to ACPI than what's proposed here. Ports are child > nodes ("Device" in ACPI terms) and the properties to determine all > this are properties of the port node(s). Aligning beyond that isn't > really possible. ACPI has a standard thing (not sure what the proper > term is) called '_PLD' for describing device location which includes > 'user visible' among several other things. There is no such concept in > DT to align with. What we have is the 'non-removable' property and IMO > that's what we should use here. Can you guys please agree on something or other. I'm happy to do it whichever way you decide, but I'd rather not waste my time making patches that will just get rejected. -- M?ns Rullg?rd