linux-kernel - Re: [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Jul 2015 09:38:08 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Aaron Sierra <asierra@...-inc.com>,
	Lee Jones <lee.jones@...aro.org>
CC:	Matt Fleming <matt@...eblueprint.co.uk>,
	Wim Van Sebroeck <wim@...ana.be>,
	linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Jean Delvare <jdelvare@...e.com>,
	Wolfram Sang <wsa@...-dreams.de>,
	Matt Fleming <matt.fleming@...el.com>,
	Peter Tyser <ptyser@...-inc.com>,
	Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform
 data

On 07/29/2015 09:20 AM, Aaron Sierra wrote:
>> From: "Lee Jones" <lee.jones@...aro.org>
>> Sent: Wednesday, July 29, 2015 10:32:26 AM
>>
>> On Wed, 29 Jul 2015, Aaron Sierra wrote:
>>
>>>> From: "Lee Jones" <lee.jones@...aro.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/