From: walter harms <wharms@bfs.de>
To: kernel-janitors@vger.kernel.org
Subject: Re: [bug report] x86/sfi: Enable enumeration of SD devices
Date: Tue, 30 Aug 2016 11:06:21 +0000 [thread overview]
Message-ID: <57C568AD.1010703@bfs.de> (raw)
In-Reply-To: <20160715192348.GA6521@mwanda>
Am 30.08.2016 11:46, schrieb Andy Shevchenko:
> On Mon, 2016-08-29 at 20:59 +0000, Kuppuswamy, Sathyanarayanan wrote:
>> Hi Andy/Dan,
>>
>> Thanks for catching this bug. As Andy mentioned, this code is written
>> in this manner to let the get_platform_data() function pointer to
>> return the error value on initialization failure. But it has never
>> been used properly in any of the existing code. So my suggestion is
>> either change the platform_lib code to return ERR_PTR on failure or
>> change the intel_mid_sfi_get_pdata to check for NULL as well. Since
>> all the use case of intel_mid_sfi_get_pdata are void functions, I
>> would prefer to go with second solution. Please let me know your
>> comments.
>>
>> diff --git a/arch/x86/platform/intel-mid/sfi.c
>> b/arch/x86/platform/intel-mid/sfi.c
>> index 051d264..a6bd275 100644
>> --- a/arch/x86/platform/intel-mid/sfi.c
>> +++ b/arch/x86/platform/intel-mid/sfi.c
>> @@ -336,7 +336,7 @@ static void __init sfi_handle_ipc_dev(struct
>> sfi_device_table_entry *pentry,
>> pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
>> pentry->name, pentry->irq);
>> pdata = intel_mid_sfi_get_pdata(dev, pentry);
>> - if (IS_ERR(pdata))
>> + if (IS_ERR_OR_NULL(pdata))
>
> But this looks wrong.
> pdata = NULL is valid case for many devices! In other words pdata is an
> optional argument to the device drivers.
>
Yep, the way is wrong.
NULL can say: get_platform_data does not exists
or get_platform_data() returned NULL (what ever that means).
IMHO it feels better to drop the define and replace it
with a proper function call and error.
#define intel_mid_sfi_get_pdata(dev, priv) \
((dev)->get_platform_data ? (dev)->get_platform_data(priv) : NULL)
void *fkt(struct devs_id *dev, void *info)
{
if ( ! dev->get_platform_data)
return ERR_PTR(-ENOSYS);
return dev->get_platform_data(info);
}
just my 2 cents,
re,
wh
>> return;
>>
>> pdev = platform_device_alloc(pentry->name, 0);
>> @@ -371,7 +371,7 @@ static void __init sfi_handle_spi_dev(struct
>> sfi_device_table_entry *pentry,
>> spi_info.chip_select);
>>
>> pdata = intel_mid_sfi_get_pdata(dev, &spi_info);
>> - if (IS_ERR(pdata))
>> + if (IS_ERR_OR_NULL(pdata))
>> return;
>>
>> spi_info.platform_data = pdata;
>> @@ -398,7 +398,7 @@ static void __init sfi_handle_i2c_dev(struct
>> sfi_device_table_entry *pentry,
>> i2c_info.addr);
>> pdata = intel_mid_sfi_get_pdata(dev, &i2c_info);
>> i2c_info.platform_data = pdata;
>> - if (IS_ERR(pdata))
>> + if (IS_ERR_OR_NULL(pdata))
>> return;
>>
>> if (dev->delay)
>> @@ -424,7 +424,7 @@ static void __init sfi_handle_sd_dev(struct
>> sfi_device_table_entry *pentry,
>> sd_info.max_clk,
>> sd_info.addr);
>> pdata = intel_mid_sfi_get_pdata(dev, &sd_info);
>> - if (IS_ERR(pdata))
>> + if (IS_ERR_OR_NULL(pdata))
>> return;
>>
>> /* Nothing we can do with this for now */
>>
>>
>> Thanks and regards,
>> Sathyanarayanan KN
>>
>> ________________________________________
>> From: Andy Shevchenko [andriy.shevchenko@linux.intel.com]
>> Sent: Sunday, August 28, 2016 6:31 AM
>> To: Dan Carpenter
>> Cc: kernel-janitors@vger.kernel.org; David Cohen; Kuppuswamy,
>> Sathyanarayanan
>> Subject: Re: [bug report] x86/sfi: Enable enumeration of SD devices
>>
>> + David, Sathya
>>
>> On Tue, 2016-08-09 at 20:58 +0300, Dan Carpenter wrote:
>>>
>>> On Tue, Aug 09, 2016 at 06:32:55PM +0300, Andy Shevchenko wrote:
>>>>
>>>>
>>>> On Fri, 2016-07-15 at 22:23 +0300, Dan Carpenter wrote:
>>>>>
>>>>>
>>>>> Hello Andy Shevchenko,
>>>>>
>>>>> The patch 05f310e26fe9: "x86/sfi: Enable enumeration of SD
>>>>> devices"
>>>>> from Jul 12, 2016, leads to the following static checker
>>>>> warning:
>>>>>
>>>>> arch/x86/platform/intel-mid/sfi.c:427 sfi_handle_sd_dev()
>>>>> warn: 'pdata' isn't an ERR_PTR
>>>>>
>>>>> arch/x86/platform/intel-mid/sfi.c
>>>>> 416 memset(&sd_info, 0, sizeof(sd_info));
>>>>> 417 strncpy(sd_info.name, pentry->name,
>>>>> SFI_NAME_LEN);
>>>>> 418 sd_info.bus_num = pentry->host_num;
>>>>> 419 sd_info.max_clk = pentry->max_freq;
>>>>> 420 sd_info.addr = pentry->addr;
>>>>> 421 pr_debug("SD bus = %d, name = %16.16s, max_clk >>>>> %d,
>>>>> addr = 0x%x\n",
>>>>> 422 sd_info.bus_num,
>>>>> 423 sd_info.name,
>>>>> 424 sd_info.max_clk,
>>>>> 425 sd_info.addr);
>>>>> 426 pdata = intel_mid_sfi_get_pdata(dev, &sd_info);
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> This is a macro calling a function pointer. None of the
>>>>> functions
>>>>> return error pointers. Some return NULL on error but some
>>>>> return
>>>>> NULL
>>>>> on success.
>>>>>
>>>>> 427 if (IS_ERR(pdata))
>>>>> 428 return;
>>>>> 429
>>>>> 430 /* Nothing we can do with this for now */
>>>>> 431 sd_info.platform_data = pdata;
>>>>> 432
>>>>
>>>> Thanks for catching up this. At some point in the future I will
>>>> re-
>>>> check
>>>> all those so called "device lib" files to be aligned to one
>>>> standard. Of
>>>> course you may propose a patch if you feel you can do it.
>>>
>>> I'm a temporary haitus from work but what's the standard supposed
>>> to be?
>>
>> I've checked all upstreamed platform modules (arch/x86/platform/intel-
>> mid/device_libs/) and noticed that not a single one returns ERR_PTR.
>>
>> Though I think the idea was to provide a way to fail initialization in
>> some cases where hardware must be initialized properly. Maybe David or
>> Sathya can shed a light on this.
>>
>> If we decide to change that it should be done for all so called device
>> handlers in sfi.c.
>>
>> --
>> Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Intel Finland Oy
>
next prev parent reply other threads:[~2016-08-30 11:06 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 19:23 [bug report] x86/sfi: Enable enumeration of SD devices Dan Carpenter
2016-08-09 15:32 ` Andy Shevchenko
2016-08-09 17:58 ` Dan Carpenter
2016-08-28 13:31 ` Andy Shevchenko
2016-08-29 20:59 ` Kuppuswamy, Sathyanarayanan
2016-08-30 9:46 ` Andy Shevchenko
2016-08-30 11:06 ` walter harms [this message]
2016-08-30 11:13 ` Andy Shevchenko
2016-08-30 18:18 ` Sathyanarayanan Kuppuswamy
2016-09-07 1:04 ` [PATCH 1/1] intel-mid: Fix sfi get_platform_data() return value issues Kuppuswamy Sathyanarayanan
2016-09-07 1:04 ` Kuppuswamy Sathyanarayanan
2016-09-07 12:15 ` Andy Shevchenko
2016-09-07 12:15 ` Andy Shevchenko
2016-09-08 0:04 ` sathyanarayanan kuppuswamy
2016-09-08 0:04 ` sathyanarayanan kuppuswamy
2016-09-08 9:49 ` Andy Shevchenko
2016-09-08 9:49 ` Andy Shevchenko
2016-09-08 0:05 ` [PATCH v2 " Kuppuswamy Sathyanarayanan
2016-09-08 0:05 ` Kuppuswamy Sathyanarayanan
2016-09-08 12:51 ` Andy Shevchenko
2016-09-08 12:51 ` Andy Shevchenko
2016-09-08 22:41 ` sathyanarayanan kuppuswamy
2016-09-08 22:41 ` sathyanarayanan kuppuswamy
2016-09-09 11:20 ` Andy Shevchenko
2016-09-09 11:20 ` Andy Shevchenko
2016-09-09 2:07 ` [PATCH v3 1/3] " Kuppuswamy Sathyanarayanan
2016-09-09 2:07 ` Kuppuswamy Sathyanarayanan
2016-09-09 2:07 ` [PATCH v3 2/3] intel-mid: Add valid error messages on init failure Kuppuswamy Sathyanarayanan
2016-09-09 2:07 ` Kuppuswamy Sathyanarayanan
2016-09-09 11:27 ` Andy Shevchenko
2016-09-09 11:27 ` Andy Shevchenko
2016-09-09 2:07 ` [PATCH v3 3/3] intel-mid: Move boundry check to the start of init code Kuppuswamy Sathyanarayanan
2016-09-09 2:07 ` Kuppuswamy Sathyanarayanan
2016-09-09 11:30 ` Andy Shevchenko
2016-09-09 11:30 ` Andy Shevchenko
2016-09-01 13:17 ` [bug report] x86/sfi: Enable enumeration of SD devices Andy Shevchenko
2016-09-07 0:51 ` Sathyanarayanan Kuppuswamy
2016-09-07 12:00 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57C568AD.1010703@bfs.de \
--to=wharms@bfs.de \
--cc=kernel-janitors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.