Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp2724318rwo; Sun, 23 Jul 2023 23:29:50 -0700 (PDT) X-Google-Smtp-Source: APBJJlEsLjRQK3cFzhW4tJq77K2DfZWilLhlpSegqm3Zrgcf9YVq8O+1XSVoqCHXBijieOnldw7K X-Received: by 2002:a05:6512:3d21:b0:4fd:cb0a:18de with SMTP id d33-20020a0565123d2100b004fdcb0a18demr5779715lfv.67.1690180190501; Sun, 23 Jul 2023 23:29:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690180190; cv=none; d=google.com; s=arc-20160816; b=yp3nQHEK3t3lVD0FGic87gtHjyllH+xwc/CxOaWaGApAkeony8retFd0PQ+4alHEWa PTcXAMelfrEURLmlFmqPy6xfH/ZCZBZebR9hjGTcZQu75h0Wx3pBg8lLoOh9DoV2QNKK 6gPAFetx/Y8G5z81ZP2+bm6qHANqkCG8XIq5H1o6MYnKQiQzPxD+1RYqDXnamsZ6FKet uzs1U+XwBwDzmwsJzVG/UMbBKEUKX4PDg0ra8+e49jNZfukNDRlQTyU3BE27VzUBjjBk TF6E9E/LPw3i8z+eBa6qR5jIA5qIZ9d0ieclicSacuIrKTppMzl/fDOhkuocMGQ43Vke L9Nw== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=arTrPiaG0jZrCNot5jcVI4xV+ClNT+Ud0u9bvBY67jk=; fh=kSE8LnZTTjUKMkVXT6bfB/bdAcUEuBEJBjhAJ5J0B9E=; b=EfDnw/LdKGqMZ57LKiIXH/+hdkY/hu69h2H9tMWn4/5Gtw1Spe4fQb9iQ44jiuswr3 3u/hfwP5xigeC3iJaN1p2GgZUkqJU2tlkvxTeuevq076+H69jzAfu6gWad1CARlmB9jd PKQaJv1hLI/Xo2wWFlxhAD/ZxMLtwXZQR0OM4avyg543D/7urJJt9becmD1CPug0w9a+ uTv98JhguV+2GS3Dst/tIcKpUQWLF9d+GMzKOgQ1wk+8PsfDa63hDIMxBTpQLxfgY5f4 G1CqV6fzOIN1EQxpfbcsWnKZqDFlMBqDPn61OEGKe3MbMC8SG7I0jwMBriL+kppo8eeF 61yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=BmwbpFPG; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s9-20020a056402164900b005223842d65fsi415504edx.222.2023.07.23.23.29.25; Sun, 23 Jul 2023 23:29:50 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=BmwbpFPG; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230073AbjGXFuP (ORCPT + 99 others); Mon, 24 Jul 2023 01:50:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229898AbjGXFuO (ORCPT ); Mon, 24 Jul 2023 01:50:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50D57180; Sun, 23 Jul 2023 22:50:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E12D760F24; Mon, 24 Jul 2023 05:50:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BFDF1C433C7; Mon, 24 Jul 2023 05:50:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1690177812; bh=bFLNepPhPHCswQ9ft0pcj3E1XJXFCkjGVMeXp3+zrvY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BmwbpFPGParIZG7W1TUUE0yYYPD2FBLWu3ib2mFJqFva1McRElxdJv4LGNGcZf3/+ YhS0qaQ3Fk7I10AJK0ox0MKRkUYab2sdAGsLZ4zyDj+YFl8VsUHszf1jnmGx1XBavt sL38/5lGbOXFVPHwuCIXa5zjFasgyrfUcpH4iNco= Date: Mon, 24 Jul 2023 07:50:09 +0200 From: Greg Kroah-Hartman To: Stanley Chang Cc: Vinod Koul , Kishon Vijay Abraham I , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Alan Stern , Roy Luo , Matthias Kaehlcke , Douglas Anderson , Flavio Suligoi , Ray Chi , linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v7 1/5] usb: phy: add usb phy notify port status API Message-ID: <2023072452-jasmine-palm-7b73@gregkh> References: <20230707064725.25291-1-stanley_chang@realtek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230707064725.25291-1-stanley_chang@realtek.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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, Jul 07, 2023 at 02:47:00PM +0800, Stanley Chang wrote: > In Realtek SoC, the parameter of usb phy is designed to can dynamic > tuning base on port status. Therefore, add a notify callback of phy > driver when usb port status change. > > The Realtek phy driver is designed to dynamically adjust disconnection > level and calibrate phy parameters. When the device connected bit changes > and when the disconnected bit changes, do port status change notification: > > Check if portstatus is USB_PORT_STAT_CONNECTION and portchange is > USB_PORT_STAT_C_CONNECTION. > 1. The device is connected, the driver lowers the disconnection level and > calibrates the phy parameters. > 2. The device disconnects, the driver increases the disconnect level and > calibrates the phy parameters. > > When controller to notify connect that device is already ready. If we > adjust the disconnection level in notify_connect, the disconnect may have > been triggered at this stage. So we need to change that as early as > possible. Therefore, we add an api to notify phy the port status changes. How do you know that the disconnect will not have already been triggered at this point, when the status changes? > > Signed-off-by: Stanley Chang > --- > v6 to v7 change: > No change > v5 to v6 change: > No change > v4 to v5 change: > No change > v3 to v4 change: > Fix the warning for checkpatch with strict. > v2 to v3 change: > Add more comments about the reason for adding this api > v1 to v2 change: > No change > --- > drivers/usb/core/hub.c | 13 +++++++++++++ > include/linux/usb/phy.h | 13 +++++++++++++ > 2 files changed, 26 insertions(+) > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index a739403a9e45..8433ff89dea6 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -614,6 +614,19 @@ static int hub_ext_port_status(struct usb_hub *hub, int port1, int type, > ret = 0; > } > mutex_unlock(&hub->status_mutex); > + > + if (!ret) { > + struct usb_device *hdev = hub->hdev; > + > + if (hdev && !hdev->parent) { Why the check for no parent? Please document that here in a comment. > + struct usb_hcd *hcd = bus_to_hcd(hdev->bus); > + > + if (hcd->usb_phy) > + usb_phy_notify_port_status(hcd->usb_phy, > + port1 - 1, *status, *change); > + } > + } > + This is safe to notify with the hub mutex unlocked? Again, a comment would be helpful to future people explaining why that is so. thanks, greg k-h