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 EE1C1C76196 for ; Fri, 31 Mar 2023 06:44:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230192AbjCaGn7 (ORCPT ); Fri, 31 Mar 2023 02:43:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230104AbjCaGn6 (ORCPT ); Fri, 31 Mar 2023 02:43:58 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0C32A27A for ; Thu, 30 Mar 2023 23:43:43 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id n28so4926307ioz.11 for ; Thu, 30 Mar 2023 23:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1680245023; 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=TJMiIBnIOha8INMf/aKt6n4a45jL1+cW2jXTn14ItTU=; b=NpfpugV6wKsgTbPpOaWm54+nfos2fguzyrvBG1BEwsGGsQPnuppnKYbIC4GWGdcZoW jZYwkukueXAmwAc/sXqgRgVX603AGnSpVaV/lkwM8NxqsweY8JQpf+/+LwoUFHBTr8BA VOCkuekSuf67GI8TQDNSd1Ei5xaOvqVOWwRmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680245023; 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=TJMiIBnIOha8INMf/aKt6n4a45jL1+cW2jXTn14ItTU=; b=Y/rUUhQZS56eumhRuJY1f3UFVNFo7bmUMQiL8TVZUNNUDXT1Udphm5UCV2MIDlqTqs kt8HNuEwqUKoZQI4HcOp6X1OdnwqI5YQ57j01R30/vivsaP9jGUJcT4XXpfJG5G2c3jh O1O+vsFyPl7ju5Nh4vvCta90hXc8vgaHbKSbyV7FT2H9FgjEv75UnYuhPyDhozeo9kh9 xtR7IYZaHbiiNtLdGvoXMpqONzXc/5RbDc1yreluAo/IGEZA5j2wI1XsMWPw3V1VU9rx TZYFLazQsOEDRlqRhCVZpRqwlLw5t3bzAV4QuwqvdDxReT5f9ZkfL7JJv6KypQ4VGCgI MXkw== X-Gm-Message-State: AO0yUKWCM2nuYo85rGbS0IphVnjExay4DskdG/HvYY0WWVVnRnofgRKK CC0C5FX2sTk+QGoUpT85bQR/fUSe+z6Iuz1VL0njjQ== X-Google-Smtp-Source: AK7set+SXmn8wNLCLzHsExgu0fibwth1DHdBynRwGrcMxlN2IJdRta9xWzqdv5f7mEqipgjZ8W0DCENK8hCl2a3ZWj8= X-Received: by 2002:a02:95a1:0:b0:3ec:dc1f:12dd with SMTP id b30-20020a0295a1000000b003ecdc1f12ddmr10175738jai.6.1680245023333; Thu, 30 Mar 2023 23:43:43 -0700 (PDT) MIME-Version: 1.0 References: <20230322104639.221402-1-treapking@chromium.org> <20230322104639.221402-4-treapking@chromium.org> In-Reply-To: From: Pin-yen Lin Date: Fri, 31 Mar 2023 15:43:32 +0900 Message-ID: Subject: Re: [PATCH v14 03/10] drm/display: Add Type-C switch helpers 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 , linux-kernel@vger.kernel.org, Thomas Zimmermann , linux-acpi@vger.kernel.org, Javier Martinez Canillas , AngeloGioacchino Del Regno , Hsin-Yi Wang , Lyude Paul , =?UTF-8?B?TsOtY29sYXMgRiAuIFIgLiBBIC4gUHJhZG8=?= , dri-devel@lists.freedesktop.org, Marek Vasut , Stephen Boyd , chrome-platform@lists.linux.dev, devicetree@vger.kernel.org, Andi Shyti , Dmitry Baryshkov , Douglas Anderson , Imre Deak , Jani Nikula , Linus Walleij , YueHaibing Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Mar 31, 2023 at 11:36=E2=80=AFAM Pin-yen Lin wrote: > > Hi Andy, > > Thanks for the review. > > On Wed, Mar 22, 2023 at 8:01=E2=80=AFPM Andy Shevchenko > wrote: > > > > On Wed, Mar 22, 2023 at 06:46:32PM +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. > > > > ... > > > > > +config DRM_DISPLAY_DP_TYPEC_HELPER > > > > > + bool > > > + default y > > > > def_bool y > > > > > + depends on DRM_DISPLAY_HELPER > > > + depends on DRM_DISPLAY_HELPER=3DTYPEC || TYPEC=3Dy > > > + help > > > + DRM display helpers for USB Type-C Displayport Alternate mode= . > > > > Hmm... Dunno if this help is enough. > > Okay I'll add more detail in the next version. > > > > ... > > > > > + snprintf(name, sizeof(name), "%pfwP-%u", fwnode, port_num); > > > > Would it be possible to have a dup in name and would it be a problem if= so? > > > The port_num is included in the name, so the names should be unique. > Also, the fwnode name actually contains the reg property, so this name > looks like "endpoint@0-1" now... I'll change the name from fwnode name This should be "endpoint@0-0", or "endpoint@1-1@. The `port_num` value has the same number as the `reg` property > to dev_name() per Dmitry's comment. > > ... > > > > > +/** > > > + * drm_dp_register_typec_switches() - register Type-C switches > > > + * @dev: Device that registers Type-C switches > > > + * @port: Device node for the switch > > > + * @switch_desc: A Type-C switch descriptor > > > + * @data: Private data for the switches > > > + * @mux_set: Callback function for typec_mux_set > > > + * > > > + * This function registers USB Type-C switches for DP bridges that c= an switch > > > + * the output signal between their output pins. This function uses d= evm_kcalloc > > > + * to allocate memory, so it is expected to only call this in the dr= iver probe > > > + * functions. > > > + * > > > + * Currently only mode switches are implemented, and the function as= sumes the > > > + * given @port device node has endpoints with "mode-switch" property= . > > > + * The port number is determined by the "reg" property of the endpoi= nt. > > > > `kernel-doc -v ...` should complain on absence of "Return" section. > > > > > + */ > > > > ... > > > > > + switch_desc->typec_ports =3D devm_kcalloc(dev, switch_desc->num= _typec_switches, > > > + sizeof(struct drm_dp_ty= pec_port_data), > > > > sizeof(*switch_desc_typ= ec_ports), > > > > ? > > > > > + GFP_KERNEL); > > > + if (!switch_desc->typec_ports) > > > + return -ENOMEM; > > > > ... > > > > > +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER > > > > Ah, maybe this should use IS_REACHABLE() ? > > CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER is a boolean. Is there any > difference between IS_REACHABLE and ifdef when the given config is a > boolean? > > > > > +void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_des= c *switch_desc); > > > +int drm_dp_register_typec_switches(struct device *dev, struct fwnode= _handle *port, > > > + struct drm_dp_typec_switch_desc *swi= tch_desc, > > > + void *data, typec_mux_set_fn_t mux_s= et); > > > +#else > > > +static inline void drm_dp_unregister_typec_switches(struct drm_dp_ty= pec_switch_desc *switch_desc) > > > +{ > > > +} > > > +static inline int drm_dp_register_typec_switches( > > > + struct device *dev, struct fwnode_handle *port, > > > + struct drm_dp_typec_switch_desc *switch_desc, void *dat= a, > > > + typec_mux_set_fn_t mux_set) > > > +{ > > > + return -EOPNOTSUPP; > > > +} > > > +#endif > > > > -- > > With Best Regards, > > Andy Shevchenko > > > > Best regards, > Pin-yen > >