[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56A789B4.3060304@codeaurora.org>
Date: Tue, 26 Jan 2016 20:29:00 +0530
From: Archit Taneja <architt@...eaurora.org>
To: Thierry Reding <treding@...dia.com>
Cc: dri-devel@...ts.freedesktop.org, a.hajda@...sung.com,
jani.nikula@...ux.intel.com, linux-kernel@...r.kernel.org,
airlied@...ux.ie, daniel@...ll.ch, l.stach@...gutronix.de,
robh@...nel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v4 1/6] drm/dsi: check for CONFIG_OF when defining
of_mipi_dsi_device_add
On 1/21/2016 9:01 PM, Thierry Reding wrote:
> On Thu, Dec 10, 2015 at 06:11:35PM +0530, Archit Taneja wrote:
>> of_mipi_dsi_device_add is used only when CONFIG_OF is enabled. It
>> currently works if OF support is disabled, but this will change
>> when we add more functionality to it.
>>
>> Define the original func if CONFIG_OF is enabled. Define a dummy func
>> otherwise.
>>
>> Signed-off-by: Archit Taneja <architt@...eaurora.org>
>> ---
>> drivers/gpu/drm/drm_mipi_dsi.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
>> index 2d5ca8ee..bced235 100644
>> --- a/drivers/gpu/drm/drm_mipi_dsi.c
>> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
>> @@ -129,6 +129,7 @@ static int mipi_dsi_device_add(struct mipi_dsi_device *dsi)
>> return device_add(&dsi->dev);
>> }
>>
>> +#if IS_ENABLED(CONFIG_OF)
>> static struct mipi_dsi_device *
>> of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
>> {
>> @@ -170,6 +171,13 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
>>
>> return dsi;
>> }
>> +#else
>> +static struct mipi_dsi_device *
>> +of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
>> +{
>> + return NULL;
>> +}
>> +#endif
>
> The OF implementation of this function never returns NULL, so perhaps
> this should return an ERR_PTR()-encoded error code instead? This isn't
> really important because we never check the return value in the one
> call-site that we have, which I guess could be an argument for removing
> the return value altogether...
You're right. I'll replace this with ERR_PTR(-ENODEV). Maybe we could
keep the return value in case we use it in the future.
Thanks,
Archit
>
> Thierry
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Powered by blists - more mailing lists