linux-kernel - Re: [PATCH 0/2] spi: Add support for non-blocking synchronous transfers

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: <200902281233.50612.david-b@pacbell.net>
Date:	Sat, 28 Feb 2009 12:33:50 -0800
From:	David Brownell <david-b@...bell.net>
To:	Balaji Rao <balajirrao@...nmoko.org>
Cc:	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net,
	Andy Green <andy@...nmoko.com>
Subject: Re: [PATCH 0/2] spi: Add support for non-blocking synchronous transfers

Note that $SUBJECT concept is nonsense.
Synchronous calls are by definition blocking ones...

On Saturday 28 February 2009, Balaji Rao wrote:
> During the course of development of an accelerometer driver, we saw the
> necessity to execute spi transfers synchronously within an interrupt handler.

This sounds like a bad design.  How can you know that no other
transfers are going on ... or are queued in front of the transfer
you're requesting?

You'd need to wait for all the other transfers to work their
way through the transfer queue.  There are *much* better things
to do in interrupt handlers.

> When using a workqueue instead, we observed a huge number of overruns
> with very high cpu utlization, which is unacceptable.

Sure, but at least part of that seems to be caused by some
broken design assumptions.

Why are you even trying to touch SPI devices from hardirq
context?  That's never going to be OK; "can't-sleep" contexts
don't mix with "must-sleep" calls.

> This series adds a new interface for this and modifies no existing ones.

NAK on these two patches.

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