<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch/arm, branch v3.7.3</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch/arm?h=v3.7.3</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch/arm?h=v3.7.3'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-01-17T16:46:26Z</updated>
<entry>
<title>ALSA: pxa27x: fix ac97 warm reset</title>
<updated>2013-01-17T16:46:26Z</updated>
<author>
<name>Mike Dunn</name>
<email>mikedunn@newsguy.com</email>
</author>
<published>2013-01-07T21:55:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3e524dfa0c7d0b65569fb403a1702c18ca9561ad'/>
<id>urn:sha1:3e524dfa0c7d0b65569fb403a1702c18ca9561ad</id>
<content type='text'>
commit 3b4bc7bccc7857274705b05cf81a0c72cfd0b0dd upstream.

This patch fixes some code that implements a work-around to a hardware bug in
the ac97 controller on the pxa27x.  A bug in the controller's warm reset
functionality requires that the mfp used by the controller as the AC97_nRESET
line be temporarily reconfigured as a generic output gpio (AF0) and manually
held high for the duration of the warm reset cycle.  This is what was done in
the original code, but it was broken long ago by commit fb1bf8cd
    ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset())
which changed the mfp to a GPIO input instead of a high output.

The fix requires the ac97 controller to obtain the gpio via gpio_request_one(),
with arguments that configure the gpio as an output initially driven high.

Tested on a palm treo 680 machine.  Reportedly, this broken code only prevents a
warm reset on hardware that lacks a pull-up on the line, which appears to be the
case for me.

Signed-off-by: Mike Dunn &lt;mikedunn@newsguy.com&gt;
Signed-off-by: Igor Grinberg &lt;grinberg@compulab.co.il&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>OMAP: board-files: fix i2c_bus for tfp410</title>
<updated>2013-01-17T16:46:08Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-11-22T08:39:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4be6f33ca418c24a214f19a7e2316bba1d1fe921'/>
<id>urn:sha1:4be6f33ca418c24a214f19a7e2316bba1d1fe921</id>
<content type='text'>
commit ca2e16faa7378878c1522a7c1b6c38211de3331d upstream.

The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as invalid/undefined.  Before the patch, 0 was the
invalid value, but as 0 is a valid bus number, the patch changed this to
-1.

However, the fact was missed that many board files do not define the bus
number at all, thus it's left to 0. This causes the driver to fail to
get the i2c bus, exiting from the driver's probe with an error, meaning
that the DVI output does not work for those boards.

This patch fixes the issue by changing the i2c_bus number field in the
driver's platform data from u16 to int, and setting the bus number to -1
in the board files for the boards that did not define the bus. The
exception is devkit8000, for which the bus is set to 1, which is the
correct bus for that board.

The bug exists in v3.5+ kernels.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reported-by: Thomas Weber &lt;thomas@tomweber.eu&gt;
Cc: Thomas Weber &lt;thomas@tomweber.eu&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 7606/1: cache: flush to LoUU instead of LoUIS on uniprocessor CPUs</title>
<updated>2013-01-11T17:19:01Z</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2012-12-19T14:01:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bbe614b3f9a1cab9cdd88ecdd9415bd3dd04efd3'/>
<id>urn:sha1:bbe614b3f9a1cab9cdd88ecdd9415bd3dd04efd3</id>
<content type='text'>
commit d056a699dd3d9366dd3b4d9996e7848209199cda upstream.

flush_cache_louis flushes the D-side caches to the point of unification
inner-shareable. On uniprocessor CPUs, this is defined as zero and
therefore no flushing will take place. Rather than invent a new interface
for UP systems, instead use our SMP_ON_UP patching code to read the
LoUU from the CLIDR instead.

Cc: Lorenzo Pieralisi &lt;Lorenzo.Pieralisi@arm.com&gt;
Tested-by: Guennadi Liakhovetski &lt;g.liakhovetski@gmx.de&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 7607/1: realview: fix private peripheral memory base for EB rev. B boards</title>
<updated>2013-01-11T17:18:54Z</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2012-12-19T14:01:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4faefc4ea2f866e9d924f47eacea45a114b8d0d1'/>
<id>urn:sha1:4faefc4ea2f866e9d924f47eacea45a114b8d0d1</id>
<content type='text'>
commit e6ee4b2b57a8e0d8e551031173de080b338d3969 upstream.

Commit 34ae6c96a6a7 ("ARM: 7298/1: realview: fix mapping of MPCore
private memory region") accidentally broke the definition for the base
address of the private peripheral region on revision B Realview-EB
boards.

This patch uses the correct address for REALVIEW_EB11MP_PRIV_MEM_BASE.

Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Tested-by: Florian Fainelli &lt;florian@openwrt.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: missing -&gt;mmap_sem around find_vma() in swp_emulate.c</title>
<updated>2013-01-11T17:18:54Z</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2012-12-16T00:25:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f41983f43cfa6643ff0d1f1c310d4d3eb3412770'/>
<id>urn:sha1:f41983f43cfa6643ff0d1f1c310d4d3eb3412770</id>
<content type='text'>
commit 7bf9b7bef881aac820bf1f2e9951a17b09bd7e04 upstream.

find_vma() is *not* safe when somebody else is removing vmas.  Not just
the return value might get bogus just as you are getting it (this instance
doesn't try to dereference the resulting vma), the search itself can get
buggered in rather spectacular ways.  IOW, -&gt;mmap_sem really, really is
not optional here.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: mm: use pteval_t to represent page protection values</title>
<updated>2013-01-11T17:18:54Z</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2012-09-18T18:18:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3f6c363d7bf291a026e4c3d2abe1d0767b0468e1'/>
<id>urn:sha1:3f6c363d7bf291a026e4c3d2abe1d0767b0468e1</id>
<content type='text'>
commit 864aa04cd02979c2c755cb28b5f4fe56039171c0 upstream.

When updating the page protection map after calculating the user_pgprot
value, the base protection map is temporarily stored in an unsigned long
type, causing truncation of the protection bits when LPAE is enabled.
This effectively means that calls to mprotect() will corrupt the upper
page attributes, clearing the XN bit unconditionally.

This patch uses pteval_t to store the intermediate protection values,
preserving the upper bits for 64-bit descriptors.

Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2012-11-30T18:30:34Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-11-30T18:30:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=73efd00d473118297cc8ecbdd54429d5f6c6f241'/>
<id>urn:sha1:73efd00d473118297cc8ecbdd54429d5f6c6f241</id>
<content type='text'>
Pull ARM SoC fixes from Arnd Bergmann:
 "These are three fixes for the Marvell EBU family and one for the
  Samsung s3c platforms.  All of them are obvious should still make it
  into 3.7."

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: Kirkwood: Update PCI-E fixup
  Dove: Fix irq_to_pmu()
  Dove: Attempt to fix PMU/RTC interrupts
  ARM: S3C24XX: Fix potential NULL pointer dereference error
</content>
</entry>
<entry>
<title>Merge tag 'ixp4xx-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2012-11-30T18:28:09Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-11-30T18:28:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=90bf80a1f110426433d6d3e77f5143b58b41165c'/>
<id>urn:sha1:90bf80a1f110426433d6d3e77f5143b58b41165c</id>
<content type='text'>
Pull ARM ixp4xx bug fixes from Arnd Bergmann:
 "These were originally prepared by Krzysztof Halasa but not submitted
  in time for v3.7 due to some confusion about how ixp4xx patches should
  be handled.  Jason Cooper thankfully offered to help out sending the
  patches upstream through arm-soc now, but given the timing, we could
  as well delay them for 3.8."

* tag 'ixp4xx-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  IXP4xx: use __iomem for MMIO
  IXP4xx: map CPU config registers within VMALLOC region.
  IXP4xx: Always ioremap() Queue Manager MMIO region at boot.
  ixp4xx: Declare MODULE_FIRMWARE usage
  IXP4xx crypto: MOD_AES{128,192,256} already include key size.
  WAN: Remove redundant HDLC info printed by IXP4xx HSS driver.
  IXP4xx: Remove time limit for PCI TRDY to enable use of slow devices.
  IXP4xx: ixp4xx_crypto driver requires Queue Manager and NPE drivers.
  IXP4xx: HW pseudo-random generator is available on IXP45x/46x only.
  IXP4xx: Fix off-by-one bug in Goramo MultiLink platform.
  IXP4xx: Fix Goramo MultiLink platform compilation.
</content>
</entry>
<entry>
<title>Merge branch 'v3.7-samsung-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes</title>
<updated>2012-11-29T14:07:27Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2012-11-29T14:07:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9434d24b11ccceeb39522965593ef2ddc9eb4e7c'/>
<id>urn:sha1:9434d24b11ccceeb39522965593ef2ddc9eb4e7c</id>
<content type='text'>
From Kukjin Kim &lt;kgene.kim@samsung.com&gt;:

Samsung fixes for v3.7

* 'v3.7-samsung-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: S3C24XX: Fix potential NULL pointer dereference error

This would have been ok to delay to 3.8 according to Kukjin, but since
it's an obvious bug fix and a potential NULL pointer dereference, it
seem appropriate for a late 3.7 submission.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
<entry>
<title>ARM: 7586/1: sp804: set cpumask to cpu_possible_mask for clock event device</title>
<updated>2012-11-28T09:46:57Z</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2012-11-23T17:55:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ea3aacf5f22c1002cac97985354658072232e280'/>
<id>urn:sha1:ea3aacf5f22c1002cac97985354658072232e280</id>
<content type='text'>
The SP804 driver statically initialises the cpumask of the clock event
device to be cpu_all_mask, which is derived from the compile-time
constant NR_CPUS. This breaks SMP_ON_UP systems where the interrupt
controller handling the sp804 doesn't have the irq_set_affinity callback
on the irq_chip, because the common timer code fails to identify the
device as cpu-local and ends up treating it as a broadcast device
instead.

This patch fixes the problem by using cpu_possible_mask at runtime,
which will correctly represent the possible CPUs when SMP_ON_UP is being
used.

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
</feed>
