<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/char, branch v3.10.78</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>tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send</title>
<updated>2015-03-26T14:00:58+00:00</updated>
<author>
<name>jmlatten@linux.vnet.ibm.com</name>
<email>jmlatten@linux.vnet.ibm.com</email>
</author>
<published>2015-02-21T00:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=230a7eea686c125a6f982480bc84b586346b4472'/>
<id>230a7eea686c125a6f982480bc84b586346b4472</id>
<content type='text'>
commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 upstream.

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.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 62dfd912ab3b5405b6fe72d0135c37e9648071f1 upstream.

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_console: init work unconditionally</title>
<updated>2015-03-26T14:00:58+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2015-03-05T00:15:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=811fe127d8934539ebb9ee38abd3f9d55159e1ca'/>
<id>811fe127d8934539ebb9ee38abd3f9d55159e1ca</id>
<content type='text'>
commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 upstream.

when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&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 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 upstream.

when multiport is off, we don't initialize config work,
but we then cancel uninitialized control_work on freeze.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Added Little Endian support to vtpm module</title>
<updated>2015-03-06T22:40:50+00:00</updated>
<author>
<name>honclo</name>
<email>honclo@imap.linux.ibm.com</email>
</author>
<published>2015-02-13T02:02:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c213da80aa303730ca6d99a30f10043428c0e354'/>
<id>c213da80aa303730ca6d99a30f10043428c0e354</id>
<content type='text'>
commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.

The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.

We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
   is in LE format on a LE OS.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.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 eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.

The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.

We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
   is in LE format on a LE OS.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send</title>
<updated>2015-03-06T22:40:50+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2014-12-01T18:32:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6280501c3e6346652bb9a1f2a77148f5aa5a37a6'/>
<id>6280501c3e6346652bb9a1f2a77148f5aa5a37a6</id>
<content type='text'>
commit 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream.

When sending data in tpm_stm_i2c_send, each loop iteration send buf.
Send buf + i instead as the goal of this for loop is to send a number
of byte from buf that fit in burstcnt. Once those byte are sent, we are
supposed to send the next ones.

The driver was working because the burstcount value returns always the maximum size for a TPM
command or response. (0x800 for a command and 0x400 for a response).

Reviewed-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.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 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream.

When sending data in tpm_stm_i2c_send, each loop iteration send buf.
Send buf + i instead as the goal of this for loop is to send a number
of byte from buf that fit in burstcnt. Once those byte are sent, we are
supposed to send the next ones.

The driver was working because the burstcount value returns always the maximum size for a TPM
command or response. (0x800 for a command and 0x400 for a response).

Reviewed-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma</title>
<updated>2015-03-06T22:40:50+00:00</updated>
<author>
<name>Hon Ching (Vicky) Lo</name>
<email>honclo@linux.vnet.ibm.com</email>
</author>
<published>2014-11-30T14:01:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1c243c211c1141a14e5e418de314ed466c513ac6'/>
<id>1c243c211c1141a14e5e418de314ed466c513ac6</id>
<content type='text'>
commit 84eb186bc37c0900b53077ca21cf6dd15823a232 upstream.

There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
kernel panic during boot when vTPM is enabled in Power partition
configured in AMS mode.

vio_bus_probe calls vio_cmo_bus_probe which calls
tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
The problem is, vio_cmo_bus_probe is called before calling probe, which
for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
and sets up vtpm's CRQ and gets required data values.  Therefore,
since this has not yet been done, NULL is returned in attempt to get
the size for DMA allocation.

We added a NULL check.  In addition, a default buffer size will
be set when NULL is returned.

Signed-off-by: Hon Ching (Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.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 84eb186bc37c0900b53077ca21cf6dd15823a232 upstream.

There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
kernel panic during boot when vTPM is enabled in Power partition
configured in AMS mode.

vio_bus_probe calls vio_cmo_bus_probe which calls
tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
The problem is, vio_cmo_bus_probe is called before calling probe, which
for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
and sets up vtpm's CRQ and gets required data values.  Therefore,
since this has not yet been done, NULL is returned in attempt to get
the size for DMA allocation.

We added a NULL check.  In addition, a default buffer size will
be set when NULL is returned.

Signed-off-by: Hon Ching (Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm_tis: verify interrupt during init</title>
<updated>2015-03-06T22:40:50+00:00</updated>
<author>
<name>Scot Doyle</name>
<email>lkml14@scotdoyle.com</email>
</author>
<published>2014-09-24T22:41:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8716dbb11fc845a2fa28d889efe638b9dae86daf'/>
<id>8716dbb11fc845a2fa28d889efe638b9dae86daf</id>
<content type='text'>
commit 448e9c55c12d6bd4fa90a7e31d802e045666d7c8 upstream.

Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
not send IRQs while also having an ACPI TPM entry indicating that they
will be sent. These machines freeze on resume while the tpm_tis module
waits for an IRQ, eventually timing out.

When in interrupt mode, the tpm_tis module should receive an IRQ during
module init. Fall back to polling mode if none is received when expected.

Signed-off-by: Scot Doyle &lt;lkml14@scotdoyle.com&gt;
Tested-by: Michael Mullin &lt;masmullin@gmail.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
[phuewe: minor checkpatch fixed]
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.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 448e9c55c12d6bd4fa90a7e31d802e045666d7c8 upstream.

Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
not send IRQs while also having an ACPI TPM entry indicating that they
will be sent. These machines freeze on resume while the tpm_tis module
waits for an IRQ, eventually timing out.

When in interrupt mode, the tpm_tis module should receive an IRQ during
module init. Fall back to polling mode if none is received when expected.

Signed-off-by: Scot Doyle &lt;lkml14@scotdoyle.com&gt;
Tested-by: Michael Mullin &lt;masmullin@gmail.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
[phuewe: minor checkpatch fixed]
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>random: add and use memzero_explicit() for clearing data</title>
<updated>2014-11-14T16:47:55+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2014-08-27T03:16:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=25e1465ac3cfeafce34b3a47e773c4bc950054a3'/>
<id>25e1465ac3cfeafce34b3a47e773c4bc950054a3</id>
<content type='text'>
commit d4c5efdb97773f59a2b711754ca0953f24516739 upstream.

zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.

Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]

Fixes kernel bugzilla: 82041

Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&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 d4c5efdb97773f59a2b711754ca0953f24516739 upstream.

zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.

Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]

Fixes kernel bugzilla: 82041

Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: Provide a generic means to override the chip returned timeouts</title>
<updated>2014-09-17T16:04:02+00:00</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgunthorpe@obsidianresearch.com</email>
</author>
<published>2014-05-22T00:26:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d64269e30131fbd8a2228323266c9e84ee6ab80d'/>
<id>d64269e30131fbd8a2228323266c9e84ee6ab80d</id>
<content type='text'>
commit 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.

Some Atmel TPMs provide completely wrong timeouts from their
TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
new correct values via a DID/VID table in the TIS driver.

Tested on ARM using an AT97SC3204T FW version 37.16

[PHuewe: without this fix these 'broken' Atmel TPMs won't function on
older kernels]
Signed-off-by: "Berg, Christopher" &lt;Christopher.Berg@atmel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
[bwh: Backported to 3.10:
 - Adjust filename, context
 - s/chip-&gt;ops-&gt;/chip-&gt;vendor./]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.

Some Atmel TPMs provide completely wrong timeouts from their
TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
new correct values via a DID/VID table in the TIS driver.

Tested on ARM using an AT97SC3204T FW version 37.16

[PHuewe: without this fix these 'broken' Atmel TPMs won't function on
older kernels]
Signed-off-by: "Berg, Christopher" &lt;Christopher.Berg@atmel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
[bwh: Backported to 3.10:
 - Adjust filename, context
 - s/chip-&gt;ops-&gt;/chip-&gt;vendor./]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: missing tpm_chip_put in tpm_get_random()</title>
<updated>2014-09-17T16:03:57+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2014-05-09T11:23:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d4281c33c1086d80b2a5e3cd6081752e75795833'/>
<id>d4281c33c1086d80b2a5e3cd6081752e75795833</id>
<content type='text'>
commit 3e14d83ef94a5806a865b85b513b4e891923c19b upstream.

Regression in 41ab999c. Call to tpm_chip_put is missing. This
will cause TPM device driver not to unload if tmp_get_random()
is called.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.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 3e14d83ef94a5806a865b85b513b4e891923c19b upstream.

Regression in 41ab999c. Call to tpm_chip_put is missing. This
will cause TPM device driver not to unload if tmp_get_random()
is called.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>applicom: dereferencing NULL on error path</title>
<updated>2014-07-01T03:09:41+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-05-09T11:59:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fc7be702474fe5c795592047940c702783736294'/>
<id>fc7be702474fe5c795592047940c702783736294</id>
<content type='text'>
commit 8bab797c6e5724a43b7666ad70860712365cdb71 upstream.

This is a static checker fix.  The "dev" variable is always NULL after
the while statement so we would be dereferencing a NULL pointer here.

Fixes: 819a3eba4233 ('[PATCH] applicom: fix error handling')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.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 8bab797c6e5724a43b7666ad70860712365cdb71 upstream.

This is a static checker fix.  The "dev" variable is always NULL after
the while statement so we would be dereferencing a NULL pointer here.

Fixes: 819a3eba4233 ('[PATCH] applicom: fix error handling')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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