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: <563C6BF7.3080406@linux.intel.com>
Date:	Fri, 06 Nov 2015 10:59:35 +0200
From:	Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:	"Yu, Xiangliang" <Xiangliang.Yu@....com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:	"andriy.shevchenko@...ux.intel.com" 
	<andriy.shevchenko@...ux.intel.com>,
	"wsa@...-dreams.de" <wsa@...-dreams.de>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Xue, Ken" <Ken.Xue@....com>, "Wan, Vincent" <Vincent.Wan@....com>,
	"Huang, Ray" <Ray.Huang@....com>,
	"Wang, Annie" <Annie.Wang@....com>, "Li, Tony" <Tony.Li@....com>
Subject: Re: [PATCH 1/1] I2C: designware: fix IO timeout issue for AMD controller

On 06.11.2015 06:34, Yu, Xiangliang wrote:
>> -----Original Message-----
>> From: Mika Westerberg [mailto:mika.westerberg@...ux.intel.com]
>>> --- a/drivers/i2c/busses/i2c-designware-core.c
>>> +++ b/drivers/i2c/busses/i2c-designware-core.c
>>> @@ -783,6 +783,9 @@ irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
>>>
>>>   	stat = i2c_dw_read_clear_intrbits(dev);
>>
>> What if the status changes right here, before you go and mask the interrupt?
> Have no effect, because i2c controller can't trigger next interrupt.
>
Does it mean possible lost interrupt too? I guess it can be debugged by 
placing a few ms long mdelay() between clearing and masking.

How frequent is this timeout? I guess lost interrupt is somehow nearly 
related to clearing, masking and unmasking if that cycle helps. One 
thing that comes to my mind is masking needed and could plain unmasking 
be also a working workaround?

Have you tried to print DW_IC_INTR_STAT, DW_IC_INTR_MASK and 
DW_IC_RAW_INTR_STAT when timeout occurs? E.g. just after printing the 
timeout out error in i2c_dw_xfer(). Probably good in i2c_dw_isr() too if 
if doesn't produce too much data and make debugging impossible.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ