Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp494136pxb; Wed, 6 Oct 2021 09:13:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyNYV+XmJaaW+ZqCuUOov4/CVJK0RwcqJq37dCARQFRIUGbDULrwlcMU/NGFiNe3V7djy6R X-Received: by 2002:a17:902:8b8b:b0:13d:e91c:a1b9 with SMTP id ay11-20020a1709028b8b00b0013de91ca1b9mr11876882plb.60.1633536799128; Wed, 06 Oct 2021 09:13:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633536799; cv=none; d=google.com; s=arc-20160816; b=q3vTjjBWlsbGvpIm77l72mRDr7vZUiOk1mmEbIB6i8fNkrPTmUIx/MOiLuBn2xXK3C wrXxqBvJLvgXfh81AW4N3WgmCx6BLYvYrM9Rs5gJTtJqUQCLc+qcNN6PKRu+pPuggNv1 GA4q5m9krPtNxdYJdGDtjB9ONK19aChUWPXr0NBc/eSunrnSl1CYXubm+H9/8ZpdAZnh TBHKfAyFKSVTA+PbZX8nPxd53a1vw402TQR/flv8jm0bH8gWWB9418aS5fhNWmMZdZSX hwSSp+umU68BtmS+2BHOAqwOFLinRIUOqtplHErWmu1yCOHQewvKqjihhUf/R8YpdW+Y GQhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=PP/5SmxD0EwdnZNZ7subNT4aG4nvrI5DeMBQAVgu/v4=; b=ykgQJnNpW7rmm4qportl37NbKTU84suehrAsS44jkoAzCGs5PxtFaOGIyqtZdgtppO 6WhBxECrFW4c1aS8XW9LNmzH3M0+I4ZCBxLDxjDLUKLNaOQLT7sI16YzCgMPkswxIHki /idUOrdaep3xzC2KBEuGGmHGlrnH3b48kw5/DF3HkjDPfXDcy1z4CgmTG+O36Rxdx1qR FZgVLxlqGbLw4HEq45vqJLCGUQTnnGVYY8jOLoP0RtK+VLeShhc/HC9lB3DuxW6vCbis XtIQPqA4xZ2zdH/V/6J6a6Ou7H1pbNnMDHQqBLy7L/Q/MeDp7tDcnVTP6UyOmzULOxx9 QQhg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n2si26069843pgb.393.2021.10.06.09.13.02; Wed, 06 Oct 2021 09:13:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239309AbhJFQMv (ORCPT + 99 others); Wed, 6 Oct 2021 12:12:51 -0400 Received: from netrider.rowland.org ([192.131.102.5]:57179 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S230021AbhJFQMv (ORCPT ); Wed, 6 Oct 2021 12:12:51 -0400 Received: (qmail 661013 invoked by uid 1000); 6 Oct 2021 12:10:58 -0400 Date: Wed, 6 Oct 2021 12:10:58 -0400 From: Alan Stern To: Oliver Neukum Cc: Dmitry Torokhov , Rajat Jain , Greg Kroah-Hartman , Thinh Nguyen , Mathias Nyman , Andrew Lunn , Chris Chiu , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, levinale@google.com, bleung@google.com, rajatxjain@gmail.com, jsbarnes@google.com, pmalani@google.com Subject: Re: [PATCH 2/2] usb: hub: Mark devices downstream a removable hub, as removable Message-ID: <20211006161058.GB659483@rowland.harvard.edu> References: <20210929224823.556943-1-rajatja@google.com> <20210929224823.556943-2-rajatja@google.com> <20211005145655.GJ621017@rowland.harvard.edu> <20211005195929.GA634685@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 06, 2021 at 11:37:58AM +0200, Oliver Neukum wrote: > > On 05.10.21 21:59, Alan Stern wrote: > > On Tue, Oct 05, 2021 at 09:51:02AM -0700, Dmitry Torokhov wrote: > >> Hi Alan, > >> > >> On Tue, Oct 5, 2021 at 7:56 AM Alan Stern wrote: > >>> As I understand it, the "removable" property refers specifically to > >>> the device's upstream link, not to whether _any_ of the links leading > >>> from the device to the computer could be removed. > >> No, that is not what it means. I'll cite our sysfs ABI: > >> > >> What: /sys/devices/.../removable > >> Date: May 2021 > >> Contact: Rajat Jain > >> Description: > >> Information about whether a given device can be removed from the > >> platform by the user. This is determined by its subsystem in a > >> bus / platform-specific way. This attribute is only present for > >> devices that can support determining such information: > >> > >> "removable": device can be removed from the platform by the user > >> "fixed": device is fixed to the platform / cannot be removed > >> by the user. > >> "unknown": The information is unavailable / cannot be deduced. > >> > >> Currently this is only supported by USB (which infers the > >> information from a combination of hub descriptor bits and > >> platform-specific data such as ACPI) and PCI (which gets this > >> from ACPI / device tree). > >> > >> It specifically talks about _platform_, not about properties of some > >> peripheral attached to a system. Note that the wording is very similar > >> to what we had for USB devices that originally implemented "removable" > >> attribute: > > In that case, shouldn't Rajat's patch change go into the driver core > > rather than the hub driver? _Every_ device downstream from a > > removable link should count as removable, yes? Not just the USB > > devices. > In theory yes. If your HC is removable by that logic every device is. > That renders the information content of 'removable' to zero. Everything > is removable. So we should add a new attribute. Call it "unpluggable", perhaps. It will say whether the device's immediate upstream link is hot-unpluggable. Then the device is removable if its parent is removable or if it is unpluggable. > > And to say that the attribute is supported only by USB and PCI is > > misleading, since it applies to every device downstream from a > > removable link. > Exactly and it is a difference. If you know that a device is removable > you must not disable hotplug detection on that port if you want full > functionality. While if you know that a device is not removable you may > straight up cut power, even if the _parent_ is still removable. > > The device tree is a tree and if you want to know whether hotplugging > is possible (let's ignore hibernation), you need to walk the tree top to > bottom. Adding the "unpluggable" attribute should take care of this, right? Alan Stern