Bug 134338 - [patch] Lock GPIO accesses on ixp425
Summary: [patch] Lock GPIO accesses on ixp425
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 7.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-07 17:40 UTC by Gavin Atkinson
Modified: 2013-09-12 13:27 UTC (History)
0 users

See Also:


Attachments
ixp425-gpio-locking.diff (7.68 KB, patch)
2009-05-07 17:40 UTC, Gavin Atkinson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gavin Atkinson freebsd_committer freebsd_triage 2009-05-07 17:40:01 UTC
	There are several points in the code where GPIO registers are read,
various operations are performed with the result, then GPIO registers are
written back to.  The problem here is that there is nothing preventing other
access occuring between the read and the write.  Some parts of the code (IIC)
go one step further and use Giant as a lock around these accesses, but as it
is not done globally, this makes little difference.

I stumbled on this while writing a driver for the NSLU LEDs, while hammering
the driver I saw interrupts being missed.  Whilst I have no absolute proof
that this is the cause, I've not been able to recreate it with this patch
in place.

I've gone for a seperate spin lock for the GPIO pins as it is used in various
contexts where a spin lock seems to be the correct choice.  It's also
implemented as a global lock rather than being stored in a softc or similar -
until there is a GPIO driver, I can't see any better solution.

Something like this is probably also needed for the other arm platforms,
however I do not have the hardware required to test these.

How-To-Repeat: 	(ab)use code paths that toggle GPIO lines (e.g. use IIC heavily while
USB generates interrupts)
Comment 1 Andrew Thompson freebsd_committer freebsd_triage 2010-12-08 00:29:07 UTC
State Changed
From-To: open->patched

Equivalent patch committed in r215319
Comment 2 Gavin Atkinson freebsd_committer freebsd_triage 2013-09-12 13:26:02 UTC
State Changed
From-To: patched->closed

This can now be closed, an equivalent patch was committed some time ago.