All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Aaron Sierra <asierra@xes-inc.com>, Lee Jones <lee.jones@linaro.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
	Wim Van Sebroeck <wim@iguana.be>,
	linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jean Delvare <jdelvare@suse.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	Matt Fleming <matt.fleming@intel.com>,
	Peter Tyser <ptyser@xes-inc.com>,
	Samuel Ortiz <sameo@linux.intel.com>
Subject: Re: [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform data
Date: Wed, 29 Jul 2015 09:38:08 -0700	[thread overview]
Message-ID: <55B90170.6080000@roeck-us.net> (raw)
In-Reply-To: <1571539887.303369.1438186805578.JavaMail.zimbra@xes-inc.com>

On 07/29/2015 09:20 AM, Aaron Sierra wrote:
>> From: "Lee Jones" <lee.jones@linaro.org>
>> Sent: Wednesday, July 29, 2015 10:32:26 AM
>>
>> On Wed, 29 Jul 2015, Aaron Sierra wrote:
>>
>>>> From: "Lee Jones" <lee.jones@linaro.org>
>>>> Sent: Wednesday, July 29, 2015 2:38:41 AM
>>>>
>>>> On Tue, 28 Jul 2015, Aaron Sierra wrote:
>>>>
>>>>>>>>> @@ -933,7 +956,7 @@ gpe0_done:
>>>>>>>>>   	lpc_chipset_info[priv->chipset].use_gpio = ret;
>>>>>>>>>   	lpc_ich_enable_gpio_space(dev);
>>>>>>>>>
>>>>>>>>> -	lpc_ich_finalize_cell(dev, &lpc_ich_cells[LPC_GPIO]);
>>>>>>>>> +	lpc_ich_finalize_gpio_cell(dev);
>>>>>>>>>   	ret = mfd_add_devices(&dev->dev, PLATFORM_DEVID_AUTO,
>>>>>>>>>   			      &lpc_ich_cells[LPC_GPIO], 1, NULL, 0, NULL);
>>>>>>>>>
>>>>>>>>> @@ -1007,7 +1030,10 @@ static int lpc_ich_init_wdt(struct
>>>>>>>>> pci_dev
>>>>>>>>> *dev)
>>>>>>>>>   		res->end = base_addr + ACPIBASE_PMC_END;
>>>>>>>>>   	}
>>>>>>>>>
>>>>>>>>> -	lpc_ich_finalize_cell(dev, &lpc_ich_cells[LPC_WDT]);
>>>>>>>>> +	ret = lpc_ich_finalize_wdt_cell(dev);
>>>>>>>>> +	if (ret)
>>>>>>>>> +		goto wdt_done;
>>>>>>>>> +
>>>>>>>>>   	ret = mfd_add_devices(&dev->dev, PLATFORM_DEVID_AUTO,
>>>>>>>>>   			      &lpc_ich_cells[LPC_WDT], 1, NULL, 0, NULL);
>>>>>>>>
>>>>>>>> Why do you have an mfd_add_devices() call for each device?
>>>>>>>
>>>>>>> Good question. This call has been present since March 2012 when
>>>>>>> support
>>>>>>> was first added for iTCO_wdt in commit 887c8ec7219f ("watchdog:
>>>>>>> Convert
>>>>>>> iTCO_wdt driver to mfd model").
>>>>>>>
>>>>>>> There's no good reason that I can see. Aaron?
>>>>>
>>>>> I chose to call mfd_add_devices() in each device init function
>>>>> because I thought it was the easiest way to avoid registering an
>>>>> incomplete/invalid MFD cell should an error occur during init.
>>>>>
>>>>> That way device registration wouldn't be an all-or-nothing affair.
>>>>>
>>>>> Doesn't mfd_add_devices() bail out after the first unsuccessful
>>>>> mfd to platform device translation?
>>>>
>>>> Right, as it should.
>>>>
>>>> Under what circumstance would an error occur and you'd wish to carry
>>>> on registering devices?
>>>
>>> Lee,
>>>
>>> The two devices that this driver is responsible for are conceptually
>>> independent; they simply are lumped together in one PCI device. No
>>> failure while preparing resources for the watchdog device should
>>> prevent the GPIO device from being registered.
>>
>> This makes me think that perhaps this isn't an MFD at all then?
>>
>> Perhaps I should invest some time to looking into that.
>>
>>> The most common real world circumstance that I experience is when a
>>> BIOS reserves resources associated with the GPIO device, thus
>>> preventing the GPIO resources (ICH_RES_GPE0 and/or ICH_RES_GPIO) from
>>> being fully prepared.
>>>
>>> I have not experienced issues with the watchdog device, but a similar
>>> issue would exist if the RCBA were disabled in a "v2" device.
>>>
>>> It seems like a dangerous change to simply attempt to register both
>>> of these devices with a single call, when one or both of them could
>>> be incomplete.
>>>
>>> Perhaps your real issue with this driver structure is that these
>>> cells are elements of a single lpc_ich_cells array for no clear
>>> reason. If each had a dedicated mfd_cell variable, would that be
>>> more acceptable to you?
>>>
>>> -static struct mfd_cell lpc_ich_cells[] = {
>>> +static struct mfd_cell lpc_ich_wdt_cell = {
>>> ...
>>> +static struct mfd_cell lpc_ich_gpio_cell = {
>>>
>>> That would eliminate the need for the lpc_cells enum, too.
>>
>> Yes, that would make more sense.  Also consider using mfd_add_device()
>> instead of mfd_add_devices(), as you are only attempting registration
>> for a single device.
>>
>
> I can submit a patch the splits up the array elements, but I
> only see mfd_add_device() as a static function in mfd-core.c;
> Is that being exported in a development branch somewhere?
>
Sure you want to do that ? You might have to move usage count
handling into the calling driver, and also provide mfd_remove_device().

Guenter


  reply	other threads:[~2015-07-29 16:38 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 13:38 [PATCH 0/5] iTCO_wdt: Add support for Intel Sunrisepoint Matt Fleming
2015-07-27 13:38 ` [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform data Matt Fleming
2015-07-27 13:49   ` Guenter Roeck
2015-07-27 14:19     ` Matt Fleming
2015-07-27 14:24       ` Guenter Roeck
2015-07-28  9:52         ` Matt Fleming
2015-07-27 15:33   ` Lee Jones
2015-07-27 15:33     ` Lee Jones
2015-07-27 15:45     ` Andy Shevchenko
2015-07-27 20:32     ` Matt Fleming
2015-07-27 21:32       ` Lee Jones
2015-07-28  9:16         ` Matt Fleming
2015-07-28  9:46   ` Lee Jones
2015-07-28  9:46     ` Lee Jones
2015-07-28 11:07     ` Matt Fleming
2015-07-28 11:37       ` Lee Jones
2015-07-28 11:37         ` Lee Jones
2015-07-28 12:43         ` Matt Fleming
2015-07-28 15:00           ` Lee Jones
2015-07-28 15:18             ` Guenter Roeck
2015-07-28 15:28               ` Lee Jones
2015-07-28 15:28                 ` Lee Jones
2015-07-28 15:45                 ` Matt Fleming
2015-07-28 15:56                   ` Lee Jones
2015-07-28 17:08                 ` Guenter Roeck
2015-07-28 17:32                   ` Lee Jones
2015-07-28 17:32                     ` Lee Jones
2015-07-28 18:51                     ` Guenter Roeck
2015-07-29  7:30                       ` Lee Jones
2015-07-29  7:30                         ` Lee Jones
2015-07-29  9:04                     ` Jean Delvare
2015-07-29 10:07                       ` Lee Jones
2015-07-29 10:07                         ` Lee Jones
2015-07-28 18:46         ` Aaron Sierra
2015-07-29  7:38           ` Lee Jones
2015-07-29 14:52             ` Aaron Sierra
2015-07-29 15:32               ` Lee Jones
2015-07-29 15:32                 ` Lee Jones
2015-07-29 15:52                 ` Guenter Roeck
2015-07-30  8:51                   ` Lee Jones
2015-07-29 16:20                 ` Aaron Sierra
2015-07-29 16:38                   ` Guenter Roeck [this message]
2015-07-29 17:00                     ` Aaron Sierra
2015-07-28 16:50     ` Jean Delvare
2015-07-28 16:50       ` Jean Delvare
2015-07-29  7:27       ` Lee Jones
2015-07-29  7:27         ` Lee Jones
2015-07-29  7:29   ` Jean Delvare
2015-07-29 11:09     ` Matt Fleming
2015-07-27 13:38 ` [PATCH 2/5] i2c: i801: Create iTCO device on newer Intel PCHs Matt Fleming
2015-07-27 14:08   ` Guenter Roeck
     [not found]     ` <55B63B48.2040603-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-07-28  9:34       ` Matt Fleming
2015-07-28  9:34         ` Matt Fleming
2015-07-27 13:38 ` [PATCH 3/5] iTCO_wdt: Add support for TCO on Intel Sunrisepoint Matt Fleming
2015-07-27 14:22   ` Guenter Roeck
2015-07-28 10:13     ` Matt Fleming
2015-07-28 17:03   ` Jean Delvare
2015-07-28 17:03     ` Jean Delvare
2015-07-29 10:45     ` Matt Fleming
2015-07-29 10:45       ` Matt Fleming
2015-07-27 13:38 ` [PATCH 4/5] iTCO_wdt: fixup for the header Matt Fleming
2015-07-27 14:13   ` Guenter Roeck
2015-07-28  9:17     ` Matt Fleming
2015-07-27 13:38 ` [PATCH 5/5] i2c-i801: fixup regarding watchdog timer Matt Fleming
2015-07-27 14:14   ` Guenter Roeck
2015-07-28  9:17     ` Matt Fleming

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=55B90170.6080000@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=asierra@xes-inc.com \
    --cc=jdelvare@suse.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mika.westerberg@linux.intel.com \
    --cc=ptyser@xes-inc.com \
    --cc=sameo@linux.intel.com \
    --cc=wim@iguana.be \
    --cc=wsa@the-dreams.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.