Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753848AbbG2QiP (ORCPT ); Wed, 29 Jul 2015 12:38:15 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:46336 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752670AbbG2QiM (ORCPT ); Wed, 29 Jul 2015 12:38:12 -0400 Message-ID: <55B90170.6080000@roeck-us.net> Date: Wed, 29 Jul 2015 09:38:08 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Aaron Sierra , Lee Jones CC: Matt Fleming , Wim Van Sebroeck , linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org, Mika Westerberg , Andy Shevchenko , Jean Delvare , Wolfram Sang , Matt Fleming , Peter Tyser , Samuel Ortiz Subject: Re: [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform data References: <1438004292-16382-1-git-send-email-matt@codeblueprint.co.uk> <20150728094643.GT14943@x1> <20150728110717.GH2492@codeblueprint.co.uk> <20150728113721.GU14943@x1> <72454140.319490.1438109162683.JavaMail.zimbra@xes-inc.com> <20150729073841.GF2284@x1> <2115196252.256986.1438181571315.JavaMail.zimbra@xes-inc.com> <20150729153226.GB9319@x1> <1571539887.303369.1438186805578.JavaMail.zimbra@xes-inc.com> In-Reply-To: <1571539887.303369.1438186805578.JavaMail.zimbra@xes-inc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4334 Lines: 112 On 07/29/2015 09:20 AM, Aaron Sierra wrote: >> From: "Lee Jones" >> Sent: Wednesday, July 29, 2015 10:32:26 AM >> >> On Wed, 29 Jul 2015, Aaron Sierra wrote: >> >>>> From: "Lee Jones" >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/