Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp279983iog; Wed, 15 Jun 2022 02:04:32 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tMPqp2xhDI/4RStbuX7+W6fpQAT7cLpmkcMx6+67n3lR34VJmQuFpzArd8CKtrjwEPmMd4 X-Received: by 2002:a17:907:6d91:b0:711:ec13:b7d8 with SMTP id sb17-20020a1709076d9100b00711ec13b7d8mr8135719ejc.565.1655283872167; Wed, 15 Jun 2022 02:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655283872; cv=none; d=google.com; s=arc-20160816; b=vCx6ls0RsFVcwK39RVQHqsr593n4xL+89BodD1OJix4lqhmX6yfmcj8Xvd+3hKuEai gc34DdsH6Au/dw50bDwHyuzbbmA/6O6KnL+d+A0LgeNazi0FtaAKlIbVfbCXrLFmPpjT f02Yb3Lwi4LGbM0KR23Ajknr8ntn7LoI1qdohrJ6r2z6WZJyH3s7YIWfLGHhosgLDJ5s 9T3zP5x8hcNcR/VOdpaJzfrVTWKxJd7jDlzYZbMVf6MhEFXEJ7v9Tv1YlE39EklUqiU/ qO6VmqXg6+Ks/VR9dM1nwIZx4UQsBcclIDuhca/a+rD0EQ2OYNdak7qk9eC+lXOBt30s 3S/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=hsob+AoXA9o+5gtLAjNi8m/7wShcAhs+woMqbifIvwk=; b=sx9WZGyWdjz8QYKTr0c/sw80d/7M5Zf+hFoSFNq8fU15pmAPMkrYsEWmGBZreBjvt/ fO1Ki9em7rpecJ7K1QpAXre2s6jiNnPmU8Psbfy7jd17VJ0dxKIaDxXMsaBaJEAM6O1W h8yIcLaOAcMkM4rRaPM0f/HUwb33pEtvisBL3BlM0eSpuZgzIK3fnh1QLnxzDKVeuHUA 9OkMtIxBr4FD9UPb6m0AxJ0sgTs0KKEDAZUsASCIh4lzC6Y9PmCkznMUL3qQencErDTT Fy47ZI7T/uxqG6RDPnBYsgCAVR7QJpwJhSzB8Zz5lCRwjNkYk0txSf4ouJPvnPNk/L2t PY7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=NSbZ9O2m; 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=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o3-20020aa7c503000000b0042b59111a63si1470804edq.256.2022.06.15.02.03.50; Wed, 15 Jun 2022 02:04:32 -0700 (PDT) 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=@collabora.com header.s=mail header.b=NSbZ9O2m; 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=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343836AbiFOIpz (ORCPT + 99 others); Wed, 15 Jun 2022 04:45:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345598AbiFOIpi (ORCPT ); Wed, 15 Jun 2022 04:45:38 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7958F4F1C9; Wed, 15 Jun 2022 01:45:37 -0700 (PDT) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 5FFF966016CE; Wed, 15 Jun 2022 09:45:34 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1655282735; bh=ig8964Pis3U0xmrv25bzOpvQC450sNHC3GS2vgea2vE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NSbZ9O2mvG+kvEwG/FE6u4dUr1wC35qYVWum6oK8RGl+oxZr81kxh2GENXiCCbPPa rYIozjo+Edc8uLzJV6bg1PgSSezGBeBbjxMdlH4Q4zUAHE/U2ifUKrx0rXwpBGnjDL UuK05auuOUhn+ZHUvRoySp/oBkYlt26K4g5W/vt3BUuZTIkwW2h1eHi2bhPSBRZHRE Wo8gFy3YQIKAgsfecFk5dPHM7y5ii6iVMwaU1ARBcLAcBu8kgw2h9NWlSKm5En8kSo FfIiq6UPzpDNiu6PKfRKrqy5npwwAk053WfXFyB7K47/r28yCFZ2tMI5I5D13dviod K69g7f+e/HXvw== Message-ID: <28135a2f-bf02-fd0b-e881-0ce9d68bd764@collabora.com> Date: Wed, 15 Jun 2022 10:45:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v2 6/7] drm/bridge: anx7625: Register Type-C mode switches Content-Language: en-US To: Prashant Malani Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, heikki.krogerus@linux.intel.com, Andrzej Hajda , Neil Armstrong , David Airlie , "open list:DRM DRIVERS" , Laurent Pinchart , Krzysztof Kozlowski , Sam Ravnborg , Jernej Skrabec , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Thomas Zimmermann , =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= , Jonas Karlman , swboyd@chromium.org, Pin-Yen Lin , Rob Herring , Maxime Ripard , Hsin-Yi Wang , Xin Ji , Greg Kroah-Hartman , Robert Foss , =?UTF-8?B?Sm9zw6kgRXhww7NzaXRv?= References: <20220609181106.3695103-1-pmalani@chromium.org> <20220609181106.3695103-7-pmalani@chromium.org> From: AngeloGioacchino Del Regno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Il 14/06/22 18:57, Prashant Malani ha scritto: > On Tue, Jun 14, 2022 at 1:18 AM AngeloGioacchino Del Regno > wrote: >> >> Il 09/06/22 20:09, Prashant Malani ha scritto: >>> When the DT node has "switches" available, register a Type-C mode-switch >>> for each listed "switch". This allows the driver to receive state >>> information about what operating mode a Type-C port and its connected >>> peripherals are in, as well as status information (like VDOs) related to >>> that state. >>> >>> The callback function is currently a stub, but subsequent patches will >>> implement the required functionality. >>> >>> Signed-off-by: Prashant Malani >>> --- >>> >>> Changes since v2: >>> - No changes. >>> >>> drivers/gpu/drm/bridge/analogix/anx7625.c | 73 +++++++++++++++++++++++ >>> drivers/gpu/drm/bridge/analogix/anx7625.h | 6 ++ >>> 2 files changed, 79 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c >>> index 07ed44c6b839..d41a21103bd3 100644 >>> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c >>> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c >>> @@ -15,6 +15,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> >>> #include >>> @@ -2581,9 +2582,59 @@ static void anx7625_runtime_disable(void *data) >>> pm_runtime_disable(data); >>> } >>> >>> +static int anx7625_typec_mux_set(struct typec_mux_dev *mux, >>> + struct typec_mux_state *state) >>> +{ >>> + return 0; >>> +} >>> + >>> +static int anx7625_register_mode_switch(struct device *dev, struct device_node *node, >>> + struct anx7625_data *ctx) >>> +{ >>> + struct anx7625_port_data *port_data; >>> + struct typec_mux_desc mux_desc = {}; >>> + char name[32]; >>> + u32 port_num; >>> + int ret; >>> + >>> + ret = of_property_read_u32(node, "reg", &port_num); >>> + if (ret) >>> + return ret; >>> + >>> + if (port_num >= ctx->num_typec_switches) { >>> + dev_err(dev, "Invalid port number specified: %d\n", port_num); >>> + return -EINVAL; >>> + } >>> + >>> + port_data = &ctx->typec_ports[port_num]; >>> + port_data->ctx = ctx; >>> + mux_desc.fwnode = &node->fwnode; >>> + mux_desc.drvdata = port_data; >>> + snprintf(name, sizeof(name), "%s-%u", node->name, port_num); >>> + mux_desc.name = name; >>> + mux_desc.set = anx7625_typec_mux_set; >>> + >>> + 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", port_num, ret); >>> + } >> >> Please return 0 at the end of this function. >> >> if (IS_ERR(....)) { >> ......code...... >> return ret; >> } >> >> return 0; >> } > > May I ask why? We're not missing any return paths. I would rather we > keep it as is (which has the valid return value). > I know that you're not missing any return paths. That's only because the proposed one is a common pattern in the kernel and it's only for consistency. Regards, Angelo