linux-kernel - Re: [PATCHv7 1/4] pwm: Add Freescale FTM PWM driver support

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: <20131217125832.GU4360@n2100.arm.linux.org.uk>
Date:	Tue, 17 Dec 2013 12:58:32 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Xiubo Li <Li.Xiubo@...escale.com>, mark.rutland@....com,
	s.hauer@...gutronix.de, galak@...eaurora.org,
	swarren@...dotorg.org, t.figa@...sung.com, grant.likely@...aro.org,
	matt.porter@...aro.org, rob@...dley.net, tomasz.figa@...il.com,
	ian.campbell@...rix.com, pawel.moll@....com,
	rob.herring@...xeda.com, linux-arm-kernel@...ts.infradead.org,
	linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	Alison Wang <b18965@...escale.com>,
	Jingchang Lu <b35083@...escale.com>
Subject: Re: [PATCHv7 1/4] pwm: Add Freescale FTM PWM driver support

On Tue, Dec 17, 2013 at 01:24:33PM +0100, Thierry Reding wrote:
> On Tue, Dec 17, 2013 at 11:51:36AM +0000, Russell King - ARM Linux wrote:
> > Same comments here - what memory operations is the wmb() trying to
> > serialise?  Does this PWM driver somehow end up doing DMA?
> 
> Not that I can see. But if my understanding is correct, not using the
> barriers would allow the compiler and CPU to reorder accesses, and by
> that cause the register accesses to potentially happen in the wrong
> order.

The compiler won't reorder them, but the CPU may if it meets certain
criteria.  The architecture guarantees that accesses to device memory
within a (minimum of) 1KB block will be ordered.

The ARM ARM is slightly ambiguous in how this is applied - in one
place it says that "Accesses must arrive at any particular memory-mapped
peripheral or block of memory in program order" and another part it
says "The size of a memory mapped peripheral, or a block of memory,
is IMPLEMENTATION DEFINED, but is not smaller than 1KByte.  Note
This implies that the maximum memory-mapped peripheral size for which
the architecture guarantees order for all implementations is 1KB."  See
page A3-148.

What this means (to me at least) is that on any SoC, the architecture
guarantees that accesses _within_ a 1KB device memory block will always
be ordered, but two accesses outside of a 1KB block _to the same device_
is implementation defined whether it is ordered or not.

The interesting point here though is that the "note" contradicts the
first definition if you have (eg) AMBA Primecell peripherals which are
generally 4KB in size, since if the architecture only guarantees 1KB,
then accesses _may_ _not_ arrive at one primecell in program order.
Hence, the note is a direct contradiction of the first definition.
--
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/