Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2322145pxb; Fri, 8 Oct 2021 05:40:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1ASutxiy8wtzLkLAnKG3FbYCVlvUG0yAOFM++4ODC+DdMoBRiYtX9gYuNoGVD78xlq0q+ X-Received: by 2002:a17:906:bfe3:: with SMTP id vr3mr3883296ejb.339.1633696838551; Fri, 08 Oct 2021 05:40:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633696838; cv=none; d=google.com; s=arc-20160816; b=YsGy2AASFLwzNgymk6DuT5c5sWgXypNtAP0xNCjQvqhVxYqxnsq3ZWDGg5Gm+BzNZX NJPHJaGQqlxytM6JVi11ENZwMe4a+lppS8DWbOd3BpDlbxLziIElLfx+OuUsRvsfooEY SGFD6J7+/fy1WIIKNmXs9EOeJe9y0Tfu3e9IGIC7KiRWaiDbIUHcx7++mRna9cI8JdYg 1zgVzGAJIRNRRDcXuNQ8E4OKkcMghKndP3blEIx8tPfNBQgSuAsWDHIrPfb9IkTLYcHC X44F1PACWFQLzOcwoO+UoXVr9FURxndHq4vepmgFL8702qA5TQf+msjcpeg8JKBMmDkY w0ag== 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; bh=5zUCVpOsFTN0pONpPotvudb029xlNcWEm2aMzk6OpYQ=; b=V/ks1ibF/8oDPVDTem0pm6/1JikpNjxJdnWiJQts4YDsyESiwQv9B4Oe+otxZzYyJn XQITnnSJcC70usCfOG1Z3T2xPB8n/ycDDkyfy2XrPe3QYkdQxxjOfdEnp5hW6GNvVstt pqBM24+flqNIW0ri+KVgpHPtgUDti12i2bYWjDjuxHQmroqjRDbrlJ+XtMS2nriTiHp8 ZaoXAaNm9qWWGmVHDrLF6yOHwXznVm+wuuDKtrELyR/Dqrq9L72Zk2yB2R0KNImgy3Up siTbNhLsZVKNPgDbEmLo9COI8JZvn0066gEr9YcpQyHcx9kkeVdMRHaAWoMo0zm+s4jN K9JA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga1si3708663ejc.128.2021.10.08.05.40.14; Fri, 08 Oct 2021 05:40:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241834AbhJHMk1 (ORCPT + 99 others); Fri, 8 Oct 2021 08:40:27 -0400 Received: from mga14.intel.com ([192.55.52.115]:6120 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230253AbhJHMkX (ORCPT ); Fri, 8 Oct 2021 08:40:23 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="226785209" X-IronPort-AV: E=Sophos;i="5.85,357,1624345200"; d="diff'?scan'208";a="226785209" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2021 05:38:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,357,1624345200"; d="diff'?scan'208";a="624724638" Received: from kuha.fi.intel.com ([10.237.72.162]) by fmsmga001.fm.intel.com with SMTP; 08 Oct 2021 05:38:21 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Fri, 08 Oct 2021 15:38:21 +0300 Date: Fri, 8 Oct 2021 15:38:21 +0300 From: Heikki Krogerus To: Bjorn Andersson Cc: Prashant Malani , Doug Anderson , Laurent Pinchart , Rob Clark , Sean Paul , David Airlie , Daniel Vetter , linux-arm-msm , LKML , Abhinav Kumar , Stephen Boyd , Kuogee Hsieh , dri-devel , Vara Reddy , freedreno , Enric Balletbo i Serra , Benson Leung Subject: Re: [RFC] drm/msm/dp: Allow attaching a drm_panel Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d5CDzt0vLc4LIaGn" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --d5CDzt0vLc4LIaGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Thu, Oct 07, 2021 at 09:15:12AM -0700, Bjorn Andersson wrote: > The one thing that I still don't understand though is, if the typec_mux > is used by the typec controller to inform _the_ mux about the function > to be used, what's up with the complexity in typec_mux_match()? This is > what lead me to believe that typec_mux was enabling/disabling individual > altmodes, rather just flipping the physical switch at the bottom. Ah, typec_mux_match() is a mess. I'm sorry about that. I think most of the code in that function is not used by anybody. If I remember correctly, all that complexity is attempting to solve some hypothetical corner case(s). Probable a case where we have multiple muxes per port to deal with. I think it would probable be best to clean the function to the bare minimum by keeping only the parts that are actually used today (attached). thanks, -- heikki --d5CDzt0vLc4LIaGn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mux.diff" diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c index c8340de0ed495..44f168c9bd9bf 100644 --- a/drivers/usb/typec/mux.c +++ b/drivers/usb/typec/mux.c @@ -193,56 +193,15 @@ static int mux_fwnode_match(struct device *dev, const void *fwnode) static void *typec_mux_match(struct fwnode_handle *fwnode, const char *id, void *data) { - const struct typec_altmode_desc *desc = data; struct device *dev; - bool match; - int nval; - u16 *val; - int ret; - int i; /* - * Check has the identifier already been "consumed". If it - * has, no need to do any extra connection identification. + * The connection identifier will be needed with device graph (OF graph). + * Device graph is not supported by this code yet, so bailing out. */ - match = !id; - if (match) - goto find_mux; - - /* Accessory Mode muxes */ - if (!desc) { - match = fwnode_property_present(fwnode, "accessory"); - if (match) - goto find_mux; - return NULL; - } - - /* Alternate Mode muxes */ - nval = fwnode_property_count_u16(fwnode, "svid"); - if (nval <= 0) - return NULL; - - val = kcalloc(nval, sizeof(*val), GFP_KERNEL); - if (!val) - return ERR_PTR(-ENOMEM); - - ret = fwnode_property_read_u16_array(fwnode, "svid", val, nval); - if (ret < 0) { - kfree(val); - return ERR_PTR(ret); - } - - for (i = 0; i < nval; i++) { - match = val[i] == desc->svid; - if (match) { - kfree(val); - goto find_mux; - } - } - kfree(val); - return NULL; + if (id) + return ERR_PTR(-ENOTSUPP); -find_mux: dev = class_find_device(&typec_mux_class, NULL, fwnode, mux_fwnode_match); --d5CDzt0vLc4LIaGn--