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: <559FCD23.2060807@ti.com>
Date:	Fri, 10 Jul 2015 16:48:19 +0300
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Alexander Sverdlin <alexander.sverdlin@...ia.com>,
	ext Vignesh R <vigneshr@...com>,
	Wolfram Sang <wsa@...-dreams.de>, Felipe Balbi <balbi@...com>
CC:	Tony Lindgren <tony@...mide.com>, <linux-omap@...r.kernel.org>,
	<linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] i2c: busses: i2c-omap: Increase timeout for i2c interrupt

On 07/10/2015 04:26 PM, Alexander Sverdlin wrote:
> Hi!
> 
> On 10/07/15 15:17, ext Vignesh R wrote:
>>>> I would propose you to throw away spinlocks. Convert threaded IRQ to

Agree. Looks like spinlock is not needed.

>>>>>> just one hardirq handler. And continue debugging. You will reduce the
>>>>>> load of the system with the above measures, maybe it will not happen
>>>>>> any more, maybe you'll figure out that problem is somewhere else.
>>>>
>>>> Or this.
>> I am not convinced with moving entire code at hardirq context. I believe
>> its better to keep hardirq as small as possible.
> 
> How deep is the controller's FIFO? 1 byte? 2 bytes? Other drivers can perfectly fill
> next byte in hardirq handler. If you need to do 10 opcodes more in hardirq handler,
> it's much better for the whole system than to trigger scheduler and thread and and and
> just because of these 10 opcodes.
> 

1) TRM: Built-in configurable FIFOs (8, 16, 32, 64 bytes) for buffered read or write.
2) We trying to be as much compatible with RT kernel as possible where all IRQ
are threaded.

And yes. This patch is u.. WA which tries to fix symptom and not an issue.

-- 
regards,
-grygorii
--
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