<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/char, branch v5.4.19</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.4.19</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.4.19'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2020-02-05T21:22:41+00:00</updated>
<entry>
<title>ttyprintk: fix a potential deadlock in interrupt context issue</title>
<updated>2020-02-05T21:22:41+00:00</updated>
<author>
<name>Zhenzhong Duan</name>
<email>zhenzhong.duan@gmail.com</email>
</author>
<published>2020-01-13T03:48:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f39406a925b09130b5baa53bb09d416ef64e38a7'/>
<id>urn:sha1:f39406a925b09130b5baa53bb09d416ef64e38a7</id>
<content type='text'>
commit 9a655c77ff8fc65699a3f98e237db563b37c439b upstream.

tpk_write()/tpk_close() could be interrupted when holding a mutex, then
in timer handler tpk_write() may be called again trying to acquire same
mutex, lead to deadlock.

Google syzbot reported this issue with CONFIG_DEBUG_ATOMIC_SLEEP
enabled:

BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:938
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/1
1 lock held by swapper/1/0:
...
Call Trace:
  &lt;IRQ&gt;
  dump_stack+0x197/0x210
  ___might_sleep.cold+0x1fb/0x23e
  __might_sleep+0x95/0x190
  __mutex_lock+0xc5/0x13c0
  mutex_lock_nested+0x16/0x20
  tpk_write+0x5d/0x340
  resync_tnc+0x1b6/0x320
  call_timer_fn+0x1ac/0x780
  run_timer_softirq+0x6c3/0x1790
  __do_softirq+0x262/0x98c
  irq_exit+0x19b/0x1e0
  smp_apic_timer_interrupt+0x1a3/0x610
  apic_timer_interrupt+0xf/0x20
  &lt;/IRQ&gt;

See link https://syzkaller.appspot.com/bug?extid=2eeef62ee31f9460ad65 for
more details.

Fix it by using spinlock in process context instead of mutex and having
interrupt disabled in critical section.

Reported-by: syzbot+2eeef62ee31f9460ad65@syzkaller.appspotmail.com
Signed-off-by: Zhenzhong Duan &lt;zhenzhong.duan@gmail.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Link: https://lore.kernel.org/r/20200113034842.435-1-zhenzhong.duan@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>hwrng: omap3-rom - Fix missing clock by probing with device tree</title>
<updated>2020-01-26T09:01:03+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2019-09-14T21:02:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9af27538c55d7f838e1a0e465e40deaa033bf396'/>
<id>urn:sha1:9af27538c55d7f838e1a0e465e40deaa033bf396</id>
<content type='text'>
[ Upstream commit 0c0ef9ea6f3f0d5979dc7b094b0a184c1a94716b ]

Commit 0ed266d7ae5e ("clk: ti: omap3: cleanup unnecessary clock aliases")
removed old omap3 clock framework aliases but caused omap3-rom-rng to
stop working with clock not found error.

Based on discussions on the mailing list it was requested by Tero Kristo
that it would be best to fix this issue by probing omap3-rom-rng using
device tree to provide a proper clk property. The other option would be
to add back the missing clock alias, but that does not help moving things
forward with removing old legacy platform_data.

Let's also add a proper device tree binding and keep it together with
the fix.

Cc: devicetree@vger.kernel.org
Cc: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Cc: Adam Ford &lt;aford173@gmail.com&gt;
Cc: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Cc: Rob Herring &lt;robh+dt@kernel.org&gt;
Cc: Sebastian Reichel &lt;sre@kernel.org&gt;
Cc: Tero Kristo &lt;t-kristo@ti.com&gt;
Fixes: 0ed266d7ae5e ("clk: ti: omap3: cleanup unnecessary clock aliases")
Reported-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ipmi: Fix memory leak in __ipmi_bmc_register</title>
<updated>2020-01-26T09:01:02+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-10-21T20:06:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=57d748f43f0742f58b5cf01b2d7b9a0d2e113e3d'/>
<id>urn:sha1:57d748f43f0742f58b5cf01b2d7b9a0d2e113e3d</id>
<content type='text'>
commit 4aa7afb0ee20a97fbf0c5bab3df028d5fb85fdab upstream.

In the impelementation of __ipmi_bmc_register() the allocated memory for
bmc should be released in case ida_simple_get() fails.

Fixes: 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name")
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Message-Id: &lt;20191021200649.1511-1-navid.emamdoost@gmail.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm: Handle negative priv-&gt;response_len in tpm_common_read()</title>
<updated>2020-01-14T19:08:21+00:00</updated>
<author>
<name>Tadeusz Struk</name>
<email>tadeusz.struk@intel.com</email>
</author>
<published>2020-01-07T22:04:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=18c395532370dc30d4abe526d77a58c2372add2b'/>
<id>urn:sha1:18c395532370dc30d4abe526d77a58c2372add2b</id>
<content type='text'>
commit a430e67d9a2c62a8c7b315b99e74de02018d0a96 upstream.

The priv-&gt;response_length can hold the size of an response or an negative
error code, and the tpm_common_read() needs to handle both cases correctly.
Changed the type of response_length to signed and accounted for negative
value in tpm_common_read().

Cc: stable@vger.kernel.org
Fixes: d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode")
Reported-by: Laura Abbott &lt;labbott@redhat.com&gt;
Signed-off-by: Tadeusz Struk &lt;tadeusz.struk@intel.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"</title>
<updated>2020-01-14T19:08:21+00:00</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2019-11-26T13:17:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2e1a0a118abe853cd9217368a551f53a0cdff15b'/>
<id>urn:sha1:2e1a0a118abe853cd9217368a551f53a0cdff15b</id>
<content type='text'>
commit aa4a63dd981682b1742baa01237036e48bc11923 upstream.

There has been a bunch of reports (one from kernel bugzilla linked)
reporting that when this commit is applied it causes on some machines
boot freezes.

Unfortunately hardware where this commit causes a failure is not widely
available (only one I'm aware is Lenovo T490), which means we cannot
predict yet how long it will take to properly fix tpm_tis interrupt
probing.

Thus, the least worst short term action is to revert the code to the
state before this commit. In long term we need fix the tpm_tis probing
code to work on machines that Stefan's fix was supposed to fix.

Fixes: 21df4a8b6018 ("tpm_tis: reserve chip for duration of tpm_tis_core_init")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205935
Cc: stable@vger.kernel.org
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Xiaoping Zhou &lt;xiaoping.zhou@intel.com&gt;
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reported-by: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm: Revert "tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts"</title>
<updated>2020-01-14T19:08:21+00:00</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2019-11-26T13:17:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=495e9443cab9db3b8d51e837923f8170b3085c71'/>
<id>urn:sha1:495e9443cab9db3b8d51e837923f8170b3085c71</id>
<content type='text'>
commit dda8b2af395b2ed508e2ef314ae32e122841b447 upstream.

There has been a bunch of reports (one from kernel bugzilla linked)
reporting that when this commit is applied it causes on some machines
boot freezes.

Unfortunately hardware where this commit causes a failure is not widely
available (only one I'm aware is Lenovo T490), which means we cannot
predict yet how long it will take to properly fix tpm_tis interrupt
probing.

Thus, the least worst short term action is to revert the code to the
state before this commit. In long term we need fix the tpm_tis probing
code to work on machines that Stefan's fix was supposed to fix.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=205935
Fixes: 1ea32c83c699 ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts")
Cc: stable@vger.kernel.org
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Xiaoping Zhou &lt;xiaoping.zhou@intel.com&gt;
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reported-by: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm: Revert "tpm_tis: reserve chip for duration of tpm_tis_core_init"</title>
<updated>2020-01-14T19:08:20+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2019-12-30T23:19:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6de025ef5840dff4ddb6e9043ae6ca3d1b95c1cd'/>
<id>urn:sha1:6de025ef5840dff4ddb6e9043ae6ca3d1b95c1cd</id>
<content type='text'>
commit 9550f210492c6f88415709002f42a9d15c0e6231 upstream.

Revert a commit, which was included in Linux v5.5-rc3 because it did not
properly fix the issues it was supposed to fix.

Fixes: 21df4a8b6018 ("tpm_tis: reserve chip for duration of tpm_tis_core_init")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205935
Cc: stable@vger.kernel.org
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Xiaoping Zhou &lt;xiaoping.zhou@intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm/tpm_ftpm_tee: add shutdown call back</title>
<updated>2020-01-12T11:21:41+00:00</updated>
<author>
<name>Pavel Tatashin</name>
<email>pasha.tatashin@soleen.com</email>
</author>
<published>2019-12-04T15:40:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=adbc8231cec9a4e83310d329fb6037feed53bbb1'/>
<id>urn:sha1:adbc8231cec9a4e83310d329fb6037feed53bbb1</id>
<content type='text'>
[ Upstream commit 1760eb689ed68c6746744aff2092bff57c78d907 ]

Add shutdown call back to close existing session with fTPM TA
to support kexec scenario.

Add parentheses to function names in comments as specified in kdoc.

Signed-off-by: Thirupathaiah Annapureddy &lt;thiruan@microsoft.com&gt;
Signed-off-by: Pavel Tatashin &lt;pasha.tatashin@soleen.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Tested-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tpm: fix invalid locking in NONBLOCKING mode</title>
<updated>2019-12-31T15:45:52+00:00</updated>
<author>
<name>Tadeusz Struk</name>
<email>tadeusz.struk@intel.com</email>
</author>
<published>2019-12-12T17:48:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4d6ebc4c4950595414722dfadd0b361f5a05d37e'/>
<id>urn:sha1:4d6ebc4c4950595414722dfadd0b361f5a05d37e</id>
<content type='text'>
commit d23d12484307b40eea549b8a858f5fffad913897 upstream.

When an application sends TPM commands in NONBLOCKING mode
the driver holds chip-&gt;tpm_mutex returning from write(),
which triggers: "WARNING: lock held when returning to user space".
To fix this issue the driver needs to release the mutex before
returning and acquire it again in tpm_dev_async_work() before
sending the command.

Cc: stable@vger.kernel.org
Fixes: 9e1b74a63f776 (tpm: add support for nonblocking operation)
Reported-by: Jeffrin Jose T &lt;jeffrin@rajagiritech.edu.in&gt;
Tested-by: Jeffrin Jose T &lt;jeffrin@rajagiritech.edu.in&gt;
Signed-off-by: Tadeusz Struk &lt;tadeusz.struk@intel.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm_tis: reserve chip for duration of tpm_tis_core_init</title>
<updated>2019-12-31T15:45:52+00:00</updated>
<author>
<name>Jerry Snitselaar</name>
<email>jsnitsel@redhat.com</email>
</author>
<published>2019-12-11T23:54:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fed4697a04ad49a9caa10bee91380d05f7000603'/>
<id>urn:sha1:fed4697a04ad49a9caa10bee91380d05f7000603</id>
<content type='text'>
commit 21df4a8b6018b842d4db181a8b24166006bad3cd upstream.

Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when
issuing commands to the tpm during initialization, just reserve the
chip after wait_startup, and release it when we are ready to call
tpm_chip_register.

Cc: Christian Bundy &lt;christianbundy@fraction.io&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Cc: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Cc: Jason Gunthorpe &lt;jgg@ziepe.ca&gt;
Cc: Stefan Berger &lt;stefanb@linux.vnet.ibm.com&gt;
Cc: stable@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")
Suggested-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
