All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: 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: Fri, 09 Sep 2016 11:20:14 +0000	[thread overview]
Message-ID: <1473420014.11323.119.camel@linux.intel.com> (raw)
In-Reply-To: <32bf3578-ec96-b043-67a1-7c6defb8c88c@linux.intel.com>

On Thu, 2016-09-08 at 15:41 -0700, sathyanarayanan kuppuswamy wrote:

> 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
> I checked the expander driver logic. As long as we return platform
> data 
> as NULL, it by default falls back to dynamic allocation. So I think 
> returning NULL on gpio_base = -1 is itself enough to support the 
> dynamic allocation.
> 
> file: a/drivers/gpio/gpio-pca953x.c
> 
> 755         pdata = dev_get_platdata(&client->dev);
> 756         if (pdata) {
> 757                 irq_base = pdata->irq_base;
> 758                 chip->gpio_start = pdata->gpio_base;
> 759                 invert = pdata->invert;
> 760                 chip->names = pdata->names;
> 761         } else {
> 762                 chip->gpio_start = -1;
> 763                 irq_base = 0;
> 764         }

Yes, but we get 2 parameters: IRQ line (if used) and gpio_base.
And I dunno how to proceed if we have gpio_base not set and IRQ line is
set.

So, it needs a comment what we will do. Currently it says that "Check if
the SFI record valid". So, if it's indeed so, than we can't use even
dynamic allocation.


>>> -	if (gpio_base < 0)
> > > +	if (gpio_base < 0) {
> > > +		pr_err("%s: Unknown GPIO base number, falling
> > > back
> > > to"
> > > +		       "dynamic allocation\n", __func__);
> > 

> > No. This not just the message you show and abort initialization, in
> > case
> > of dynamic allocation you have to proceed initialization.
> How about we go with following warning message. Since using dynamic
> gpio 
> allocation is not an error, I think a warning message is more than 
> enough here. Also , I don't see any value in adding "Unknown gpio
> base 
> number" to the error message. So we can remove it to fit the log
> message 
> into one line.
> 
> +       if (gpio_base = -1) {
> +               pr_warn("%s: falling back to dynamic gpio
> allocation\n",
> +                       __func__);

See above. Perhaps we need to prevent the device driver initialization.

> --- 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.
> Submitting a separate patch to fix this this single style issue seems
> to 
> be over kill. Will it be ok if I add this to my debug message patch ?

For me sounds okay, but what I know most of the maintainers doesn't
approve such changes ("white space" type of patches are most hateful).

So, I would not do this at all.

-- 
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: 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: Fri, 09 Sep 2016 14:20:14 +0300	[thread overview]
Message-ID: <1473420014.11323.119.camel@linux.intel.com> (raw)
In-Reply-To: <32bf3578-ec96-b043-67a1-7c6defb8c88c@linux.intel.com>

On Thu, 2016-09-08 at 15:41 -0700, sathyanarayanan kuppuswamy wrote:

> 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
> I checked the expander driver logic. As long as we return platform
> data 
> as NULL, it by default falls back to dynamic allocation. So I think 
> returning NULL on gpio_base == -1 is itself enough to support the 
> dynamic allocation.
> 
> file: a/drivers/gpio/gpio-pca953x.c
> 
> 755         pdata = dev_get_platdata(&client->dev);
> 756         if (pdata) {
> 757                 irq_base = pdata->irq_base;
> 758                 chip->gpio_start = pdata->gpio_base;
> 759                 invert = pdata->invert;
> 760                 chip->names = pdata->names;
> 761         } else {
> 762                 chip->gpio_start = -1;
> 763                 irq_base = 0;
> 764         }

Yes, but we get 2 parameters: IRQ line (if used) and gpio_base.
And I dunno how to proceed if we have gpio_base not set and IRQ line is
set.

So, it needs a comment what we will do. Currently it says that "Check if
the SFI record valid". So, if it's indeed so, than we can't use even
dynamic allocation.


>>> -	if (gpio_base < 0)
> > > +	if (gpio_base < 0) {
> > > +		pr_err("%s: Unknown GPIO base number, falling
> > > back
> > > to"
> > > +		       "dynamic allocation\n", __func__);
> > 

> > No. This not just the message you show and abort initialization, in
> > case
> > of dynamic allocation you have to proceed initialization.
> How about we go with following warning message. Since using dynamic
> gpio 
> allocation is not an error, I think a warning message is more than 
> enough here. Also , I don't see any value in adding "Unknown gpio
> base 
> number" to the error message. So we can remove it to fit the log
> message 
> into one line.
> 
> +       if (gpio_base == -1) {
> +               pr_warn("%s: falling back to dynamic gpio
> allocation\n",
> +                       __func__);

See above. Perhaps we need to prevent the device driver initialization.

> --- 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.
> Submitting a separate patch to fix this this single style issue seems
> to 
> be over kill. Will it be ok if I add this to my debug message patch ?

For me sounds okay, but what I know most of the maintainers doesn't
approve such changes ("white space" type of patches are most hateful).

So, I would not do this at all.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2016-09-09 11:20 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
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 [this message]
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=1473420014.11323.119.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.