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 7EED3C64EC4 for ; Wed, 8 Mar 2023 13:51:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231625AbjCHNvw (ORCPT ); Wed, 8 Mar 2023 08:51:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231253AbjCHNvj (ORCPT ); Wed, 8 Mar 2023 08:51:39 -0500 Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01987BE5D4 for ; Wed, 8 Mar 2023 05:51:30 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id e11so6789073ioe.3 for ; Wed, 08 Mar 2023 05:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1678283490; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O2ScB8i7PrG39DRTErC7kF+bBBVGcw9XNhNSA0VqouI=; b=imkqhCCosUh66ifIsRQPbANxZXdmJpEwCj2rF7iSVxboMb7R9EE2AFrdMjLL16Y/Kw ooGlAR2bIPsm2FI/6N4VeIN+MSDg7j79K5/3wNTcuCOl8Gx8dM0twquGzlpwCcPl1klq NicNIX+rKLK1R+g/ECbCTeA/17uvvBo5G2SJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678283490; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O2ScB8i7PrG39DRTErC7kF+bBBVGcw9XNhNSA0VqouI=; b=0x9v304uDa47NScxyTOx7+xmNsVV4PtSv5TU7Ax6PrSTJga7I0FPGQMRrMaeF/7QVw n9Vc9DigYBj5Er4oH4OtBdE7/8SzJ4WO0v9WUMPvGRrjmqADQlfI70+ojE9ZtwC1w16F OpjbUwKNr5gBTsJlvq2BKCighTDgwOYSpfXzPAExXANKn3xaQ6fVzdI/Wqw22B24Edxo p4Nkrav38VamsepP4f5BJTn23kqRDA6tWfydvQ+3khd/dTiWgWDnQvHNxkig4ksXTN0N 1A24DF1qoVwT4vpIFtER0KkJoDdMsFoNkX3jeF+YXQIFQPXxuEnlMOt0iO8GkyLtuC0H OORQ== X-Gm-Message-State: AO0yUKVX2MpQ9SUU8Z4uui2Tmd82hVKwVSufM6nH5r+tJ6PxNcicE82O GaSBnl7d+wHJ/iY3BcAcGLsb8mPwMuehPfC4riZ0+Q== X-Google-Smtp-Source: AK7set8VM1H7ES454XkYoww9M66+Aop3lkGBIArzYN2bvLHb4IHDHyckUz3PiQcAOs/tKbPekPyLMzsgcHMc8Vkk8wo= X-Received: by 2002:a6b:dc0c:0:b0:743:5fb0:2ca8 with SMTP id s12-20020a6bdc0c000000b007435fb02ca8mr8414193ioc.4.1678283490142; Wed, 08 Mar 2023 05:51:30 -0800 (PST) MIME-Version: 1.0 References: <20230303143350.815623-1-treapking@chromium.org> <20230303143350.815623-11-treapking@chromium.org> In-Reply-To: From: Pin-yen Lin Date: Wed, 8 Mar 2023 21:51:19 +0800 Message-ID: Subject: Re: [PATCH v13 10/10] drm/bridge: it6505: Register Type C mode switches To: Andy Shevchenko 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, =?UTF-8?B?TsOtY29sYXMgRiAuIFIgLiBBIC4gUHJhZG8=?= , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Andy, Thanks for the review. On Mon, Mar 6, 2023 at 8:03=E2=80=AFPM Andy Shevchenko wrote: > > On Fri, Mar 03, 2023 at 10:33:50PM +0800, Pin-yen Lin wrote: > > Register USB Type-C mode switches when the "mode-switch" property and > > relevant port are available in Device Tree. Configure the "lane_swap" > > state based on the entered alternate mode for a specific Type-C > > connector, which ends up updating the lane swap registers of the it6505 > > chip. > > ... > > > + it6505->port_data =3D devm_kcalloc(dev, switch_desc->num_typec_sw= itches, > > + sizeof(struct it6505_typec_port_= data), > > + GFP_KERNEL); > > > + > > Same, no need for a blank line here. > I'll fix this in the next version. > > + if (!it6505->port_data) { > > + ret =3D -ENOMEM; > > + goto unregister_mux; > > + } > > ... > > > + it6505->port_data[i].lane_swap =3D (dp_lanes[0] / 2 =3D= =3D 1); > > ' % 2 =3D=3D 0' ? > Per another patch, I'll update this into `< 2` > ... > > Wouldn't be better to have > > ret =3D PTR_ERR_OR_ZERO(extcon); > > here and amend the following accordingly? > > > if (PTR_ERR(extcon) =3D=3D -EPROBE_DEFER) > > return -EPROBE_DEFER; > > if (IS_ERR(extcon)) { > > - dev_err(dev, "can not get extcon device!"); > > - return PTR_ERR(extcon); > > + if (PTR_ERR(extcon) !=3D -ENODEV) > > + dev_warn(dev, "Cannot get extcon device: %ld\n", > > + PTR_ERR(extcon)); > > + it6505->extcon =3D NULL; > > + } else { > > + it6505->extcon =3D extcon; > > } > > > > - it6505->extcon =3D extcon; > > + init_completion(&it6505->mux_register); > > + ret =3D it6505_register_typec_switches(dev, it6505); > > + if (ret) { > > + if (ret !=3D -ENODEV) > > + dev_warn(dev, "Didn't register Type-C switches, e= rr: %d\n", > > + ret); > > + if (!it6505->extcon) { > > + dev_err(dev, "Both extcon and typec-switch are no= t registered.\n"); > > + return -EINVAL; > > + } > > + } > > > Perhaps > > if (ret !=3D -ENODEV) > dev_warn(dev, "Didn't register Type-C switches, err: %d\n= ", ret); > > if (ret && !it6505->extcon) { > dev_err(dev, "Both extcon and typec-switch are not regist= ered.\n"); > return ret; > } > > ? Thanks for the suggestion! I'll update this in v14. > > -- > With Best Regards, > Andy Shevchenko > > Best regards, Pin-yen