From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 727BF32142B; Wed, 26 Nov 2025 09:43:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764150198; cv=none; b=Nwug6MAt5P7ThDVXqvEnT/KSzeLgwWGlfCTiR8LqMHPDFIFOddg2JL4XqMNzmXJ8YuHM7qBriWJf0msAri6+UGX7gpYnanp0jJZI7cPGpm1GY2v2/3LtZ3zCiJdZelsE+SV9ucB5Cubr/Igz1h9lw/i63sb/YFLHr+8bR1UWvx0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764150198; c=relaxed/simple; bh=CCg+lZSEq+WcXEQmJQne7xQ4oE1yxypysTDuDghy64Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U7Dfc55aFpvp0DfJ0Zh6bjLMkICoR7AaNh1j3uWwreqChcuULvo6i7MDC48VK0PpRiMsv7rnQ0WtJ4Jo5Lm38vqL6jBqeJ4W/RWw9N3zRQrU+Hdtf/RMh2QtGKGJ6gntHkdWfBTCXgQ/BWiOdXDDW1ALAE5w8hWeOSbx8laMcNI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WoXWk7AW; arc=none smtp.client-ip=192.198.163.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WoXWk7AW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764150197; x=1795686197; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=CCg+lZSEq+WcXEQmJQne7xQ4oE1yxypysTDuDghy64Q=; b=WoXWk7AWy9cksdbhge4h9b1xR7phsEkvAvaJLcfw6JLNGpAthe8mgVfY 5Kk30lzPdLRrbT1GDsTRHOZAUm6tAeuo34Thev2jme/iD2P533sKk0Ink yqFCHW10V8wLitUfrlrhUX5gJB23Ph8PgW/EzWfOGMTAACLxnehmxiNPU EGpWoeyXp3e/TIl13N/zDmq72Nu5DKznGAkpGeuB94qXxKB+ZrEixSoCK hCilJX93uhi9XNCBPQftkjrVOBis9/eD2byjIOK3R/gb3dlCVZOxXUkTy H3sB9jpX2TxvFO5PzMd1N8POruaUKBKbNmCjd4Rg/yNabLPJq6dvl0ZFk w==; X-CSE-ConnectionGUID: aW8A2IbyTOW9rjSpGGbZcw== X-CSE-MsgGUID: ZY42antbTpeOMRMZMOlLXA== X-IronPort-AV: E=McAfee;i="6800,10657,11624"; a="65371587" X-IronPort-AV: E=Sophos;i="6.20,228,1758610800"; d="scan'208";a="65371587" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2025 01:43:14 -0800 X-CSE-ConnectionGUID: B+T8YiSeRD+/P6Odm3S47w== X-CSE-MsgGUID: B/YD/UVbQWaORjBCGIUAVA== X-ExtLoop1: 1 Received: from iherna2-mobl4.amr.corp.intel.com (HELO kuha) ([10.124.223.25]) by fmviesa003.fm.intel.com with SMTP; 26 Nov 2025 01:42:55 -0800 Received: by kuha (sSMTP sendmail emulation); Wed, 26 Nov 2025 11:42:43 +0200 Date: Wed, 26 Nov 2025 11:42:43 +0200 From: Heikki Krogerus To: Chaoyi Chen Cc: Greg Kroah-Hartman , 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: References: <20251120022343.250-2-kernel@airkyi.com> <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: 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(). thanks, -- heikki