linux-kernel - Re: ad714x driver help and possible bug

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: <4DBA8AFE.6080807@cam.ac.uk>
Date:	Fri, 29 Apr 2011 10:55:10 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Jean-Francois Dagenais <jeff.dagenais@...il.com>
CC:	Barry Song <21cnbao@...il.com>, linux-kernel@...r.kernel.org,
	"device-drivers-devel@...ckfin.uclinux.org" 
	<device-drivers-devel@...ckfin.uclinux.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>
Subject: Re: ad714x driver help and possible bug

Cc'd input, and analog devices driver list...

On 04/28/11 19:17, Jean-Francois Dagenais wrote:
> Hi all,
> 
> I am having trouble getting the ad714x (i2c) driver to work in my
> test setup. I am using the VGA i2c bus to talk to the ad7147 I have.
> I used INTA of a PCI ethernet slot in my PC. I enabled the PCI device
> without the driver module loaded.  I then give the interrupt number
> to ad714x through the struct i2c_board_info. I actually tried the
> same setup on two PCs, one intel graphics, the other nvidia to
> eliminate the i2c master as a possible cause of my problem.
> 
> The device is successfully loaded and I can see the interrupts going.
> The eventN device created under /dev/input never spit out anything
> and so I added printks in the threaded ISR handler to see what is
> going on.
> 
> I only have a wheel with 8 stages. In ad714x_wheel_state_machine() I
> see that upon the first interrupt, the state goes from IDLE to
> JITTER. After this the JITTER case checks that c_state == mask (with
> mask being 0xff in our case). This condition is never met and the
> driver stays indefinitely in this state. After lifting my finger from
> the wheel, the chip settles down to scanning every so many
> milliseconds.
> 
> The STAGE_COMPLETE_INT_STATUS is always 0 when my finger is off, but
> varies a lot while my finger is on (while interrupt frequency is
> high). Looking at the value of STAGE_COMPLETE_INT_STATUS in binary
> reveals that the set bits are always in groups, e.g. 0x0007 or 0x001C
> or 0x0081(I imagine a roll-over of our start_stage-end_stage (0-7)).
> There seems to be a timing aspect here. I added a spin counter in the
> threaded ISR to delay reading the 3 registers and that seemed to make
> the c_state change a little.
> 
> I modified the code that reads the 3 registers right after the
> mutex_lock in ad714x_interrupt_thread so that the
> STAGE_COMPLETE_INT_STATUS is read before the other two (LOW and HIGH
> regs). The result was surprising. The COMPLETE reg did read 0xff now
> and the JITTER case went past the "if(c_state == mask)" but later
> crashed (divide by 0) in ad714x_wheel_cal_abs_pos() called from the
> JITTER case.
> 
> 
> Here's the initial configuration I give the driver:
> 
> static struct ad714x_wheel_plat wheel_platform_data = {
> 	.start_stage = 0, // int start_stage;
> 	.end_stage = 7, // int end_stage;
> 	.max_coord = 128,  // int max_coord;
> };
> 
> static struct ad714x_platform_data wheel_dev_platform_data = {
> 	.slider_num = 0,
> 	.wheel_num = 1,
> 	.touchpad_num = 0,
> 	.button_num = 0,
> 	.slider = 0,
> 	.wheel = &wheel_platform_data, // struct ad714x_wheel_plat *wheel;
> 	.touchpad = 0, // struct ad714x_touchpad_plat *touchpad;
> 	.button = 0, // struct ad714x_button_plat *button;
> 	.stage_cfg_reg =  { /* unsigned short stage_cfg_reg[STAGE_NUM][STAGE_CFGREG_NUM] */
> 		{0xfffe, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xfffb, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xffef, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xffbf, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xfeff, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xfbff, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xefff, 0x3fff, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 		{0xffff, 0x3ffe, 0, 0x2626, 0x3e8, 0x3e8, 0x1388, 0x1388 },
> 
> 		{0xffff, 0x3fff, 0, 0x0606, 0x01f4, 0x01f4, 0x0320, 0x0320},
> 		{0xffff, 0x3fff, 0, 0x0606, 0x01f4, 0x01f4, 0x0320, 0x0320},
> 		{0xffff, 0x3fff, 0, 0x0606, 0x01f4, 0x01f4, 0x0320, 0x0320},
> 		{0xffff, 0x3fff, 0, 0x0606, 0x01f4, 0x01f4, 0x0320, 0x0320},
> 	},
> 	.sys_cfg_reg = {0x027e, 0x00ff, 0x3233, 0x0819, 0x0832, 0x0000, 0x00ff, 0}, /* unsigned short sys_cfg_reg[SYS_CFGREG_NUM] */
> 	//.sys_cfg_reg = {0x2b2, 0xfff, 0x3233, 0x819, 0x832, 0xcff, 0xcff, 0x0}, /* unsigned short sys_cfg_reg[SYS_CFGREG_NUM] */
> };
> 

> 
> I also had to change the request_threaded_irq flags to specify
> IRQF_ONESHOT so the kernel keeps the interrupt masked while we are
> running ad714x_interrupt_thread(). Otherwise we were getting storms
> of interrupts each time only one was requested. I am wondering if
> this should be pulled back to the mainline kernel?
> 
> Thanks for pointers and clues!
> 

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