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

Message-ID: <20130208110716.GN5072@sortiz-mobl>
Date:	Fri, 8 Feb 2013 12:07:16 +0100
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Darren Hart <dvhart@...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 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.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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/