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: <511448A8.8000509@linux.intel.com>
Date:	Thu, 07 Feb 2013 16:36:56 -0800
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	"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/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@...ux.intel.com> wrote:
> 
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
> 
> Yes I think that could be it, the driver would need to call
> gpio_export() for it to also be accessible in sysfs.
> 
> Configure in debugfs and check the file "gpio" in debugfs
> to figure out the client.

I added dynamic printk and queried the relevant files. I didn't see any
dev_* or pr_* messages.

# dmesg | grep -i gpio
Kernel command line: BOOT_IMAGE=/vmlinuz root=/dev/sda2
console=ttyPCH0,115200 cons
ole=tty0 vmalloc=256MB "dyndbg=file gpiolib.c +p;file gpio-sch.c +p;
file gpio-pch.
c +p" dynamic_debug.verbose=1 debug loglevel=8

dynamic_debug:ddebug_add_module: 17 debug prints in module gpiolib
dynamic_debug:ddebug_add_module: 2 debug prints in module gpio_pch
pch_gpio 0000:02:00.2: enabling device (0000 -> 0002)
gpiochip_find_base: found new base at 244
gpiochip_add: registered GPIOs 244 to 255 on device: 0000:02: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

The GPIO debugfs and SYSFS interfaces only show the GPIO from the PCH,
nothing from the SCH (CPU):

# cat /debug/gpio
GPIOs 244-255, 0000:02:00.2:

# ls /sys/class/gpio/
export       gpiochip244  unexport

Instrumenting gpiochip_export, I see:

gpiochip_export: base=0 ngpio=5 label=sch_gpio_core
gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core

gpiochip_export: base=5 ngpio=9 label=sch_gpio_resume
gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume

So the calls to gpiochip_export for the sch driver are being made, and
my on-error instrumentation did not trigger.

Finally, I do see an "irq 16: nobody cared" with the sch driver as
the handler. It isn't clear to me that this would cause the chip not
to appear in sysfs, but I'm including it here for completeness:

irq 16: nobody cared (try booting with the "irqpoll" option)

Pid: 0, comm: swapper/0 Not tainted 3.4.26-yocto-standard #2

Call Trace:

 [<c1648288>] ? printk+0x2e/0x30

 [<c1093cfa>] __report_bad_irq+0x2a/0xd0
 [<c1389719>] ? add_interrupt_randomness+0x19/0x150

 [<c1093fd4>] note_interrupt+0x174/0x1c0
 [<c1009fbf>] ? cpu_idle+0x1f/0xb0

 [<c1091da2>] handle_irq_event_percpu+0xb2/0x220

 [<c1653fc9>] ? add_preempt_count+0x9/0xb0

 [<c1091f4b>] handle_irq_event+0x3b/0x60

 [<c1094940>] ? unmask_irq+0x30/0x30

 [<c1094990>] handle_fasteoi_irq+0x50/0xe0

 <IRQ>  [<c16576b3>] ? do_IRQ+0x43/0xb0

 [<c1056f04>] ? scheduler_ipi+0x74/0xd0

 [<c16575e9>] ? common_interrupt+0x29/0x30

 [<c1009fbf>] ? cpu_idle+0x1f/0xb0
 [<c1632518>] ? rest_init+0x6c/0x74
 [<c193b71d>] ? start_kernel+0x30c/0x313

 [<c193b243>] ? repair_env_string+0x51/0x51

 [<c193b078>] ? i386_start_kernel+0x78/0x7d

handlers:

[<c130aec0>] pch_gpio_handler

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