From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 32FC3322DD1; Wed, 26 Nov 2025 11:44:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764157474; cv=none; b=gI23Mnrn6la7Z0JB4yU1SQtnD1ROUuxpshOKyX5cHq9uGqAwpWk0mJRWFkYz8bsJWLjy3Vr1QIE3zIvcrprkO+lChGoh8WG3yUQr+PK5EVqqQrC2xihcF5hyGIvbxELNjfkNWK10X5gjJl96Fp5WT0pVhe8YoFekIs+FVFA1M9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764157474; c=relaxed/simple; bh=dQ3LNp2DPvCHpByC5YJ/LPjNqcR3n3ZIP831X7vWn8k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rFEnW7EFNmol8flc0ZVbBLKvlhNR/ms8kaOslQANI8YHQ0IiGkqtJIZ+3jBWodTwG/DSpazURaRdIgWrkzcdV6BOnvAIIfHlSgB36dhCsqzhSIAPg/glQqWNXoskJ5+xttJUXBkeXW43+jJO4aUzAknVr0Wf08dH3CUm63yg2Bs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=EX6HFDp6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="EX6HFDp6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C877C113D0; Wed, 26 Nov 2025 11:44:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1764157473; bh=dQ3LNp2DPvCHpByC5YJ/LPjNqcR3n3ZIP831X7vWn8k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EX6HFDp6M+6sFCHy11l719FEszcZCnX/arPyanWY59AmUz7HdftavnC1U4UCkzvV0 uMiLKf9hkOEIYyVgWL4ByFWeBVROb9xMXOMOAFmxeygWsa7rhDrNnpXdbZ/kbBuZPA mFQJCkSC9jrSiqVsHgOTzV+V4tdIrre3rw2MorAU= Date: Wed, 26 Nov 2025 12:44:17 +0100 From: Greg Kroah-Hartman To: Heikki Krogerus Cc: Chaoyi Chen , Chaoyi Chen , Dmitry Baryshkov , Peter Chen , Luca Ceresoli , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Vinod Koul , Kishon Vijay Abraham I , Heiko Stuebner , Sandy Huang , Andy Yan , Yubing Zhang , Frank Wang , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Amit Sunil Dhamne , Dragan Simic , Johan Jonker , Diederik de Haas , Peter Robinson , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v10 01/11] usb: typec: Add notifier functions Message-ID: <2025112656-dreamland-retreat-2a65@gregkh> References: <2025112102-laurel-mulch-58e4@gregkh> <462ad1bd-7eec-4f26-b383-96b049e14559@rock-chips.com> <2025112402-unopposed-polio-e6e9@gregkh> <2025112448-brush-porcupine-c851@gregkh> <2025112554-uncaring-curator-642a@gregkh> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Nov 26, 2025 at 11:42:43AM +0200, Heikki Krogerus wrote: > Wed, Nov 26, 2025 at 09:46:19AM +0800, Chaoyi Chen kirjoitti: > > On 11/25/2025 7:49 PM, Greg Kroah-Hartman wrote: > > >> +static umode_t typec_is_visible(struct kobject *kobj, struct attribute *attr, int n) > > >> +{ > > >> + if (is_typec_port(kobj_to_dev(kobj)->parent)) > > > > > > Why look at the parent? Doesn't the device have a type that should show > > > this? > > > > > > Otherwise, looks good to me. > > > > They have same deivce type "typec_altmode_dev_type". > > The parent device has a different device type to distinguish between > > port device and partner device. > > I was already wondering would it make sense to provide separate device > types for the port, and also plug, alternate modes, but I'm not sure > if that's the right thing to do. > > There is a plan to register an "altmode" also for the USB4 mode, > which of course is not an alternate mode. So USB4 will definitely need a > separate device type. > > So if we supply separate device types for the port, plug and partner > alternate modes, we need to supply separate device types for port, plug > and partner USB4 mode as well. > > We certainly can still do that, but I'm just not sure if it makes > sense? > > I'll prepare a new version for this and include a separate patch where > instead of defining separate device types for the port and plug > alternate modes I'll just supply helpers is_port_alternate_mode() and > is_plug_alternate_mode(). That feels like it would be better in the long run as it would be easier to "match" on the device type. thanks, greg k-h