Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1537906pxp; Sun, 6 Mar 2022 18:29:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJwaV8N0JJW6CAepGHdU7aHQ05GdAexQWl5sP6aqa5EJYU1o/yE5uQGKYA0wnl5X6IpoNNEC X-Received: by 2002:a17:906:5fd3:b0:6db:47a:411e with SMTP id k19-20020a1709065fd300b006db047a411emr6366332ejv.637.1646620197217; Sun, 06 Mar 2022 18:29:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646620197; cv=none; d=google.com; s=arc-20160816; b=uX+z2pX8/aEg4peT+orTZI8YJ6T8x8eq2fWodnGPi0UDWf9adQRMDmpPLsoDFuc8DG YWBxf/TkKFrfV27O2U0RYh0LlWarBYWf5+OnDH911PXcy2sN00yb6kszA4gRZrBIM5FQ CR7qMHrQJ28qEyG0OOWn02LMs42wXThD5jeiGnOeoFWbObFU4v6QZtqPpCYzIvMp9qZD AjFEoixgSRwV3NerLgjcEDtqHhMy5OEWa4LiBQ65dBXTVY5k9ab11KzD2q41ntL7ZF4x 6IlpJkcLZ+dpi4Cgl7oX8BZIUQVV/UcaZ754WGWO+5GZYECND9EnYi6N/q40jhJuB3tZ KR6Q== 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=91JHo+kN7GqhMtZV/rEVrLYoHL8DpG7QLjAYJ+/Aigc=; b=AXPJ8xF8ySVeNXZAHydhMjnryFNukV2/Dgjn2GRVOVJYsEsyYKwQo7MmUeoDmlQeNK qiV9Fi7pKB5W0syxLlBh75e+PAymGwpjvoufK8FzemJuJ8KJ4HHIge7gqFShqFuZl1an wDs5dn/Hvwgrw5mtlq22Bn/Ey0oiFR+mcBdaNCjQSXUBnDxMC+y0PHoFm6xLjjWOiXAo rtgk7VQLTQ3csVDLAcWABGdK1U6rEXZGm8py0JtYDKpdqvExebToFfJBoUZ63HmLVjIX xTdzxRnZ7P36RmxrNalFwtfp0zxqicjV+tkk/s5v7eif0TIIFRPt2e4HUQsXSVjnXyRY 6+Cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nkrLcVSj; 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=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l17-20020a170906795100b006db166ef563si2453389ejo.16.2022.03.06.18.29.35; Sun, 06 Mar 2022 18:29:57 -0800 (PST) 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=@linaro.org header.s=google header.b=nkrLcVSj; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234674AbiCGCKh (ORCPT + 99 others); Sun, 6 Mar 2022 21:10:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233300AbiCGCKg (ORCPT ); Sun, 6 Mar 2022 21:10:36 -0500 Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0995E0E7 for ; Sun, 6 Mar 2022 18:09:42 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id z7so13785134oid.4 for ; Sun, 06 Mar 2022 18:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=91JHo+kN7GqhMtZV/rEVrLYoHL8DpG7QLjAYJ+/Aigc=; b=nkrLcVSjKtzpHK3S3tQXUQCWDCHVlxe3tlubcwjorSDBLIGy2bvjmKf4SVkuSM7L5i WGd4jS+q6l6IBnrF0/NHAOgEPUjN0Sx3LL9ESYCvrvxZEqREuZ0aK/FNKJWCV8ShXsd6 2Uceqox+rZhex2s47Sj4TSD/MbCbvTjEOf3Ujwf44vPr+G/t4IaOJhx/1TjgZvVC2vNt 3fUzrR6MAH+iuXdyFO0x3ggOqOIsKARcSBOEX25QBQbK7DUsq9JWTtLD98/gNfJYeRvl 4hVtA8FcLJg9DI2sf7zejvabDqs3Tbyf3UwXWDLBWX8qM0Syu0JJDSsqw+5VPqBAEvdu nVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=91JHo+kN7GqhMtZV/rEVrLYoHL8DpG7QLjAYJ+/Aigc=; b=NmNrurg/m8YquOh0qZuZyk3kYT+tXGlXo5gLP+n8tiG46KGwKEetiyr56EjViYwDOv RX3oAln+qYogo7glwAGLhqhOekYM6T8StOk9dPSRw4y3XwQHVqi9OfIZc6TGMUf+sF47 ghrkPlLzCrWVcLHDtbhruRDV+PRF8JG+GGQNvngj5gzuIV2MhFynTsab7fMZDCsJk1Qj N5ZWjGtIWg6mb83CIq9VCq6EDzoCd7bN/tNGYMUFmcbs0DAoM//QtmMoQalNnQj+YeCo JIJOU+DnuvMgS3/ueNiiN92JnlmtYiOlkHyCJsAMnR0Do1MCV3O9UKl8544sS1FRoPwz hHNQ== X-Gm-Message-State: AOAM531v0ZedRM9d9CxmWXcRlmfj1e7j+8JVTVb3B/CaA2+b/hrRcTLA p5qTguSqoqbz58XVonIZhbx1Hg== X-Received: by 2002:a05:6808:10d2:b0:2d9:a01a:4b9d with SMTP id s18-20020a05680810d200b002d9a01a4b9dmr6145452ois.196.1646618981954; Sun, 06 Mar 2022 18:09:41 -0800 (PST) Received: from yoga ([2600:1700:a0:3dc8:5c39:baff:fe03:898d]) by smtp.gmail.com with ESMTPSA id bl16-20020a056808309000b002d43b28a8bdsm6012298oib.14.2022.03.06.18.09.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Mar 2022 18:09:41 -0800 (PST) Date: Sun, 6 Mar 2022 20:09:39 -0600 From: Bjorn Andersson To: Andy Shevchenko Cc: Rob Herring , Daniel Scally , Heikki Krogerus , Sakari Ailus , "Rafael J. Wysocki" , Hans de Goede , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Dmitry Baryshkov Subject: Re: [PATCH v3 1/6] device property: Helper to match multiple connections Message-ID: References: <20220303223351.141238-1-bjorn.andersson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 04 Mar 06:54 CST 2022, Andy Shevchenko wrote: > On Thu, Mar 03, 2022 at 02:33:46PM -0800, Bjorn Andersson wrote: > > In some cases multiple connections with the same connection id > > needs to be resolved from a fwnode graph. > > > > One such example is when separate hardware is used for performing muxing > > and/or orientation switching of the SuperSpeed and SBU lines in a USB > > Type-C connector. In this case the connector needs to belong to a graph > > with multiple matching remote endpoints, and the Type-C controller needs > > to be able to resolve them both. > > > > Add a new API that allows this kind of lookup. > > ... > > > +static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode, > > + const char *con_id, void *data, > > + devcon_match_fn_t match, > > + void **matches, > > + unsigned int matches_len) > > +{ > > + struct fwnode_handle *node; > > + struct fwnode_handle *ep; > > + unsigned int count = 0; > > + void *ret; > > + > > + fwnode_graph_for_each_endpoint(fwnode, ep) { > > > + if (count >= matches_len && matches) { > > + fwnode_handle_put(ep); > > + return count; > > + } > > Wouldn't be the same as > > if (count >= matches_len) { This would cause the return value to be at most matches_len, seems relevant to ignore (or perhaps require it to be 0) when matches is NULL. But flipping the order of the expression seems better to me, now that this has been sitting for a while. > fwnode_handle_put(ep); > break; Right, this isn't an "early return", so nicer to have a single return at the bottom. > } > > ? > > > + node = fwnode_graph_get_remote_port_parent(ep); > > + if (!fwnode_device_is_available(node)) { > > + fwnode_handle_put(node); > > + continue; > > + } > > + > > + ret = match(node, con_id, data); > > + fwnode_handle_put(node); > > + if (ret) { > > + if (matches) > > + matches[count] = ret; > > + count++; > > + } > > + } > > + return count; > > +} > > ... > > > +static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode, > > + const char *con_id, void *data, > > + devcon_match_fn_t match, > > + void **matches, > > + unsigned int matches_len) > > +{ > > + struct fwnode_handle *node; > > + unsigned int count = 0; > > + unsigned int i; > > + void *ret; > > + > > + for (i = 0; ; i++) { > > > + if (count >= matches_len && matches) > > + return count; > > Ditto. > > > + node = fwnode_find_reference(fwnode, con_id, i); > > + if (IS_ERR(node)) > > + break; > > + > > + ret = match(node, NULL, data); > > + fwnode_handle_put(node); > > + if (ret) { > > + if (matches) > > + matches[count] = ret; > > + count++; > > + } > > + } > > + > > + return count; > > +} > > ... > > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode, > > + const char *con_id, void *data, > > + devcon_match_fn_t match, > > + void **matches, unsigned int matches_len) > > +{ > > + unsigned int count_graph; > > + unsigned int count_ref; > > + > > + if (!fwnode || !match) > > + return -EINVAL; > > > + count_graph = fwnode_graph_devcon_matches(fwnode, con_id, data, match, > > + matches, matches_len); > > > + matches += count_graph; > > + matches_len -= count_graph; > > No, won't work when matches == NULL. > Sorry about that, you're obviously correct. > Also, matches_len is expected to be 0 in that case (or at least being ignored, > check with vsnprintf() behaviour in similar case). > > So, something like this, perhaps > > if (matches && matches_len) { > matches += count_graph; > matches_len -= count_graph; > } Seems reasonable. Thanks, Bjorn > > > + count_ref = fwnode_devcon_matches(fwnode, con_id, data, match, > > + matches, matches_len); > > + > > + return count_graph + count_ref; > > +} > > > -- > With Best Regards, > Andy Shevchenko > >