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 D3252C6FD1C for ; Mon, 6 Mar 2023 11:49:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229928AbjCFLt5 (ORCPT ); Mon, 6 Mar 2023 06:49:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbjCFLtz (ORCPT ); Mon, 6 Mar 2023 06:49:55 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0AD51C7F2; Mon, 6 Mar 2023 03:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678103394; x=1709639394; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=um7CQzxNZpfEkzvRsWCHjh149pxoosAWW6kD+77Ctas=; b=SVSGDvuFgbJ0v666TITbuJP+QDrGkY66mgoC+NYwaXJ5h472acCcQc71 rI37QibQDOLm7EXHheO5QXOJ6fVoqeJSnVC1HcgK5mtsFska9FvhIKThA ICFnbPiQ1zzsAholfaS2wLBbllELA9CGRbfNApPCl+faFli6Drr0J2P0S GM3ADuuAmJ02s9XwzhIZEkfC1X/gSQ2TJQXn2xoFKjJh1RQv6BiIhJppy dbN3skJnYZcuJJTBZEZOzDzW2B5nAHj/BhFQzSoXPsVQyW3dEtTrTH9db YS1dIhOY4gF/7MevDoiEaJ+UKKHgjRdNI+7Y2nzwIIVdEJ//BjvycD9pp Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10640"; a="337851128" X-IronPort-AV: E=Sophos;i="5.98,236,1673942400"; d="scan'208";a="337851128" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2023 03:49:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10640"; a="850263457" X-IronPort-AV: E=Sophos;i="5.98,236,1673942400"; d="scan'208";a="850263457" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga005.jf.intel.com with ESMTP; 06 Mar 2023 03:49:44 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pZ9LZ-00GKdu-08; Mon, 06 Mar 2023 13:49:41 +0200 Date: Mon, 6 Mar 2023 13:49:40 +0200 From: Andy Shevchenko To: Pin-yen Lin Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , Rob Herring , Krzysztof Kozlowski , Daniel Scally , Heikki Krogerus , Sakari Ailus , Greg Kroah-Hartman , "Rafael J . Wysocki" , Prashant Malani , Benson Leung , Guenter Roeck , Xin Ji , Javier Martinez Canillas , Lyude Paul , linux-kernel@vger.kernel.org, AngeloGioacchino Del Regno , chrome-platform@lists.linux.dev, =?iso-8859-1?Q?N=EDcolas_F_=2E_R_=2E_A_=2E?= Prado , Marek Vasut , Hsin-Yi Wang , devicetree@vger.kernel.org, Allen Chen , dri-devel@lists.freedesktop.org, Thomas Zimmermann , Stephen Boyd , linux-acpi@vger.kernel.org, Alex Deucher , Douglas Anderson , Imre Deak , Jani Nikula , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH v13 03/10] drm/display: Add Type-C switch helpers Message-ID: References: <20230303143350.815623-1-treapking@chromium.org> <20230303143350.815623-4-treapking@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230303143350.815623-4-treapking@chromium.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 03, 2023 at 10:33:43PM +0800, Pin-yen Lin wrote: > Add helpers to register and unregister Type-C "switches" for bridges > capable of switching their output between two downstream devices. > > The helper registers USB Type-C mode switches when the "mode-switch" > and the "reg" properties are available in Device Tree. ... > + port_data->typec_mux = typec_mux_register(dev, &mux_desc); > + if (IS_ERR(port_data->typec_mux)) { > + ret = PTR_ERR(port_data->typec_mux); > + dev_err(dev, "Mode switch register for port %d failed: %d\n", > + port_num, ret); > + return ret; > + } > + > + return 0; Can be simply port_data->typec_mux = typec_mux_register(dev, &mux_desc); ret = PTR_ERR_OR_ZERO(port_data->typec_mux); if (ret) dev_err(dev, "Mode switch register for port %d failed: %d\n", port_num, ret); return ret; ... > + switch_desc->typec_ports = devm_kcalloc(dev, switch_desc->num_typec_switches, > + sizeof(struct drm_dp_typec_port_data), > + GFP_KERNEL); > + if (!switch_desc->typec_ports) > + return -ENOMEM; How often this function _can_ be called during the runtime? If it's _possible_ to call it infinite times, consider *not* using devm. -- With Best Regards, Andy Shevchenko