From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9B9BC433FE for ; Sun, 20 Feb 2022 11:17:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231983AbiBTLSF (ORCPT ); Sun, 20 Feb 2022 06:18:05 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:57052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbiBTLSD (ORCPT ); Sun, 20 Feb 2022 06:18:03 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E85143AFB; Sun, 20 Feb 2022 03:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645355863; x=1676891863; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wFiGHzKu/gkWdPi94TIZ1NxsAlvi0yITyD0myZyZrQc=; b=DuyfglcsIbXJoAUdkKW4gcOJXIEti9jsjsslsMnu2O5xQjq3rtaGbncv m4U7b+iNLzJtWwh+lt+1p0rCuOPKjXTFUJ9yqzM+CRSZOk9rw9j5TsYhY iQXBNAomp/lJI4RFKy2omkc5ok0nFDIzATZ5xolAtOuEnRFnHCbykcv79 4JJNq4HMIkKZsptTN2RVZSHXhED3dNSbsg6sLbcHuTqfYhlobDYskYYXQ 8iUGIf9ENP4/Mq3yO9lQ9xGSuqpRKhQgV5lTofDvAnoEhsTDMU4Pdv9xa Y+J0dgOVpZ7iE7nw2+z+eARWRSDEldZpYERm1tYvElGVgTICJ9fbEHL+y g==; X-IronPort-AV: E=McAfee;i="6200,9189,10263"; a="337795825" X-IronPort-AV: E=Sophos;i="5.88,383,1635231600"; d="scan'208";a="337795825" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2022 03:17:42 -0800 X-IronPort-AV: E=Sophos;i="5.88,383,1635231600"; d="scan'208";a="638243794" Received: from smile.fi.intel.com ([10.237.72.59]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2022 03:17:39 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nLkCs-006Uow-OJ; Sun, 20 Feb 2022 13:16:46 +0200 Date: Sun, 20 Feb 2022 13:16:46 +0200 From: Andy Shevchenko To: Bjorn Andersson 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 v2 1/6] device property: Helper to match multiple connections Message-ID: References: <20220208031944.3444-1-bjorn.andersson@linaro.org> <20220208031944.3444-2-bjorn.andersson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Fri, Feb 18, 2022 at 11:00:45AM -0800, Bjorn Andersson wrote: > On Wed 09 Feb 04:30 PST 2022, Andy Shevchenko wrote: > > On Mon, Feb 07, 2022 at 07:19:39PM -0800, Bjorn Andersson wrote: ... > > > +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; > > > + > > > + if (!fwnode || !match || !matches) > > > > !matches case may be still useful to get the count and allocate memory by > > caller. Please, consider this case. > > > > As discussed in previous version, and described in the commit message, > the returned value of "match" is a opaque pointer to something which > has to be passed back to the caller in order to be cleaned up. > > E.g. the typec mux code returns a pointer to a typec_mux/switch object > with a refcounted struct device within, or an ERR_PTR(). > > So unfortunately we can must gather the results into matches and pass it > back to the caller to take consume or clean up. It's fine. You have **matches, means pointer of an opaque pointer. What I'm talking about is memory allocation for and array of _pointers_. That's what caller very much aware of and can allocate on heap. So, please consider this case. -- With Best Regards, Andy Shevchenko