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

Message-ID: <5112FC44.2000303@linux.intel.com>
Date:	Wed, 06 Feb 2013 16:58:44 -0800
From:	Darren Hart <dvhart@...ux.intel.com>
To:	"lkml, " <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Denis Turischev <denis@...pulab.co.il>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: gpio-sch GPIO_SYSFS access

I'm working with a TunnelCreek + EG20T platform which has two GPIO drivers:

gpio-sch - for the CPU GPIO lines
gpio-pch - for the EG20T GPIO lines

I can see the PCH GPIO lines in /sys/class/gpio, but not the CPU lines:

# dmesg | grep -i gpio
pch_gpio 0000:03:00.2: enabling device (0000 -> 0002)

gpiochip_find_base: found new base at 244

gpiochip_add: registered GPIOs 244 to 255 on device: 0000:03:00.2

gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core

gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume

gpio_request: gpio-0 (sysfs) status -22

gpio_request: gpio-243 (sysfs) status -22

gpio_request: gpio-256 (sysfs) status -22

# ls /sys/class/gpio
export       gpiochip244  unexport

I can export 244-255 and manipulate and read them through the
sys interface. I cannot seem to access 0-13, although the dmesg
above seems to have successfully added them (and the core/resume
pin mapping is correct for a TunnelCreek CPU).

I'm not seeing any obvious difference in how the two drivers probe and
setup the chip that explains why one is accessible and the other is not.

I've enabled the following GPIO CONFIG* options:
$ cat config-minnow.gpio | grep -e "^CONFIG_.*GPIO"
CONFIG_GENERIC_GPIO=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_SPI_GPIO=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_SCH=y
CONFIG_GPIO_PCH=y
CONFIG_LEDS_GPIO=y

I'm working with 3.4.26, but I have not seen anything in the gpio-sch.c
driver commit log that would suggest a fix has landed. I suspect I am
missing something fundamental about how these lines get exported.

Any ideas on what I might be missing?

Is it that some other driver has claimed these GPIO lines? If so, how do
I determine which one?

Thanks!

-- 
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/