<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/m68k, branch v3.4.23</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>m68k: fix sigset_t accessor functions</title>
<updated>2012-11-26T19:37:46+00:00</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@linux-m68k.org</email>
</author>
<published>2012-11-17T21:27:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=999d6a5194c9707b081869f40306ac5e1727edf4'/>
<id>999d6a5194c9707b081869f40306ac5e1727edf4</id>
<content type='text'>
commit 34fa78b59c52d1db3513db4c1a999db26b2e9ac2 upstream.

The sigaddset/sigdelset/sigismember functions that are implemented with
bitfield insn cannot allow the sigset argument to be placed in a data
register since the sigset is wider than 32 bits.  Remove the "d"
constraint from the asm statements.

The effect of the bug is that sending RT signals does not work, the signal
number is truncated modulo 32.

Signed-off-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.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 34fa78b59c52d1db3513db4c1a999db26b2e9ac2 upstream.

The sigaddset/sigdelset/sigismember functions that are implemented with
bitfield insn cannot allow the sigset argument to be placed in a data
register since the sigset is wider than 32 bits.  Remove the "d"
constraint from the asm statements.

The effect of the bug is that sending RT signals does not work, the signal
number is truncated modulo 32.

Signed-off-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>m68k: Add missing RCU idle APIs on idle loop</title>
<updated>2012-10-12T20:38:54+00:00</updated>
<author>
<name>Frederic Weisbecker</name>
<email>fweisbec@gmail.com</email>
</author>
<published>2012-08-22T15:27:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ce6ccabd21d356ac22973d275f122d3d8efc96d7'/>
<id>ce6ccabd21d356ac22973d275f122d3d8efc96d7</id>
<content type='text'>
commit 5b57ba37e82a15f345a6a2eb8c01a2b2d94c5eeb upstream.

In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.

So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.

This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.

Add this missing pair of calls in the m68k's idle loop.

Reported-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: m68k &lt;linux-m68k@lists.linux-m68k.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.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 5b57ba37e82a15f345a6a2eb8c01a2b2d94c5eeb upstream.

In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.

So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.

This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.

Add this missing pair of calls in the m68k's idle loop.

Reported-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: m68k &lt;linux-m68k@lists.linux-m68k.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>m68k: Correct the Atari ALLOWINT definition</title>
<updated>2012-08-09T15:31:53+00:00</updated>
<author>
<name>Mikael Pettersson</name>
<email>mikpe@it.uu.se</email>
</author>
<published>2012-04-18T22:53:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ef2e080c19599e3d0844f3bc599ee5dd627fc850'/>
<id>ef2e080c19599e3d0844f3bc599ee5dd627fc850</id>
<content type='text'>
commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream.

Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
`nfeth' ethernet device triggers a WARN_ONCE() in generic irq
handling code on the first irq for that device:

WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142()
irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts
Modules linked in:
Call Trace: [&lt;000299b2&gt;] warn_slowpath_common+0x48/0x6a
 [&lt;000299c0&gt;] warn_slowpath_common+0x56/0x6a
 [&lt;00029a4c&gt;] warn_slowpath_fmt+0x2a/0x32
 [&lt;0005b34c&gt;] handle_irq_event_percpu+0x134/0x142
 [&lt;0005b34c&gt;] handle_irq_event_percpu+0x134/0x142
 [&lt;0000a584&gt;] nfeth_interrupt+0x0/0x194
 [&lt;001ba0a8&gt;] schedule_preempt_disabled+0x0/0xc
 [&lt;0005b37a&gt;] handle_irq_event+0x20/0x2c
 [&lt;0005add4&gt;] generic_handle_irq+0x2c/0x3a
 [&lt;00002ab6&gt;] do_IRQ+0x20/0x32
 [&lt;0000289e&gt;] auto_irqhandler_fixup+0x4/0x6
 [&lt;00003144&gt;] cpu_idle+0x22/0x2e
 [&lt;001b8a78&gt;] printk+0x0/0x18
 [&lt;0024d112&gt;] start_kernel+0x37a/0x386
 [&lt;0003021d&gt;] __do_proc_dointvec+0xb1/0x366
 [&lt;0003021d&gt;] __do_proc_dointvec+0xb1/0x366
 [&lt;0024c31e&gt;] _sinittext+0x31e/0x9c0

After invoking the irq's handler the kernel sees !irqs_disabled()
and concludes that the handler erroneously enabled interrupts.

However, debugging shows that !irqs_disabled() is true even before
the handler is invoked, which indicates a problem in the platform
code rather than the specific driver.

The warning does not occur in 3.1 or older kernels.

It turns out that the ALLOWINT definition for Atari is incorrect.

The Atari definition of ALLOWINT is ~0x400, the stated purpose of
that is to avoid taking HSYNC interrupts.  irqs_disabled() returns
true if the 3-bit ipl &amp; 4 is non-zero.  The nfeth interrupt runs at
ipl 3 (it's autovector 3), but 3 &amp; 4 is zero so irqs_disabled() is
false, and the warning above is generated.

When interrupts are explicitly disabled, ipl is set to 7.  When they
are enabled, ipl is masked with ALLOWINT.  On Atari this will result
in ipl = 3, which blocks interrupts at ipl 3 and below.  So how come
nfeth interrupts at ipl 3 are received at all?  That's because ipl
is reset to 2 by Atari-specific code in default_idle(), again with
the stated purpose of blocking HSYNC interrupts.  This discrepancy
means that ipl 3 can remain blocked for longer than intended.

Both default_idle() and falcon_hblhandler() identify HSYNC with
ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees,
but ALLOWINT is defined as if HSYNC was ipl 3.

[As an experiment I modified default_idle() to reset ipl to 3, and
as expected that resulted in all nfeth interrupts being blocked.]

The fix is simple: define ALLOWINT as ~0x500 instead.  This makes
arch_local_irq_enable() consistent with default_idle(), and prevents
the !irqs_disabled() problems for ipl 3 interrupts.

Tested on Atari running in an Aranym VM.

Signed-off-by: Mikael Pettersson &lt;mikpe@it.uu.se&gt;
Tested-by: Michael Schmitz &lt;schmitzmic@googlemail.com&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.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 c663600584a596b5e66258cc10716fb781a5c2c9 upstream.

Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
`nfeth' ethernet device triggers a WARN_ONCE() in generic irq
handling code on the first irq for that device:

WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142()
irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts
Modules linked in:
Call Trace: [&lt;000299b2&gt;] warn_slowpath_common+0x48/0x6a
 [&lt;000299c0&gt;] warn_slowpath_common+0x56/0x6a
 [&lt;00029a4c&gt;] warn_slowpath_fmt+0x2a/0x32
 [&lt;0005b34c&gt;] handle_irq_event_percpu+0x134/0x142
 [&lt;0005b34c&gt;] handle_irq_event_percpu+0x134/0x142
 [&lt;0000a584&gt;] nfeth_interrupt+0x0/0x194
 [&lt;001ba0a8&gt;] schedule_preempt_disabled+0x0/0xc
 [&lt;0005b37a&gt;] handle_irq_event+0x20/0x2c
 [&lt;0005add4&gt;] generic_handle_irq+0x2c/0x3a
 [&lt;00002ab6&gt;] do_IRQ+0x20/0x32
 [&lt;0000289e&gt;] auto_irqhandler_fixup+0x4/0x6
 [&lt;00003144&gt;] cpu_idle+0x22/0x2e
 [&lt;001b8a78&gt;] printk+0x0/0x18
 [&lt;0024d112&gt;] start_kernel+0x37a/0x386
 [&lt;0003021d&gt;] __do_proc_dointvec+0xb1/0x366
 [&lt;0003021d&gt;] __do_proc_dointvec+0xb1/0x366
 [&lt;0024c31e&gt;] _sinittext+0x31e/0x9c0

After invoking the irq's handler the kernel sees !irqs_disabled()
and concludes that the handler erroneously enabled interrupts.

However, debugging shows that !irqs_disabled() is true even before
the handler is invoked, which indicates a problem in the platform
code rather than the specific driver.

The warning does not occur in 3.1 or older kernels.

It turns out that the ALLOWINT definition for Atari is incorrect.

The Atari definition of ALLOWINT is ~0x400, the stated purpose of
that is to avoid taking HSYNC interrupts.  irqs_disabled() returns
true if the 3-bit ipl &amp; 4 is non-zero.  The nfeth interrupt runs at
ipl 3 (it's autovector 3), but 3 &amp; 4 is zero so irqs_disabled() is
false, and the warning above is generated.

When interrupts are explicitly disabled, ipl is set to 7.  When they
are enabled, ipl is masked with ALLOWINT.  On Atari this will result
in ipl = 3, which blocks interrupts at ipl 3 and below.  So how come
nfeth interrupts at ipl 3 are received at all?  That's because ipl
is reset to 2 by Atari-specific code in default_idle(), again with
the stated purpose of blocking HSYNC interrupts.  This discrepancy
means that ipl 3 can remain blocked for longer than intended.

Both default_idle() and falcon_hblhandler() identify HSYNC with
ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees,
but ALLOWINT is defined as if HSYNC was ipl 3.

[As an experiment I modified default_idle() to reset ipl to 3, and
as expected that resulted in all nfeth interrupts being blocked.]

The fix is simple: define ALLOWINT as ~0x500 instead.  This makes
arch_local_irq_enable() consistent with default_idle(), and prevents
the !irqs_disabled() problems for ipl 3 interrupts.

Tested on Atari running in an Aranym VM.

Signed-off-by: Mikael Pettersson &lt;mikpe@it.uu.se&gt;
Tested-by: Michael Schmitz &lt;schmitzmic@googlemail.com&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>m68k: Make sys_atomic_cmpxchg_32 work on classic m68k</title>
<updated>2012-08-09T15:31:53+00:00</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@linux-m68k.org</email>
</author>
<published>2012-07-27T22:20:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=727cda365f7007f75a402f38ecd8bbf88a874e8f'/>
<id>727cda365f7007f75a402f38ecd8bbf88a874e8f</id>
<content type='text'>
commit 9e2760d18b3cf179534bbc27692c84879c61b97c upstream.

User space access must always go through uaccess accessors, since on
classic m68k user space and kernel space are completely separate.

Signed-off-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Tested-by: Thorsten Glaser &lt;tg@debian.org&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.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 9e2760d18b3cf179534bbc27692c84879c61b97c upstream.

User space access must always go through uaccess accessors, since on
classic m68k user space and kernel space are completely separate.

Signed-off-by: Andreas Schwab &lt;schwab@linux-m68k.org&gt;
Tested-by: Thorsten Glaser &lt;tg@debian.org&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>m68knommu: enable qspi support when SPI_COLDFIRE_QSPI = m</title>
<updated>2012-05-08T03:06:51+00:00</updated>
<author>
<name>Steven King</name>
<email>sfking@fdwdc.com</email>
</author>
<published>2012-05-06T19:22:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=83ca60094e5e907b8b43c60b4c29b1119604cbb8'/>
<id>83ca60094e5e907b8b43c60b4c29b1119604cbb8</id>
<content type='text'>
Enable Coldfire QSPI support when SPI_COLDFIRE_QSPI is built as a module.

This version of the patch combines changes to the config files and  device.c
and uses IF_ENABLED (thanks to Sam Ravnborg for the suggestion).

Signed-off-by: Steven King &lt;sfking@fdwdc.com&gt;
Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enable Coldfire QSPI support when SPI_COLDFIRE_QSPI is built as a module.

This version of the patch combines changes to the config files and  device.c
and uses IF_ENABLED (thanks to Sam Ravnborg for the suggestion).

Signed-off-by: Steven King &lt;sfking@fdwdc.com&gt;
Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m68knommu: make sure 2nd FEC eth interface pins are enabled on 5275 ColdFire</title>
<updated>2012-04-17T07:06:34+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2012-04-17T07:06:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=938ed25008d665d1dd937ca251d1aabb363113c6'/>
<id>938ed25008d665d1dd937ca251d1aabb363113c6</id>
<content type='text'>
The CONFIG_FEC2 define was removed from the kernel many versions ago.
But it is still being used to set the multi-function pins when compiling
for a ColdFire 527[45] SoC that has 2 ethernet interfaces. Remove the
last remaining uses of this define, and so fix the setting of the pins
for the 2nd ethernet interface.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The CONFIG_FEC2 define was removed from the kernel many versions ago.
But it is still being used to set the multi-function pins when compiling
for a ColdFire 527[45] SoC that has 2 ethernet interfaces. Remove the
last remaining uses of this define, and so fix the setting of the pins
for the 2nd ethernet interface.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m68knommu: fix id number for second eth device on 5275 ColdFire</title>
<updated>2012-04-17T06:58:35+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2012-04-17T06:58:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bfdd769ac51cb68cb99902192fac81bc67cb23b0'/>
<id>bfdd769ac51cb68cb99902192fac81bc67cb23b0</id>
<content type='text'>
The second ColdFire FEC ethernet device should have an id number of 1,
not 0. Otherwise it clashes with the first FEC ethernet device.

On booting a kernel on a 5275 based board you will get messages out of
the kernel like this:

    &lt;4&gt;------------[ cut here ]------------
    &lt;4&gt;WARNING: at fs/sysfs/dir.c:508 0x0a8b50()
    &lt;4&gt;sysfs: cannot create duplicate filename 'fec.0'

And likely you won't be able to completely boot up after this at all.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The second ColdFire FEC ethernet device should have an id number of 1,
not 0. Otherwise it clashes with the first FEC ethernet device.

On booting a kernel on a 5275 based board you will get messages out of
the kernel like this:

    &lt;4&gt;------------[ cut here ]------------
    &lt;4&gt;WARNING: at fs/sysfs/dir.c:508 0x0a8b50()
    &lt;4&gt;sysfs: cannot create duplicate filename 'fec.0'

And likely you won't be able to completely boot up after this at all.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m68knommu: move and fix the 68VZ328 platform bootlogo.h</title>
<updated>2012-04-16T05:11:04+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2012-03-21T04:22:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=89d786011fcbc89eedca8b6bf9b7c11bbbde350a'/>
<id>89d786011fcbc89eedca8b6bf9b7c11bbbde350a</id>
<content type='text'>
The 68EZ328/bootlogo.h is not actually used in the 68EZ328 platform code
at all. It is used by the 68VZ328 platform code though, so move it to be
with the rest of the 68VZ328 platform code.

Commit c0e0c89c089f4bd66dbbd1a44da90abe74fe3f02 ("fix broken boot logo
inclusion") modified the bootlogo code to not be included in asm code.
Modify 68VZ328/bootlogo.h so that the bootlogo bit map is named correctly
for direct use in the C code.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 68EZ328/bootlogo.h is not actually used in the 68EZ328 platform code
at all. It is used by the 68VZ328 platform code though, so move it to be
with the rest of the 68VZ328 platform code.

Commit c0e0c89c089f4bd66dbbd1a44da90abe74fe3f02 ("fix broken boot logo
inclusion") modified the bootlogo code to not be included in asm code.
Modify 68VZ328/bootlogo.h so that the bootlogo bit map is named correctly
for direct use in the C code.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m68knommu: remove the unused bootlogo.h processing for 68EZ328 and 68VZ328</title>
<updated>2012-04-16T05:11:04+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2012-03-21T04:17:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=acb0c7accde75f75afc70f662d045827d5126839'/>
<id>acb0c7accde75f75afc70f662d045827d5126839</id>
<content type='text'>
The 68EZ328 and 68VZ328 platforms currently try to process their bootlogo.h
to make it clean to include in asm files. This is no longer used, the
bootlogo.h file is now included only in C code, so remove all the processing
code in the 68EZ328 and 68VZ328 Makefiles.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 68EZ328 and 68VZ328 platforms currently try to process their bootlogo.h
to make it clean to include in asm files. This is no longer used, the
bootlogo.h file is now included only in C code, so remove all the processing
code in the 68EZ328 and 68VZ328 Makefiles.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m68k/q40: Add missing platform check before registering platform devices</title>
<updated>2012-04-01T20:57:53+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2012-03-18T12:20:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=450aed725c9a53282483c48ebd012feefae94a07'/>
<id>450aed725c9a53282483c48ebd012feefae94a07</id>
<content type='text'>
On multi-platform kernels, the Q40/Q60 platform devices should be
registered when running on Q40/Q60 only. Else it may crash later.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On multi-platform kernels, the Q40/Q60 platform devices should be
registered when running on Q40/Q60 only. Else it may crash later.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
