<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/tty, branch v3.10.38</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>tty: Set correct tty name in 'active' sysfs attribute</title>
<updated>2014-04-27T00:15:34+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2014-02-27T11:30:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f5b4cbf53a1da6f90b4ac8c5389d6c8528507e8b'/>
<id>f5b4cbf53a1da6f90b4ac8c5389d6c8528507e8b</id>
<content type='text'>
commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream.

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The -&gt;device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering &lt;lennart@poettering.net&gt;
Cc: Kay Sievers &lt;kay@vrfy.org&gt;
Cc: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Werner Fink &lt;werner@suse.de&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: David Herrmann &lt;dh.herrmann@gmail.com&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 723abd87f6e536f1353c8f64f621520bc29523a3 upstream.

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The -&gt;device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering &lt;lennart@poettering.net&gt;
Cc: Kay Sievers &lt;kay@vrfy.org&gt;
Cc: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Werner Fink &lt;werner@suse.de&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vt: Fix secure clear screen</title>
<updated>2014-02-22T20:41:27+00:00</updated>
<author>
<name>Petr Písař</name>
<email>petr.pisar@atlas.cz</email>
</author>
<published>2014-02-06T20:01:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=27f0831c1aedad09238f173550919ac7f809e4fa'/>
<id>27f0831c1aedad09238f173550919ac7f809e4fa</id>
<content type='text'>
commit 0930b0950a8996aa88b0d2ba4bb2bab27cc36bc7 upstream.

\E[3J console code (secure clear screen) needs to update_screen(vc)
in order to write-through blanks into off-screen video memory.

This has been removed accidentally in 3.6 by:

commit 81732c3b2fede049a692e58a7ceabb6d18ffb18c
Author: Jean-François Moine &lt;moinejf@free.fr&gt;
Date:   Thu Sep 6 19:24:13 2012 +0200

    tty vt: Fix line garbage in virtual console on command line edition

Signed-off-by: Petr Písař &lt;petr.pisar@atlas.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 0930b0950a8996aa88b0d2ba4bb2bab27cc36bc7 upstream.

\E[3J console code (secure clear screen) needs to update_screen(vc)
in order to write-through blanks into off-screen video memory.

This has been removed accidentally in 3.6 by:

commit 81732c3b2fede049a692e58a7ceabb6d18ffb18c
Author: Jean-François Moine &lt;moinejf@free.fr&gt;
Date:   Thu Sep 6 19:24:13 2012 +0200

    tty vt: Fix line garbage in virtual console on command line edition

Signed-off-by: Petr Písař &lt;petr.pisar@atlas.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty: n_gsm: Fix for modems with brk in modem status control</title>
<updated>2014-02-22T20:41:27+00:00</updated>
<author>
<name>Lars Poeschel</name>
<email>poeschel@lemonage.de</email>
</author>
<published>2014-01-07T12:34:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5e33b2d90acb2d0272596cae533d920a0399a88a'/>
<id>5e33b2d90acb2d0272596cae533d920a0399a88a</id>
<content type='text'>
commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream.

3GPP TS 07.10 states in section 5.4.6.3.7:
"The length byte contains the value 2 or 3 ... depending on the break
signal." The break byte is optional and if it is sent, the length is
3. In fact the driver was not able to work with modems that send this
break byte in their modem status control message. If the modem just
sends the break byte if it is really set, then weird things might
happen.
The code for deconding the modem status to the internal linux
presentation in gsm_process_modem has already a big comment about
this 2 or 3 byte length thing and it is already able to decode the
brk, but the code calling the gsm_process_modem function in
gsm_control_modem does not encode it and hand it over the right way.
This patch fixes this.
Without this fix if the modem sends the brk byte in it's modem status
control message the driver will hang when opening a muxed channel.

Signed-off-by: Lars Poeschel &lt;poeschel@lemonage.de&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 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream.

3GPP TS 07.10 states in section 5.4.6.3.7:
"The length byte contains the value 2 or 3 ... depending on the break
signal." The break byte is optional and if it is sent, the length is
3. In fact the driver was not able to work with modems that send this
break byte in their modem status control message. If the modem just
sends the break byte if it is really set, then weird things might
happen.
The code for deconding the modem status to the internal linux
presentation in gsm_process_modem has already a big comment about
this 2 or 3 byte length thing and it is already able to decode the
brk, but the code calling the gsm_process_modem function in
gsm_control_modem does not encode it and hand it over the right way.
This patch fixes this.
Without this fix if the modem sends the brk byte in it's modem status
control message the driver will hang when opening a muxed channel.

Signed-off-by: Lars Poeschel &lt;poeschel@lemonage.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250: enable UART_BUG_NOMSR for Tegra</title>
<updated>2014-02-06T19:08:14+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2014-01-07T22:00:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d353b6d2f264168b820b2124c3db5018430fd04'/>
<id>8d353b6d2f264168b820b2124c3db5018430fd04</id>
<content type='text'>
commit 3685f19e07802ec4207b52465c408f185b66490e upstream.

Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
their MODEM-control signals tied off to a static state. However UARTs A
and B can optionally route those signals to/from package pins, depending
on the exact pinmux configuration.

When these signals are not routed to package pins, false interrupts may
trigger either temporarily, or permanently, all while not showing up in
the IIR; it will read as NO_INT. This will eventually lead to the UART
IRQ being disabled due to unhandled interrupts. When this happens, the
kernel may print e.g.:

    irq 68: nobody cared (try booting with the "irqpoll" option)

In order to prevent this, enable UART_BUG_NOMSR. This prevents
UART_IER_MSI from being enabled, which prevents the false interrupts
from triggering.

In practice, this is not needed under any of the following conditions:

* On Tegra chips after Tegra30, since the HW bug has apparently been
  fixed.

* On UARTs C..E since their MODEM control signals are tied to the correct
  static state which doesn't trigger the issue.

* On UARTs A..B if the MODEM control signals are routed out to package
  pins, since they will then carry valid signals.

However, we ignore these exceptions for now, since they are only relevant
if a board actually hooks up more than a 4-wire UART, and no currently
supported board does this. If we ever support a board that does, we can
refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
into account, and/or read a flag from DT/... that indicates that the
board has hooked up and pinmux'd more than a 4-wire UART.

Reported-by: Olof Johansson &lt;olof@lixom.net&gt; # autotester
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&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 3685f19e07802ec4207b52465c408f185b66490e upstream.

Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
their MODEM-control signals tied off to a static state. However UARTs A
and B can optionally route those signals to/from package pins, depending
on the exact pinmux configuration.

When these signals are not routed to package pins, false interrupts may
trigger either temporarily, or permanently, all while not showing up in
the IIR; it will read as NO_INT. This will eventually lead to the UART
IRQ being disabled due to unhandled interrupts. When this happens, the
kernel may print e.g.:

    irq 68: nobody cared (try booting with the "irqpoll" option)

In order to prevent this, enable UART_BUG_NOMSR. This prevents
UART_IER_MSI from being enabled, which prevents the false interrupts
from triggering.

In practice, this is not needed under any of the following conditions:

* On Tegra chips after Tegra30, since the HW bug has apparently been
  fixed.

* On UARTs C..E since their MODEM control signals are tied to the correct
  static state which doesn't trigger the issue.

* On UARTs A..B if the MODEM control signals are routed out to package
  pins, since they will then carry valid signals.

However, we ignore these exceptions for now, since they are only relevant
if a board actually hooks up more than a 4-wire UART, and no currently
supported board does this. If we ever support a board that does, we can
refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
into account, and/or read a flag from DT/... that indicates that the
board has hooked up and pinmux'd more than a 4-wire UART.

Reported-by: Olof Johansson &lt;olof@lixom.net&gt; # autotester
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250: Fix initialisation of Quatech cards with the AMCC PCI chip</title>
<updated>2014-02-06T19:08:14+00:00</updated>
<author>
<name>Jonathan Woithe</name>
<email>jwoithe@just42.net</email>
</author>
<published>2013-12-09T06:03:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f8cef8c248cf56daefe3c2fb98f13cc626377f5'/>
<id>2f8cef8c248cf56daefe3c2fb98f13cc626377f5</id>
<content type='text'>
commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream.

Fix the initialisation of older Quatech serial cards which are fitted with
the AMCC PCI Matchmaker interface chip.

Signed-off-by: Jonathan Woithe (jwoithe@just42.net)
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 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream.

Fix the initialisation of older Quatech serial cards which are fitted with
the AMCC PCI Matchmaker interface chip.

Signed-off-by: Jonathan Woithe (jwoithe@just42.net)
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: add support for 200 v3 series Titan card</title>
<updated>2014-02-06T19:08:14+00:00</updated>
<author>
<name>Yegor Yefremov</name>
<email>yegorslists@googlemail.com</email>
</author>
<published>2013-12-09T11:11:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1459439f7c43db399daf01ab5b5ead82248db361'/>
<id>1459439f7c43db399daf01ab5b5ead82248db361</id>
<content type='text'>
commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream.

Signed-off-by: Yegor Yefremov &lt;yegorslists@googlemail.com&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 48c0247d7b7bf58abb85a39021099529df365c4d upstream.

Signed-off-by: Yegor Yefremov &lt;yegorslists@googlemail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty/serial: at91: Handle shutdown more safely</title>
<updated>2014-02-06T19:08:14+00:00</updated>
<author>
<name>Marek Roszko</name>
<email>mark.roszko@gmail.com</email>
</author>
<published>2014-01-07T10:45:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=630cf7648cd47e83ddb674aaa4e4c245a6736f10'/>
<id>630cf7648cd47e83ddb674aaa4e4c245a6736f10</id>
<content type='text'>
commit 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream.

Interrupts were being cleaned up late in the shutdown handler, it is possible
that an interrupt can occur and schedule a tasklet that runs after the port is
cleaned up. There is a null dereference due to this race condition with the
following stacktrace:

[&lt;c02092b0&gt;] (atmel_tasklet_func+0x514/0x814) from [&lt;c001fd34&gt;] (tasklet_action+0x70/0xa8)
[&lt;c001fd34&gt;] (tasklet_action+0x70/0xa8) from [&lt;c001f60c&gt;] (__do_softirq+0x90/0x144)
[&lt;c001f60c&gt;] (__do_softirq+0x90/0x144) from [&lt;c001fa18&gt;] (irq_exit+0x40/0x4c)
[&lt;c001fa18&gt;] (irq_exit+0x40/0x4c) from [&lt;c000e298&gt;] (handle_IRQ+0x64/0x84)
[&lt;c000e298&gt;] (handle_IRQ+0x64/0x84) from [&lt;c000d6c0&gt;] (__irq_svc+0x40/0x50)
[&lt;c000d6c0&gt;] (__irq_svc+0x40/0x50) from [&lt;c0208060&gt;] (atmel_rx_dma_release+0x88/0xb8)
[&lt;c0208060&gt;] (atmel_rx_dma_release+0x88/0xb8) from [&lt;c0209740&gt;] (atmel_shutdown+0x104/0x160)
[&lt;c0209740&gt;] (atmel_shutdown+0x104/0x160) from [&lt;c0205e8c&gt;] (uart_port_shutdown+0x2c/0x38)

Signed-off-by: Marek Roszko &lt;mark.roszko@gmail.com&gt;
Acked-by: Leilei Zhao &lt;leilei.zhao@atmel.com&gt;
Signed-off-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&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 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream.

Interrupts were being cleaned up late in the shutdown handler, it is possible
that an interrupt can occur and schedule a tasklet that runs after the port is
cleaned up. There is a null dereference due to this race condition with the
following stacktrace:

[&lt;c02092b0&gt;] (atmel_tasklet_func+0x514/0x814) from [&lt;c001fd34&gt;] (tasklet_action+0x70/0xa8)
[&lt;c001fd34&gt;] (tasklet_action+0x70/0xa8) from [&lt;c001f60c&gt;] (__do_softirq+0x90/0x144)
[&lt;c001f60c&gt;] (__do_softirq+0x90/0x144) from [&lt;c001fa18&gt;] (irq_exit+0x40/0x4c)
[&lt;c001fa18&gt;] (irq_exit+0x40/0x4c) from [&lt;c000e298&gt;] (handle_IRQ+0x64/0x84)
[&lt;c000e298&gt;] (handle_IRQ+0x64/0x84) from [&lt;c000d6c0&gt;] (__irq_svc+0x40/0x50)
[&lt;c000d6c0&gt;] (__irq_svc+0x40/0x50) from [&lt;c0208060&gt;] (atmel_rx_dma_release+0x88/0xb8)
[&lt;c0208060&gt;] (atmel_rx_dma_release+0x88/0xb8) from [&lt;c0209740&gt;] (atmel_shutdown+0x104/0x160)
[&lt;c0209740&gt;] (atmel_shutdown+0x104/0x160) from [&lt;c0205e8c&gt;] (uart_port_shutdown+0x2c/0x38)

Signed-off-by: Marek Roszko &lt;mark.roszko@gmail.com&gt;
Acked-by: Leilei Zhao &lt;leilei.zhao@atmel.com&gt;
Signed-off-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: amba-pl011: use port lock to guard control register access</title>
<updated>2014-01-25T16:27:12+00:00</updated>
<author>
<name>Jon Medhurst</name>
<email>tixy@linaro.org</email>
</author>
<published>2013-12-10T10:18:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3bb0df1b71413ae789767d928d9126c5a5cb1e11'/>
<id>3bb0df1b71413ae789767d928d9126c5a5cb1e11</id>
<content type='text'>
commit fe43390702a1b5741fdf217063b05c7612b38303 upstream.

When the pl011 is being used for a console, pl011_console_write forces
the control register (CR) to enable the UART for transmission and then
restores this to the original value afterwards. It does this while
holding the port lock.

Unfortunately, when the uart is started or shutdown - say in response to
userland using the serial device for a terminal - then this updates the
control register without any locking.

This means we can have

  pl011_console_write   Save CR
  pl011_startup         Initialise CR, e.g. enable receive
  pl011_console_write   Restore old CR with receive not enabled

this result is a serial port which doesn't respond to any input.

A similar race in reverse could happen when the device is shutdown.

We can fix these problems by taking the port lock when updating CR.

Signed-off-by: Jon Medhurst &lt;tixy@linaro.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 fe43390702a1b5741fdf217063b05c7612b38303 upstream.

When the pl011 is being used for a console, pl011_console_write forces
the control register (CR) to enable the UART for transmission and then
restores this to the original value afterwards. It does this while
holding the port lock.

Unfortunately, when the uart is started or shutdown - say in response to
userland using the serial device for a terminal - then this updates the
control register without any locking.

This means we can have

  pl011_console_write   Save CR
  pl011_startup         Initialise CR, e.g. enable receive
  pl011_console_write   Restore old CR with receive not enabled

this result is a serial port which doesn't respond to any input.

A similar race in reverse could happen when the device is shutdown.

We can fix these problems by taking the port lock when updating CR.

Signed-off-by: Jon Medhurst &lt;tixy@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_dw: add new ACPI IDs</title>
<updated>2014-01-09T20:24:20+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2013-12-10T10:56:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a718268abcb22c6276b8a9126335b6f0714bd0e9'/>
<id>a718268abcb22c6276b8a9126335b6f0714bd0e9</id>
<content type='text'>
commit d24c195f90cb1adb178d26d84c722d4b9e551e05 upstream.

Newer Intel PCHs with LPSS have the same Designware controllers than
Haswell but ACPI IDs are different. Add these IDs to the driver list.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&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 d24c195f90cb1adb178d26d84c722d4b9e551e05 upstream.

Newer Intel PCHs with LPSS have the same Designware controllers than
Haswell but ACPI IDs are different. Add these IDs to the driver list.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>TTY: pmac_zilog, check existence of ports in pmz_console_init()</title>
<updated>2014-01-09T20:24:19+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2013-11-22T15:47:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb36b98472a57ce5e9aaa81de2a8d21089210071'/>
<id>fb36b98472a57ce5e9aaa81de2a8d21089210071</id>
<content type='text'>
commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream.

When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
on the kernel command line, it crashes with:

Unable to handle kernel NULL pointer dereference at virtual address   (null)
Oops: 00000000
PC: [&lt;0013ad28&gt;] __pmz_startup+0x32/0x2a0
...
Call Trace: [&lt;002c5d3e&gt;] pmz_console_setup+0x64/0xe4

The normal tty driver doesn't crash, because init_pmz() checks
pmz_ports_count again after calling pmz_probe().

In the serial console initialization path, pmz_console_init() doesn't do
this, causing the driver to crash later.

Add a check for pmz_ports_count to fix this.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.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 dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream.

When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
on the kernel command line, it crashes with:

Unable to handle kernel NULL pointer dereference at virtual address   (null)
Oops: 00000000
PC: [&lt;0013ad28&gt;] __pmz_startup+0x32/0x2a0
...
Call Trace: [&lt;002c5d3e&gt;] pmz_console_setup+0x64/0xe4

The normal tty driver doesn't crash, because init_pmz() checks
pmz_ports_count again after calling pmz_probe().

In the serial console initialization path, pmz_console_init() doesn't do
this, causing the driver to crash later.

Add a check for pmz_ports_count to fix this.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
