From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
wharms@bfs.de
Cc: dan.carpenter@oracle.com, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org, david.a.cohen@linux.intel.com
Subject: Re: [PATCH v2 1/1] intel-mid: Fix sfi get_platform_data() return value issues
Date: Thu, 08 Sep 2016 12:51:35 +0000 [thread overview]
Message-ID: <1473339095.11323.112.camel@linux.intel.com> (raw)
In-Reply-To: <1473293103-78682-1-git-send-email-sathyanarayanan.kuppuswamy@linux.intel.com>
On Wed, 2016-09-07 at 17:05 -0700, Kuppuswamy Sathyanarayanan wrote:
> According to the intel_mid_sfi_get_pdata() function definition,
"function" is implied, remove the word.
> get_platform_data() function
Ditto.
> should returns NULL on no platform
returns -> return
> data scenario and return ERR_PTR on platform data initialization
> failures. But current device platform initialization code does not
> follow this requirement. This patch fixes the return values issues
> in various sfi device libs code.
sfi -> SFI
Looking into patch I would consider to split it to series:
1. Rewrite GPIO expander logic to cover dynamic allocation. You have to
check how it supposed to be in GPIO framework. IIRC gpio_base = -1
(perhaps a defined constant) will do the trick.
2. Fix the actual return codes (maybe with changes to sfi.c).
3. Fix and add error messages.
4+ (in the future) Address code duplication
> --- a/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
> @@ -29,9 +29,9 @@ static void __init *max7315_platform_data(void
> *info)
> char intr_pin_name[SFI_NAME_LEN + 1];
>
> if (nr = MAX7315_NUM) {
> - pr_err("too many max7315s, we only support %d\n",
> - MAX7315_NUM);
> - return NULL;
> + pr_err("%s: too many max7315s, we only support %d\n",
> + __func__, MAX7315_NUM);
Use the same as for PCAL9555A:
pr_err("%s: Too many instances, only %d supported\n",
> @@ -48,8 +48,12 @@ static void __init *max7315_platform_data(void
> *info)
> gpio_base = get_gpio_by_name(base_pin_name);
> intr = get_gpio_by_name(intr_pin_name);
>
> - if (gpio_base < 0)
> + if (gpio_base < 0) {
> + pr_err("%s: Unknown GPIO base number, falling back
> to"
> + "dynamic allocation\n", __func__);
Don't split literals.
pr_err("...long literal...\n",
args...);
No. This not just the message you show and abort initialization, in case
of dynamic allocation you have to proceed initialization.
> index ee22864..4b33aab 100644
> --- a/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
> @@ -14,15 +14,21 @@
>
> i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
> +
> return NULL;
This change doesn't belong to the series.
> }
>
> diff --git a/arch/x86/platform/intel-
> mid/device_libs/platform_pcal9555a.c b/arch/x86/platform/intel-
> mid/device_libs/platform_pcal9555a.c
> index 429a941..190b2d2 100644
> --- a/arch/x86/platform/intel-mid/device_libs/platform_pcal9555a.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_pcal9555a.c
> @@ -41,13 +41,16 @@ static void __init *pcal9555a_platform_data(void
> *info)
> intr = get_gpio_by_name(intr_pin_name);
>
> /* Check if the SFI record valid */
> - if (gpio_base = -1)
> + if (gpio_base = -1) {
> + pr_err("%s: Unknown GPIO base number, falling back to
> dynamic"
> + "allocation\n", __func__);
> return NULL;
Same comment as above for gpio_base.
>
> --- a/arch/x86/platform/intel-mid/device_libs/platform_tca6416.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_tca6416.c
> @@ -34,8 +34,12 @@ static void *tca6416_platform_data(void *info)
> gpio_base = get_gpio_by_name(base_pin_name);
> intr = get_gpio_by_name(intr_pin_name);
>
> - if (gpio_base < 0)
> + if (gpio_base < 0) {
> + pr_err("%s: Unknown GPIO base number, falling back to
> dynamic"
> + "allocation\n", __func__);
Ditto.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
wharms@bfs.de
Cc: dan.carpenter@oracle.com, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org, david.a.cohen@linux.intel.com
Subject: Re: [PATCH v2 1/1] intel-mid: Fix sfi get_platform_data() return value issues
Date: Thu, 08 Sep 2016 15:51:35 +0300 [thread overview]
Message-ID: <1473339095.11323.112.camel@linux.intel.com> (raw)
In-Reply-To: <1473293103-78682-1-git-send-email-sathyanarayanan.kuppuswamy@linux.intel.com>
On Wed, 2016-09-07 at 17:05 -0700, Kuppuswamy Sathyanarayanan wrote:
> According to the intel_mid_sfi_get_pdata() function definition,
"function" is implied, remove the word.
> get_platform_data() function
Ditto.
> should returns NULL on no platform
returns -> return
> data scenario and return ERR_PTR on platform data initialization
> failures. But current device platform initialization code does not
> follow this requirement. This patch fixes the return values issues
> in various sfi device libs code.
sfi -> SFI
Looking into patch I would consider to split it to series:
1. Rewrite GPIO expander logic to cover dynamic allocation. You have to
check how it supposed to be in GPIO framework. IIRC gpio_base = -1
(perhaps a defined constant) will do the trick.
2. Fix the actual return codes (maybe with changes to sfi.c).
3. Fix and add error messages.
4+ (in the future) Address code duplication
> --- a/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_max7315.c
> @@ -29,9 +29,9 @@ static void __init *max7315_platform_data(void
> *info)
> char intr_pin_name[SFI_NAME_LEN + 1];
>
> if (nr == MAX7315_NUM) {
> - pr_err("too many max7315s, we only support %d\n",
> - MAX7315_NUM);
> - return NULL;
> + pr_err("%s: too many max7315s, we only support %d\n",
> + __func__, MAX7315_NUM);
Use the same as for PCAL9555A:
pr_err("%s: Too many instances, only %d supported\n",
> @@ -48,8 +48,12 @@ static void __init *max7315_platform_data(void
> *info)
> gpio_base = get_gpio_by_name(base_pin_name);
> intr = get_gpio_by_name(intr_pin_name);
>
> - if (gpio_base < 0)
> + if (gpio_base < 0) {
> + pr_err("%s: Unknown GPIO base number, falling back
> to"
> + "dynamic allocation\n", __func__);
Don't split literals.
pr_err("...long literal...\n",
args...);
No. This not just the message you show and abort initialization, in case
of dynamic allocation you have to proceed initialization.
> index ee22864..4b33aab 100644
> --- a/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
> @@ -14,15 +14,21 @@
>
> i2c_info->irq = intr + INTEL_MID_IRQ_OFFSET;
> +
> return NULL;
This change doesn't belong to the series.
> }
>
> diff --git a/arch/x86/platform/intel-
> mid/device_libs/platform_pcal9555a.c b/arch/x86/platform/intel-
> mid/device_libs/platform_pcal9555a.c
> index 429a941..190b2d2 100644
> --- a/arch/x86/platform/intel-mid/device_libs/platform_pcal9555a.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_pcal9555a.c
> @@ -41,13 +41,16 @@ static void __init *pcal9555a_platform_data(void
> *info)
> intr = get_gpio_by_name(intr_pin_name);
>
> /* Check if the SFI record valid */
> - if (gpio_base == -1)
> + if (gpio_base == -1) {
> + pr_err("%s: Unknown GPIO base number, falling back to
> dynamic"
> + "allocation\n", __func__);
> return NULL;
Same comment as above for gpio_base.
>
> --- a/arch/x86/platform/intel-mid/device_libs/platform_tca6416.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_tca6416.c
> @@ -34,8 +34,12 @@ static void *tca6416_platform_data(void *info)
> gpio_base = get_gpio_by_name(base_pin_name);
> intr = get_gpio_by_name(intr_pin_name);
>
> - if (gpio_base < 0)
> + if (gpio_base < 0) {
> + pr_err("%s: Unknown GPIO base number, falling back to
> dynamic"
> + "allocation\n", __func__);
Ditto.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2016-09-08 12:51 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
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 [this message]
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=1473339095.11323.112.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=dan.carpenter@oracle.com \
--cc=david.a.cohen@linux.intel.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=wharms@bfs.de \
/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.