linux-kernel - Re: [RFC PATCH] i2c: busses: i2c-omap: Increase timeout for i2c interrupt

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: <559FC7E9.1060003@nokia.com>
Date:	Fri, 10 Jul 2015 15:26:01 +0200
From:	Alexander Sverdlin <alexander.sverdlin@...ia.com>
To:	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

Hi!

On 10/07/15 15:17, ext Vignesh R wrote:
>>> I would propose you to throw away spinlocks. Convert threaded IRQ to
>>> >> 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.

-- 
Best regards,
Alexander Sverdlin.
--
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/