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
next prev parent reply other threads:[~2015-07-29 16:38 UTC|newest]
Thread overview: 53+ 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: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 11:07 ` Matt Fleming
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: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 18:51 ` Guenter Roeck
2015-07-29 7:30 ` Lee Jones
2015-07-29 9:04 ` Jean Delvare
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: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-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
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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox