[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28135a2f-bf02-fd0b-e881-0ce9d68bd764@collabora.com>
Date: Wed, 15 Jun 2022 10:45:31 +0200
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Prashant Malani <pmalani@...omium.org>
Cc: linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
heikki.krogerus@...ux.intel.com,
Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <narmstrong@...libre.com>,
David Airlie <airlied@...ux.ie>,
"open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Sam Ravnborg <sam@...nborg.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
Nícolas F. R. A. Prado
<nfraprado@...labora.com>, Jonas Karlman <jonas@...boo.se>,
swboyd@...omium.org, Pin-Yen Lin <treapking@...omium.org>,
Rob Herring <robh+dt@...nel.org>,
Maxime Ripard <maxime@...no.tech>,
Hsin-Yi Wang <hsinyi@...omium.org>,
Xin Ji <xji@...logixsemi.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Robert Foss <robert.foss@...aro.org>,
José Expósito <jose.exposito89@...il.com>
Subject: Re: [PATCH v2 6/7] drm/bridge: anx7625: Register Type-C mode switches
Il 14/06/22 18:57, Prashant Malani ha scritto:
> On Tue, Jun 14, 2022 at 1:18 AM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@...labora.com> 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 <pmalani@...omium.org>
>>> ---
>>>
>>> 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 <linux/regulator/consumer.h>
>>> #include <linux/slab.h>
>>> #include <linux/types.h>
>>> +#include <linux/usb/typec_mux.h>
>>> #include <linux/workqueue.h>
>>>
>>> #include <linux/of_gpio.h>
>>> @@ -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
Powered by blists - more mailing lists