<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/mips, branch v3.6.4</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>MIPS: ath79: Fix CPU/DDR frequency calculation for SRIF PLLs</title>
<updated>2012-10-21T16:32:42+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-09-08T12:02:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c71964b93fde02f9607e49191d55bd430767892c'/>
<id>c71964b93fde02f9607e49191d55bd430767892c</id>
<content type='text'>
commit 97541ccfb9db2bb9cd1dde6344d5834438d14bda upstream.

Besides the CPU and DDR PLLs, the CPU and DDR frequencies
can be derived from other PLLs in the SRIF block on the
AR934x SoCs. The current code does not checks if the SRIF
PLLs are used and this can lead to incorrectly calculated
CPU/DDR frequencies.

Fix it by calculating the frequencies from SRIF PLLs if
those are used on a given board.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4324/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 97541ccfb9db2bb9cd1dde6344d5834438d14bda upstream.

Besides the CPU and DDR PLLs, the CPU and DDR frequencies
can be derived from other PLLs in the SRIF block on the
AR934x SoCs. The current code does not checks if the SRIF
PLLs are used and this can lead to incorrectly calculated
CPU/DDR frequencies.

Fix it by calculating the frequencies from SRIF PLLs if
those are used on a given board.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4324/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mips,kgdb: fix recursive page fault with CONFIG_KPROBES</title>
<updated>2012-10-21T16:32:39+00:00</updated>
<author>
<name>Jason Wessel</name>
<email>jason.wessel@windriver.com</email>
</author>
<published>2012-08-10T17:21:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5224f4e0e077c6c6336dc9640c81ea9799e620a6'/>
<id>5224f4e0e077c6c6336dc9640c81ea9799e620a6</id>
<content type='text'>
commit f0a996eeeda214f4293e234df33b29bec003b536 upstream.

This fault was detected using the kgdb test suite on boot and it
crashes recursively due to the fact that CONFIG_KPROBES on mips adds
an extra die notifier in the page fault handler.  The crash signature
looks like this:

kgdbts:RUN bad memory access test
KGDB: re-enter exception: ALL breakpoints killed
Call Trace:
[&lt;807b7548&gt;] dump_stack+0x20/0x54
[&lt;807b7548&gt;] dump_stack+0x20/0x54

The fix for now is to have kgdb return immediately if the fault type
is DIE_PAGE_FAULT and allow the kprobe code to decide what is supposed
to happen.

Signed-off-by: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Cc: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f0a996eeeda214f4293e234df33b29bec003b536 upstream.

This fault was detected using the kgdb test suite on boot and it
crashes recursively due to the fact that CONFIG_KPROBES on mips adds
an extra die notifier in the page fault handler.  The crash signature
looks like this:

kgdbts:RUN bad memory access test
KGDB: re-enter exception: ALL breakpoints killed
Call Trace:
[&lt;807b7548&gt;] dump_stack+0x20/0x54
[&lt;807b7548&gt;] dump_stack+0x20/0x54

The fix for now is to have kgdb return immediately if the fault type
is DIE_PAGE_FAULT and allow the kprobe code to decide what is supposed
to happen.

Signed-off-by: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Cc: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: ath79: use correct fractional dividers for {CPU,DDR}_PLL on AR934x</title>
<updated>2012-10-12T20:50:26+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-09-01T16:46:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c2bb4485c33a281d9b58e20c811dfe5711ef9f62'/>
<id>c2bb4485c33a281d9b58e20c811dfe5711ef9f62</id>
<content type='text'>
commit 65fc7f9957c52ad4fdf4ee5dfe3a75aa0a633d39 upstream.

The current dividers in the code are wrong and this
leads to broken CPU frequency calculation on boards
where the fractional part is used.

For example, if the SoC is running from a 40MHz
reference clock, refdiv=1, nint=14, outdiv=0 and
nfrac=31 the real frequency is 579.375MHz but the
current code calculates 569.687MHz instead.

Because the system time is indirectly related to
the CPU frequency the broken computation causes
drift in the system time.

The correct divider is 2^6 for the CPU PLL and 2^10
for the DDR PLL. Use the correct values to fix the
issue.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4305/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 65fc7f9957c52ad4fdf4ee5dfe3a75aa0a633d39 upstream.

The current dividers in the code are wrong and this
leads to broken CPU frequency calculation on boards
where the fractional part is used.

For example, if the SoC is running from a 40MHz
reference clock, refdiv=1, nint=14, outdiv=0 and
nfrac=31 the real frequency is 579.375MHz but the
current code calculates 569.687MHz instead.

Because the system time is indirectly related to
the CPU frequency the broken computation causes
drift in the system time.

The correct divider is 2^6 for the CPU PLL and 2^10
for the DDR PLL. Use the correct values to fix the
issue.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4305/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>kbuild: Fix gcc -x syntax</title>
<updated>2012-10-12T20:50:17+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2012-10-02T14:42:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=29f7d41bd8864713f28a63c7706afa7816b8e6e2'/>
<id>29f7d41bd8864713f28a63c7706afa7816b8e6e2</id>
<content type='text'>
commit b1e0d8b70fa31821ebca3965f2ef8619d7c5e316 upstream.

The correct syntax for gcc -x is "gcc -x assembler", not
"gcc -xassembler". Even though the latter happens to work, the former
is what is documented in the manual page and thus what gcc wrappers
such as icecream do expect.

This isn't a cosmetic change. The missing space prevents icecream from
recognizing compilation tasks it can't handle, leading to silent kernel
miscompilations.

Besides me, credits go to Michael Matz and Dirk Mueller for
investigating the miscompilation issue and tracking it down to this
incorrect -x parameter syntax.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Bernhard Walle &lt;bernhard@bwalle.de&gt;
Cc: Michal Marek &lt;mmarek@suse.cz&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b1e0d8b70fa31821ebca3965f2ef8619d7c5e316 upstream.

The correct syntax for gcc -x is "gcc -x assembler", not
"gcc -xassembler". Even though the latter happens to work, the former
is what is documented in the manual page and thus what gcc wrappers
such as icecream do expect.

This isn't a cosmetic change. The missing space prevents icecream from
recognizing compilation tasks it can't handle, leading to silent kernel
miscompilations.

Besides me, credits go to Michael Matz and Dirk Mueller for
investigating the miscompilation issue and tracking it down to this
incorrect -x parameter syntax.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Bernhard Walle &lt;bernhard@bwalle.de&gt;
Cc: Michal Marek &lt;mmarek@suse.cz&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus</title>
<updated>2012-09-22T19:47:53+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-09-22T19:47:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e5e77cf9f9a275083f9a365a20d956fa8a67803e'/>
<id>e5e77cf9f9a275083f9a365a20d956fa8a67803e</id>
<content type='text'>
Pull MIPS fixes from Ralf Baechle:
 "Random fixes across arch/mips, essentially.

  One fix for an issue in get_user_pages_fast() which previously was
  discovered on x86, a miscalculation in the support for the MIPS MT
  hardware multithreading support, the RTC support for the Malta and a
  fix for a spurious interrupt issue that seems to bite only very
  special Malta configurations."

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Malta: Don't crash on spurious interrupt.
  MIPS: Malta: Remove RTC Data Mode bootstrap breakage
  MIPS: mm: Add compound tail page _mapcount when mapped
  MIPS: CMP/SMTC: Fix tc_id calculation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull MIPS fixes from Ralf Baechle:
 "Random fixes across arch/mips, essentially.

  One fix for an issue in get_user_pages_fast() which previously was
  discovered on x86, a miscalculation in the support for the MIPS MT
  hardware multithreading support, the RTC support for the Malta and a
  fix for a spurious interrupt issue that seems to bite only very
  special Malta configurations."

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Malta: Don't crash on spurious interrupt.
  MIPS: Malta: Remove RTC Data Mode bootstrap breakage
  MIPS: mm: Add compound tail page _mapcount when mapped
  MIPS: CMP/SMTC: Fix tc_id calculation
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Malta: Don't crash on spurious interrupt.</title>
<updated>2012-09-17T00:04:29+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2012-09-16T23:23:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e376fdf42062e7373b82093b278f99aa2b547db7'/>
<id>e376fdf42062e7373b82093b278f99aa2b547db7</id>
<content type='text'>
48d480b0bde794781fcae9501fb043c1bac0e523 [[MIPS] Malta: Fix off by one bug in interrupt
handler.] did not take in account that irq_ffs() will also return 0 if for some reason
the set of pending interrupts happens to be empty.

This is trivial to trigger with a RM5261 CPU module running a 64-bit kernel and results
in something like the following:

CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff801772d0, ra == ffffffff8017ad24
Oops[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff9000a4e0 ffffffff9000a4e0 ffffffff9000a4e0
$ 4   : ffffffff80592be0 0000000000000000 00000000000000d6 ffffffff80322ed0
$ 8   : ffffffff805fe538 0000000000000000 ffffffff9000a4e0 ffffffff80590000
$12   : 00000000000000d6 0000000000000000 ffffffff80600000 ffffffff805fe538
$16   : 0000000000000000 0000000000000010 ffffffff80592be0 0000000000000010
$20   : 0000000000000000 0000000000500001 0000000000000000 ffffffff8051e078
$24   : 0000000000000028 ffffffff803226e8
$28   : 9800000003828000 980000000382b900 ffffffff8051e060 ffffffff8017ad24
Hi    : 0000000000000000
Lo    : 0000006388974000
epc   : ffffffff801772d0 handle_irq_event_percpu+0x70/0x2f0
    Not tainted
ra    : ffffffff8017ad24 handle_percpu_irq+0x54/0x88
Status: 9000a4e2    KX SX UX KERNEL EXL
Cause : 00808008
BadVA : 0000000000000000
PrId  : 000028a0 (Nevada)
Modules linked in:
Process init (pid: 1, threadinfo=9800000003828000, task=9800000003827968, tls=0000000077087490)
Stack : ffffffff80592be0 ffffffff8058d248 0000000000000040 0000000000000000
        ffffffff80613340 0000000000500001 ffffffff805a0000 0000000000000882
        9800000003b89000 ffffffff8017ad24 00000000000000d5 0000000000000010
        ffffffff9000a4e1 ffffffff801769f4 ffffffff9000a4e0 ffffffff801037f8
        0000000000000000 ffffffff80101c44 0000000000000000 ffffffff9000a4e0
        0000000000000000 9000000018000000 90000000180003f9 0000000000000001
        0000000000000000 00000000000000ff 0000000000000018 0000000000000001
        0000000000000001 00000000003fffff 0000000000000020 ffffffff802cf7ac
        ffffffff80208918 000000007fdadf08 ffffffff80612d88 ffffffff9000a4e1
        0000000000000040 0000000000000000 ffffffff80613340 0000000000500001
        ...
Call Trace:
[&lt;ffffffff801772d0&gt;] handle_irq_event_percpu+0x70/0x2f0
[&lt;ffffffff8017ad24&gt;] handle_percpu_irq+0x54/0x88
[&lt;ffffffff801769f4&gt;] generic_handle_irq+0x44/0x60
[&lt;ffffffff801037f8&gt;] do_IRQ+0x48/0x70
[&lt;ffffffff80101c44&gt;] ret_from_irq+0x0/0x4
[&lt;ffffffff80326170&gt;] serial8250_startup+0x310/0x870
[&lt;ffffffff8032175c&gt;] uart_startup.part.7+0x9c/0x330
[&lt;ffffffff80321b4c&gt;] uart_open+0x15c/0x1b0
[&lt;ffffffff80302034&gt;] tty_open+0x1fc/0x720
[&lt;ffffffff801bffac&gt;] chrdev_open+0x7c/0x180
[&lt;ffffffff801b9ab8&gt;] do_dentry_open.isra.14+0x288/0x390
[&lt;ffffffff801bac5c&gt;] nameidata_to_filp+0x5c/0xc0
[&lt;ffffffff801ca700&gt;] do_last.isra.33+0x330/0x8f0
[&lt;ffffffff801caf3c&gt;] path_openat+0xbc/0x440
[&lt;ffffffff801cb3c8&gt;] do_filp_open+0x38/0xa8
[&lt;ffffffff801bade4&gt;] do_sys_open+0x124/0x218
[&lt;ffffffff80110538&gt;] handle_sys+0x118/0x13c

Code: 02d5a825  12800012  02a0b02d &lt;de820000&gt; de850008  0040f809  0220202d  0040a82d  40026000
---[ end trace 5d8e7b9a86badd2d ]---
Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
48d480b0bde794781fcae9501fb043c1bac0e523 [[MIPS] Malta: Fix off by one bug in interrupt
handler.] did not take in account that irq_ffs() will also return 0 if for some reason
the set of pending interrupts happens to be empty.

This is trivial to trigger with a RM5261 CPU module running a 64-bit kernel and results
in something like the following:

CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff801772d0, ra == ffffffff8017ad24
Oops[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff9000a4e0 ffffffff9000a4e0 ffffffff9000a4e0
$ 4   : ffffffff80592be0 0000000000000000 00000000000000d6 ffffffff80322ed0
$ 8   : ffffffff805fe538 0000000000000000 ffffffff9000a4e0 ffffffff80590000
$12   : 00000000000000d6 0000000000000000 ffffffff80600000 ffffffff805fe538
$16   : 0000000000000000 0000000000000010 ffffffff80592be0 0000000000000010
$20   : 0000000000000000 0000000000500001 0000000000000000 ffffffff8051e078
$24   : 0000000000000028 ffffffff803226e8
$28   : 9800000003828000 980000000382b900 ffffffff8051e060 ffffffff8017ad24
Hi    : 0000000000000000
Lo    : 0000006388974000
epc   : ffffffff801772d0 handle_irq_event_percpu+0x70/0x2f0
    Not tainted
ra    : ffffffff8017ad24 handle_percpu_irq+0x54/0x88
Status: 9000a4e2    KX SX UX KERNEL EXL
Cause : 00808008
BadVA : 0000000000000000
PrId  : 000028a0 (Nevada)
Modules linked in:
Process init (pid: 1, threadinfo=9800000003828000, task=9800000003827968, tls=0000000077087490)
Stack : ffffffff80592be0 ffffffff8058d248 0000000000000040 0000000000000000
        ffffffff80613340 0000000000500001 ffffffff805a0000 0000000000000882
        9800000003b89000 ffffffff8017ad24 00000000000000d5 0000000000000010
        ffffffff9000a4e1 ffffffff801769f4 ffffffff9000a4e0 ffffffff801037f8
        0000000000000000 ffffffff80101c44 0000000000000000 ffffffff9000a4e0
        0000000000000000 9000000018000000 90000000180003f9 0000000000000001
        0000000000000000 00000000000000ff 0000000000000018 0000000000000001
        0000000000000001 00000000003fffff 0000000000000020 ffffffff802cf7ac
        ffffffff80208918 000000007fdadf08 ffffffff80612d88 ffffffff9000a4e1
        0000000000000040 0000000000000000 ffffffff80613340 0000000000500001
        ...
Call Trace:
[&lt;ffffffff801772d0&gt;] handle_irq_event_percpu+0x70/0x2f0
[&lt;ffffffff8017ad24&gt;] handle_percpu_irq+0x54/0x88
[&lt;ffffffff801769f4&gt;] generic_handle_irq+0x44/0x60
[&lt;ffffffff801037f8&gt;] do_IRQ+0x48/0x70
[&lt;ffffffff80101c44&gt;] ret_from_irq+0x0/0x4
[&lt;ffffffff80326170&gt;] serial8250_startup+0x310/0x870
[&lt;ffffffff8032175c&gt;] uart_startup.part.7+0x9c/0x330
[&lt;ffffffff80321b4c&gt;] uart_open+0x15c/0x1b0
[&lt;ffffffff80302034&gt;] tty_open+0x1fc/0x720
[&lt;ffffffff801bffac&gt;] chrdev_open+0x7c/0x180
[&lt;ffffffff801b9ab8&gt;] do_dentry_open.isra.14+0x288/0x390
[&lt;ffffffff801bac5c&gt;] nameidata_to_filp+0x5c/0xc0
[&lt;ffffffff801ca700&gt;] do_last.isra.33+0x330/0x8f0
[&lt;ffffffff801caf3c&gt;] path_openat+0xbc/0x440
[&lt;ffffffff801cb3c8&gt;] do_filp_open+0x38/0xa8
[&lt;ffffffff801bade4&gt;] do_sys_open+0x124/0x218
[&lt;ffffffff80110538&gt;] handle_sys+0x118/0x13c

Code: 02d5a825  12800012  02a0b02d &lt;de820000&gt; de850008  0040f809  0220202d  0040a82d  40026000
---[ end trace 5d8e7b9a86badd2d ]---
Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Malta: Remove RTC Data Mode bootstrap breakage</title>
<updated>2012-09-14T15:54:33+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@codesourcery.com</email>
</author>
<published>2012-09-13T20:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=636221b86ce0b3b1238c72bad7172d5227d408ac'/>
<id>636221b86ce0b3b1238c72bad7172d5227d408ac</id>
<content type='text'>
 YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to
binary, that is the bit is set every time the board goes through the
firmware bootstrap sequence.  Likewise its calendar manipulation commands
interpret or set the RTC registers unconditionally as binary, never
actually checking what the value of the DM bit is, under the (correct)
assumption that it has been previously set, to indicate the binary mode.

 A change to Linux a while ago however introduced a platform-specific
tweak that clears that bit and therefore forces the data mode to BCD.
This causes clock corruption and misinterpretation that has to be fixed up
by user-mode tools in system startup scripts as the initial clock is often
incorrect according to the BCD interpretation forced.

 This change removes the hack; a comment included refers to alarm code,
but even if it was broken at one point by requiring the BCD mode, it
should have been trivially corrected and even if not, given how rarely the
alarm feature is used, that was not really a reasonable justification to
break the system clock that is indeed used by virtually everything.  And
either way the alarm code has been since fixed anyway.

Signed-off-by: Maciej W. Rozycki &lt;macro@codesourcery.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4336/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to
binary, that is the bit is set every time the board goes through the
firmware bootstrap sequence.  Likewise its calendar manipulation commands
interpret or set the RTC registers unconditionally as binary, never
actually checking what the value of the DM bit is, under the (correct)
assumption that it has been previously set, to indicate the binary mode.

 A change to Linux a while ago however introduced a platform-specific
tweak that clears that bit and therefore forces the data mode to BCD.
This causes clock corruption and misinterpretation that has to be fixed up
by user-mode tools in system startup scripts as the initial clock is often
incorrect according to the BCD interpretation forced.

 This change removes the hack; a comment included refers to alarm code,
but even if it was broken at one point by requiring the BCD mode, it
should have been trivially corrected and even if not, given how rarely the
alarm feature is used, that was not really a reasonable justification to
break the system clock that is indeed used by virtually everything.  And
either way the alarm code has been since fixed anyway.

Signed-off-by: Maciej W. Rozycki &lt;macro@codesourcery.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4336/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: mm: Add compound tail page _mapcount when mapped</title>
<updated>2012-08-27T14:10:21+00:00</updated>
<author>
<name>Jovi Zhang</name>
<email>bookjovi@gmail.com</email>
</author>
<published>2012-08-22T02:34:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=af89fa3986b9d034a286544ab1ed95096496a2f9'/>
<id>af89fa3986b9d034a286544ab1ed95096496a2f9</id>
<content type='text'>
See commit b6999b191 which did the same modification for x86's mm/gup,

Quote from commit b6999b191:
    "If compound pages are used and the page is a
    tail page, gup_huge_pmd() increases _mapcount to record tail page are
    mapped while gup_huge_pud does not do that."

[ralf@linux-mips.org: fixed rejects caused by the original patch getting
linewrapped.]

Signed-off-by: Jovi Zhang &lt;boojovi@gmail.com&gt;
Cc: Youquan Song &lt;youquan.song@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/4291/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
See commit b6999b191 which did the same modification for x86's mm/gup,

Quote from commit b6999b191:
    "If compound pages are used and the page is a
    tail page, gup_huge_pmd() increases _mapcount to record tail page are
    mapped while gup_huge_pud does not do that."

[ralf@linux-mips.org: fixed rejects caused by the original patch getting
linewrapped.]

Signed-off-by: Jovi Zhang &lt;boojovi@gmail.com&gt;
Cc: Youquan Song &lt;youquan.song@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/4291/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: CMP/SMTC: Fix tc_id calculation</title>
<updated>2012-08-27T14:10:13+00:00</updated>
<author>
<name>RongQing.Li</name>
<email>roy.qing.li@gmail.com</email>
</author>
<published>2012-07-02T04:34:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2bd4082776ff17a0d0d565852afb422931c2f6f2'/>
<id>2bd4082776ff17a0d0d565852afb422931c2f6f2</id>
<content type='text'>
Currently the tc_id code is:

  (read_c0_tcbind() &gt;&gt; TCBIND_CURTC_SHIFT) &amp; TCBIND_CURTC;

After processing this becomes:

  (read_c0_tcbind() &gt;&gt; 21) &amp; ((0xff) &lt;&lt; 21)

But it should be:

  (read_c0_tcbind() &amp; ((0xff)&lt;&lt; 21)) &gt;&gt; 21

Signed-off-by: RongQing.Li &lt;roy.qing.li@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4077/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the tc_id code is:

  (read_c0_tcbind() &gt;&gt; TCBIND_CURTC_SHIFT) &amp; TCBIND_CURTC;

After processing this becomes:

  (read_c0_tcbind() &gt;&gt; 21) &amp; ((0xff) &lt;&lt; 21)

But it should be:

  (read_c0_tcbind() &amp; ((0xff)&lt;&lt; 21)) &gt;&gt; 21

Signed-off-by: RongQing.Li &lt;roy.qing.li@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4077/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: pci-ar724x: avoid data bus error due to a missing PCIe module</title>
<updated>2012-08-23T13:44:47+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-08-23T13:35:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a1dca315ce3f78347bca8ce8befe3cc71ae63b7e'/>
<id>a1dca315ce3f78347bca8ce8befe3cc71ae63b7e</id>
<content type='text'>
If the controller has no PCIe module attached, accessing of the device
configuration space causes a data bus error. Avoid this by checking the
status of the PCIe link in advance, and indicate an error if the link
is down.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4293/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the controller has no PCIe module attached, accessing of the device
configuration space causes a data bus error. Avoid this by checking the
status of the PCIe link in advance, and indicate an error if the link
is down.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4293/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
