linux-kernel - Re: gpio-sch GPIO

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] [day] [month] [year] [list]

Message-ID: <51153953.8010608@linux.intel.com>
Date:	Fri, 08 Feb 2013 09:43:47 -0800
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Samuel Ortiz <sameo@...ux.intel.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	"lkml," <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Denis Turischev <denis@...pulab.co.il>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: gpio-sch GPIO_SYSFS access

On 02/08/2013 03:07 AM, Samuel Ortiz wrote:
> On Fri, Feb 08, 2013 at 02:36:16AM -0800, Darren Hart wrote:
>> On 02/08/2013 12:49 AM, Samuel Ortiz wrote:
>>>> Well, this happens when the driver in question gets removed by another
>>>> driver. 
>>> removed by another driver ? I'm not sure I understand what that means.
>>
>> In my case, the gpio-sch probe function runs and creates the gpiochip
>> with 14 GPIO lines. Later lpc-sch probe runs, 
> That's weird: The lpc-sch probe should run first. Then the gpio-sch probe
> should be called when lpc-sch adds the MFD cells as platform devices, from
> lpc_sch_probe().
> So someone is adding gpio-sch as a platform device, and that is wrong.
> 
>> adds devices to the mfd
>> device list, fails the WDT base address as described below, and then
>> removes the devices in the mfd device list, which triggers the removal
>> of the gpio-sch device.
>>
>> If I just skip the WDT lookup and not abort, then things work as I had
>> expected. Sooo... does it make sense to remove ALL the MFD device when
>> the read of the WDTBA registers indicates "Disabled"? Seems extreme to me.
> Yes, that's a bit rough. But I think you have a more fundamental problem where
> you're probing both LPC and your GPIO driver.
> 
>>>> Samuel, does it make sense for CONFIG_GPIO_SCH to require
>>>> CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
>>>> There is no SCH as I understand things. Can these be decoupled?
>>> They actually don't have code dependency, GPIO_SCH selects LPC_SCH beacause
>>> the MFD parts actually creates the GPIO device.
>>> So you're saying Queensbay use the same GPIO IP block without actually having
>>> SCH ?
>>
>> That is how I currently understand it. These drivers appear to have been
>> originaly written for the Silverthorne (Z5xx) CPUs and the Intel SCH
>> chipset.
> If your lpc_sch_probe routine runs, you basically have an LPC on your PCI bus
> here. As I said, PCI probes lpc_sch _and_ gpio_sch is probed as well (As a
> platform device, probably coming from your SFI tables or so). Probing both is
> problematic, especially since you do have an LPC sitting on your PCI bus.


Upon closer inspection what is really happening is the lpc_sch probe
runs and adds the sch_gpio device with the mfd_add_devices call which
creates the platform device. At that time the gpio_sch probe runs and
sets up the gpio stuff. Control returns to the lpc_sch which then tries
to find the WDT, fails, and removes all the mfd devices it had added
previously.

I'm working with firmware (UEFI, ACPI - not SFI) on why WDTBA is 0, but
in the meantime I'll work up a patch to not destroy all the valid devices
when that one fails.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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/