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: <AANLkTinw5KDThsSw+2PJMdrPBq1=rMJNVYgF4z5mEJTM@mail.gmail.com>
Date:	Sat, 4 Dec 2010 03:28:49 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	David Daney <ddaney@...iumnetworks.com>
Cc:	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
	Greg KH <greg@...ah.com>, Tony Lindgren <tony@...mide.com>,
	Benoit Cousson <b-cousson@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Hari Kanigeri <h-kanigeri2@...com>, Suman Anna <s-anna@...com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v3 0/4] Introduce hardware spinlock framework

On Sat, Dec 4, 2010 at 2:29 AM, David Daney <ddaney@...iumnetworks.com> wrote:
> Does anything other than OMAP4 have one of these things?

I'm not aware of any, but David Brownell had some ideas about it in
our previous v2 discussion (see
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39413.html).

Btw, you might want to read throughout that entire discussion with
David, since it was touching the same questions you raise here.

> And are there any
> devices that are commonly encountered across more than one platform that
> might have these hardware spinlocks, thus making it advantageous to have a
> common framework?

Such devices are just multiple processors that have no alternative
mechanism to accomplish synchronization.

OMAP4 has a few non-coherent heterogeneous processors that do not
support fancy synchronization primitives, so it needs this hwspinlock
peripheral.

Otherwise, I don't know how common that is (/might become), and I'd
hate speculating, but I suspect that OMAP is not going to be the only
platform with multiple coprocessors, that have no other means of
achieving synchronization, and with which inter-processor
communications is desired.

>
> If not why a general purpose framework for a very chip specific feature?

We started out with an omap-specific driver (see first iteration at
http://lwn.net/Articles/410375/), but were asked to make it a
platform-agnostic framework, in order to keep the IPC drivers that
will use it generic (and assuming that more users will show up for
such framework).

To me it sounds reasonable, but again, I prefer not to speculate how
many users will show up for this, if any.

Both ways (framework / omap-specific driver) will work for us just fine.

>
> There are chips with hardware atomic memory, but the only time it makes
> sense to use it is in conjunction with specialize on-chip devices.  So the
> implementation details are kept in the drivers rather than creating a
> general purpose hwatomic (with its hwatomic_add() et al.) type.

This case is a bit different IMHO: some of the potential users of
hwspinlocks are just generic IPC drivers that are by no means
platform-specific. It's not a special on-chip device: it's just one
processor, trying to achieve mutual exclusion with another processor,
before manipulating some shared data structure.
--
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