Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2862473rwd; Fri, 26 May 2023 12:24:25 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ59INGTopxGLum32Bdmk6Sn0/BZUf2vEaFA+cRFwLAWghnkcSYQH6JotTaGQP4QA8aun6L3 X-Received: by 2002:a05:6a00:2284:b0:64d:1333:6f3d with SMTP id f4-20020a056a00228400b0064d13336f3dmr4785819pfe.10.1685129064833; Fri, 26 May 2023 12:24:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685129064; cv=none; d=google.com; s=arc-20160816; b=zCKZpA7+rp5oHyBG9ygDXda559amm6xopyAqVy8r+MlCoAybDpZFxXpJoKUm7GFEIg WpSqJ7Np5Bzbq3t+rTM/buNPF+wPIXMH/TXJNc/+8Q+ChCcI5aZChsF3evLqqfmC1G2u jypQj0OlLBK9VxRl8mqHGhW6gS/GQRcoKrBbluB8CMG2RpqfX/yJT/lpkmQAan33Mywc 0n1za4cqkoEguP9Q0/QF2QJ9RD2O1rVncZyF7NE9maGj5xVHh1WTGMQNrTZ9GOIJvu57 b43Vw5NLSBuv1qW8RAbpU377165TqWE5v6MshL2Y3VFJP6EQ5gT4xBYEXHtU6tCiHTuz x2jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Tff6CjaDmwLmNpqENs6Nd6VkENM9TNn8VBbur/5u91o=; b=lDg0pYqyeki57lULLa9uEKTnjJUtqvs+iX5Elp5fX+G423o2s+Y3ybeOEHRnsGrvcu 6zlKZ6dKqoZr9v++fjX5Cs7BYxa/1OIOrloy3AP+uS7/Uh4FVzIKeHCU5AX0Qh+Ei9UB DYau11UuTJ9obQMPSemFLyNp99HE/Ip/O0Ak03N8wADi71LM4aLhtKQBnrf/Sr2JWW0/ Fiz/lZ5QNK8pdUKa882GphHVQJ/QZRpzKGVUsuqgwQ6NSJr5VRd8Jc0EDySEAaqYHDlR ER6GKqxaCEVHx/DFxzoUpBTnedlOAviviwx5JW/t+HfSiyjh/y3km0UiWWqKCfZA+mNf NzNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y186-20020a6264c3000000b00637745fdf99si2543945pfb.370.2023.05.26.12.24.10; Fri, 26 May 2023 12:24:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236735AbjEZTNO (ORCPT + 99 others); Fri, 26 May 2023 15:13:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230298AbjEZTNN (ORCPT ); Fri, 26 May 2023 15:13:13 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id AB89F13D for ; Fri, 26 May 2023 12:13:10 -0700 (PDT) Received: (qmail 301648 invoked by uid 1000); 26 May 2023 15:13:09 -0400 Date: Fri, 26 May 2023 15:13:09 -0400 From: Alan Stern To: Roy Luo Cc: Greg Kroah-Hartman , raychi@google.com, badhri@google.com, Benjamin Tissoires , Michael Grzeschik , Bastien Nocera , Mathias Nyman , Matthias Kaehlcke , Flavio Suligoi , Douglas Anderson , Christophe JAILLET , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCH v1] usb: core: add sysfs entry for usb device state Message-ID: References: <20230525173818.219633-1-royluo@google.com> <2023052600-survey-fondness-27ce@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 26, 2023 at 11:34:44AM -0700, Roy Luo wrote: > On Thu, May 25, 2023 at 5:50 PM Alan Stern wrote: > > > > On Thu, May 25, 2023 at 01:31:17PM -0700, Roy Luo wrote: > > > Currently the usb core assumes the usb_device that port_dev->child points > > > to is enumerated and port_dev->child->dev is registered when > > > port_dev->child is present. Setting port_dev->child early would break this > > > fundamental assumption, hence I'm a bit reluctant to go this way. > > > > Well, you could remove that assumption by adding a "child_is_registered" > > flag and explicitly checking it. > > > > Alan Stern > > Agree that's doable, with the following overheads: > 1. We can no longer safely access port_dev->child without checking > "child_is_registered", and there are plenty of places in the usb core that > touch port_dev->child. The implicit assumption could also hurt code > maintainability. That doesn't sound like a big deal. Currently you can't safely access port_dev->child without checking whether it is non-NULL. You would just have to replace one check with another. The fact that plenty of places touch port_dev->child indicates someone must have given some thought to protection against racing accesses. Your modifications should be able to benefit from that thought. > 2. In the worst case where enumeration keeps failing, the retry loop in > hub_port_connect() would frequently hold device_state_lock in order > to link/unlink the usb_device to port_dev->child. > This would definitely make sense if more places need port_dev->child early. > However, we only need port_dev->child->state at this point, so it does not > seem like a good deal to me. Another alternative -- possibly a much simpler one -- is to replicate port_dev->child->state in port_dev->state, purely for use by the new sysfs routine. In other words, keep the actual value there instead of a pointer to some other location that might get deallocated at any time. Since presumably you don't care about precise synchronization (that is, it doesn't matter if the value shown in the sysfs file is a few tens of milliseconds out of date) you could do this without extra locking. Just use WRITE_ONCE() for updates and READ_ONCE() to see what the current value is. Alan Stern