Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp391644pxb; Thu, 21 Apr 2022 01:47:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkTPSZ/x+pfuDcu6GuOnHXsvWgzNdr5gx+Vk/KwicFVRqiwapoSrb5VQX8M8XxGJ/Q4P+n X-Received: by 2002:a05:6a00:2883:b0:509:322f:685f with SMTP id ch3-20020a056a00288300b00509322f685fmr27644163pfb.60.1650530866592; Thu, 21 Apr 2022 01:47:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650530866; cv=none; d=google.com; s=arc-20160816; b=hkqkyzmuM0CZHoC80ouVbjxFk/tNL/W8omlO9rK7rjQh8+zTFC45oisFiSTk8uv2px 9TTeR90VZC53/9wRkV8QUOFkLQP8DVoudfl03vv5qmztka4QNeb+0KB/iKheLY/UIau+ d4y9N4QXmAiHXH700qXC/pPZMsL9JnORAoekE1OJpPQMcIXzZby++J/RT9rk6XawrdcR NkEuO8CrcdRjakttxeJIVW5sgbOUaiM6Oo8FP80Ev12Cpuqn8VtMbPO/IqWVxi+DINWi gmnma46wwun+Y2cvHhCAWxt7XxS/PKIUgZ5IfXmAv8IYiQ9YuIa/WwWF6EP5qkAdaVXz 5qYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=BOf2hv92/jj7Pk4QQheaST/1j+rhxV6maBDm0OXMc0I=; b=sGrD59MaJm0vMl8kOPX+SvQqUQlXlS13gj7sTNddFgnA2XkCmG6VxyLHfYZ8BnYB9l F0KZmoEuN5JYJx9dq/SSAN9UVvHujCN7HXzd7LSI+9S69yswHLzR4llzIqOanw7pGIta 023q8U8rVuuwC9UYRXjpLqjgu+ykOYuTnPctR1PyNatHGRwmdyuDDbNExOEUsU35u6wi +SyrHlq+o4zbnmYmkhZ4feJdxO84RG4sGnJdP+f2Y+CCbc0vFgsi7lSGQxiBgPgC9iPq 9PLfYlPc/DnY/zyQIQNLFMIRMh3L28dCsrbnY7sSFwG+94YW5wkSlpuoAq3saiXt7kWk 6XAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W7etYtnL; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n6-20020a654cc6000000b003990deab146si4759000pgt.595.2022.04.21.01.47.32; Thu, 21 Apr 2022 01:47:46 -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=@intel.com header.s=Intel header.b=W7etYtnL; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377865AbiDTK6J (ORCPT + 99 others); Wed, 20 Apr 2022 06:58:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377857AbiDTK5d (ORCPT ); Wed, 20 Apr 2022 06:57:33 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AD021138 for ; Wed, 20 Apr 2022 03:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650452087; x=1681988087; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hyqDQuSmqIjjQPXkotxKrGwioZ0GHsZ6wRaW/+HeR68=; b=W7etYtnLqY8vbZ+/uQjBqCyi1v/wXIANYXAq8LWgKyknsqPZeB9Np4hf QBm/Yab+ueuzYlw8CP0mJ3g/RNwdnH452Uv67rI1+VQIZj1GXpUfWpYxO HAy38dEMXhjnMHCIW1b1Zb/5qoOqVTWKPnKjezzgU4n6dGHpJU72Qql7R LOdR3WKRN907R3Sdgor33GLz6bP75hIw0PC1YUaVh2oP8y1hUiq/RONxG W0AHfcvXy5GxcjCaj/gsiftGYFYZbz2APHV21/8B0zXqdzetf5NvsH7o3 aLQtVYLJTPbQxmpFKcu1mSLwsmICLfYoWQMuXeqiVx1vRLV9QCz70Ory7 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="324439207" X-IronPort-AV: E=Sophos;i="5.90,275,1643702400"; d="scan'208";a="324439207" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2022 03:54:47 -0700 X-IronPort-AV: E=Sophos;i="5.90,275,1643702400"; d="scan'208";a="510505952" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.162]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2022 03:54:43 -0700 Received: by lahna (sSMTP sendmail emulation); Wed, 20 Apr 2022 13:52:30 +0300 Date: Wed, 20 Apr 2022 13:52:30 +0300 From: Mika Westerberg To: Won Chung Cc: Heikki Krogerus , Alexander Usyskin , Benson Leung , Prashant Malani , Daniele Ceraolo Spurio , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] thunderbolt: Link USB4 ports to their USB Type-C connectors Message-ID: References: <20220418175932.1809770-1-wonchung@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220418175932.1809770-1-wonchung@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_NONE 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 Hi, On Mon, Apr 18, 2022 at 05:59:30PM +0000, Won Chung wrote: > Currently, USB port is linked to Type C connector, using the component > framework, if they share the same _PLD fields from ACPI table. Type C > port-mapper searches for devices with the same _PLD values, and > aggregate them as components. > > When there is another device that share the same _PLD but does not > registers a component, Type C connector (component master) would never > be bound due to a component match entry device without a component > registered. There exists some cases where USB4 port also shares the same > _PLD with USB port and Type C connector, so we need to register a > component for USB4 ports too, linking USB4 port with Type C connector. > Otherwise, link between USB port and Type C connector would not > work either. > > Due to the nature of the component framework, all registered components > are shared by all component match despite the relevance. MEI subsystems > also use the component framework to bind to i915 driver, which try to > match components registered by USB ports and USB4 ports. This can be > problematic since MEI assumes that there is a driver bound to the > component device, while USB4 port does not bind to any drivers. MEI's > component match callback functions should handle such case to avoid NULL > pointer dereference when USB4 port registers a component. > > In summary this patch series > 1. Fixes MEI subsystem's component match callbacks to handle a component > device without any driver bound > 2. Registers a component for USB4 ports to link them to Type C > connectors, similar to USB ports. > > Heikki Krogerus (1): > thunderbolt: Link USB4 ports to their USB Type-C connectors > > Won Chung (1): > misc/mei: Add NULL check to component match callback functions The Thunderbolt patch looks good to me. Do you want me to take the both patches through the Thunderbolt tree or they can go separately? I need an ack from the mei maintainer it goes through my tree.