<feed xmlns='http://www.w3.org/2005/Atom'>
<title>starfive-tech/linux.git/drivers/char, branch visionfive_v1_5.13</title>
<subtitle>StarFive Tech Linux Kernel for VisionFive (JH7110) boards (mirror)</subtitle>
<id>https://git.radix-linux.su/starfive-tech/linux.git/atom?h=visionfive_v1_5.13</id>
<link rel='self' href='https://git.radix-linux.su/starfive-tech/linux.git/atom?h=visionfive_v1_5.13'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/'/>
<updated>2021-08-26T21:07:32+00:00</updated>
<entry>
<title>drivers/hw_random: Add StarFive JH7100 Random Number Generator driver</title>
<updated>2021-08-26T21:07:32+00:00</updated>
<author>
<name>Huan Feng</name>
<email>huan.feng@starfivetech.com</email>
</author>
<published>2021-01-07T19:35:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=df3d1f566b98ce17f0dd245f128ffd57614b2200'/>
<id>urn:sha1:df3d1f566b98ce17f0dd245f128ffd57614b2200</id>
<content type='text'>
</content>
</entry>
<entry>
<title>tpm_ftpm_tee: Free and unregister TEE shared memory during kexec</title>
<updated>2021-08-12T11:32:18+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.microsoft.com</email>
</author>
<published>2021-06-14T22:33:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=7a4e7a65d088df2f59c378668f8c10b500861aa8'/>
<id>urn:sha1:7a4e7a65d088df2f59c378668f8c10b500861aa8</id>
<content type='text'>
commit dfb703ad2a8d366b829818a558337be779746575 upstream.

dma-buf backed shared memory cannot be reliably freed and unregistered
during a kexec operation even when tee_shm_free() is called on the shm
from a .shutdown hook. The problem occurs because dma_buf_put() calls
fput() which then uses task_work_add(), with the TWA_RESUME parameter,
to queue tee_shm_release() to be called before the current task returns
to user mode. However, the current task never returns to user mode
before the kexec completes so the memory is never freed nor
unregistered.

Use tee_shm_alloc_kernel_buf() to avoid dma-buf backed shared memory
allocation so that tee_shm_free() can directly call tee_shm_release().
This will ensure that the shm can be freed and unregistered during a
kexec operation.

Fixes: 09e574831b27 ("tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE")
Fixes: 1760eb689ed6 ("tpm/tpm_ftpm_tee: add shutdown call back")
Cc: stable@vger.kernel.org
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.microsoft.com&gt;
Reviewed-by: Sumit Garg &lt;sumit.garg@linaro.org&gt;
Acked-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>virtio_console: Assure used length from device is limited</title>
<updated>2021-07-20T14:00:27+00:00</updated>
<author>
<name>Xie Yongji</name>
<email>xieyongji@bytedance.com</email>
</author>
<published>2021-05-25T12:56:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=21a06a244d2576f93cbc9ce9bf95814c2810c36a'/>
<id>urn:sha1:21a06a244d2576f93cbc9ce9bf95814c2810c36a</id>
<content type='text'>
[ Upstream commit d00d8da5869a2608e97cfede094dfc5e11462a46 ]

The buf-&gt;len might come from an untrusted device. This
ensures the value would not exceed the size of the buffer
to avoid data corruption or loss.

Signed-off-by: Xie Yongji &lt;xieyongji@bytedance.com&gt;
Acked-by: Jason Wang &lt;jasowang@redhat.com&gt;
Link: https://lore.kernel.org/r/20210525125622.1203-1-xieyongji@bytedance.com
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ipmi/watchdog: Stop watchdog timer when the current action is 'none'</title>
<updated>2021-07-19T08:04:51+00:00</updated>
<author>
<name>Petr Pavlu</name>
<email>petr.pavlu@suse.com</email>
</author>
<published>2021-05-13T12:26:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=238a7c0a5c3090b46e68de10003df8aebe5d8935'/>
<id>urn:sha1:238a7c0a5c3090b46e68de10003df8aebe5d8935</id>
<content type='text'>
commit 2253042d86f57d90a621ac2513a7a7a13afcf809 upstream.

When an IPMI watchdog timer is being stopped in ipmi_close() or
ipmi_ioctl(WDIOS_DISABLECARD), the current watchdog action is updated to
WDOG_TIMEOUT_NONE and _ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB) is called
to install this action. The latter function ends up invoking
__ipmi_set_timeout() which makes the actual 'Set Watchdog Timer' IPMI
request.

For IPMI 1.0, this operation results in fully stopping the watchdog timer.
For IPMI &gt;= 1.5, function __ipmi_set_timeout() always specifies the "don't
stop" flag in the prepared 'Set Watchdog Timer' IPMI request. This causes
that the watchdog timer has its action correctly updated to 'none' but the
timer continues to run. A problem is that IPMI firmware can then still log
an expiration event when the configured timeout is reached, which is
unexpected because the watchdog timer was requested to be stopped.

The patch fixes this problem by not setting the "don't stop" flag in
__ipmi_set_timeout() when the current action is WDOG_TIMEOUT_NONE which
results in stopping the watchdog timer. This makes the behaviour for
IPMI &gt;= 1.5 consistent with IPMI 1.0. It also matches the logic in
__ipmi_heartbeat() which does not allow to reset the watchdog if the
current action is WDOG_TIMEOUT_NONE as that would start the timer.

Signed-off-by: Petr Pavlu &lt;petr.pavlu@suse.com&gt;
Message-Id: &lt;10a41bdc-9c99-089c-8d89-fa98ce5ea080@suse.com&gt;
Cc: stable@vger.kernel.org
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: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status()</title>
<updated>2021-07-14T15:07:50+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko@kernel.org</email>
</author>
<published>2021-06-09T13:26:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=9d2da0b8863a207c2f3d8a97b2b038ea8c6592b1'/>
<id>urn:sha1:9d2da0b8863a207c2f3d8a97b2b038ea8c6592b1</id>
<content type='text'>
commit 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f upstream.

Do not tear down the system when getting invalid status from a TPM chip.
This can happen when panic-on-warn is used.

Instead, introduce TPM_TIS_INVALID_STATUS bitflag and use it to trigger
once the error reporting per chip. In addition, print out the value of
TPM_STS for improved forensics.

Link: https://lore.kernel.org/keyrings/YKzlTR1AzUigShtZ@kroah.com/
Fixes: 55707d531af6 ("tpm_tis: Add a check for invalid status")
Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>char: pcmcia: error out if 'num_bytes_read' is greater than 4 in set_protocol()</title>
<updated>2021-07-14T15:07:31+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2021-05-21T12:06:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=b91a065a5ba4d3ac173326894a8d2a064ef802e6'/>
<id>urn:sha1:b91a065a5ba4d3ac173326894a8d2a064ef802e6</id>
<content type='text'>
[ Upstream commit 37188559c610f1b7eec83c8e448936c361c578de ]

Theoretically, it will cause index out of bounds error if
'num_bytes_read' is greater than 4. As we expect it(and was tested)
never to be greater than 4, error out if it happens.

Fixes: c1986ee9bea3 ("[PATCH] New Omnikey Cardman 4000 driver")
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Link: https://lore.kernel.org/r/20210521120617.138396-1-yukuai3@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tpm_tis_spi: add missing SPI device ID entries</title>
<updated>2021-07-14T15:06:36+00:00</updated>
<author>
<name>Javier Martinez Canillas</name>
<email>javierm@redhat.com</email>
</author>
<published>2021-05-27T15:23:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=e34583fce2ea318225811a5accc3c1a8b59bb5ac'/>
<id>urn:sha1:e34583fce2ea318225811a5accc3c1a8b59bb5ac</id>
<content type='text'>
[ Upstream commit c46ed2281bbe4b84e6f3d4bdfb0e4e9ab813fa9d ]

The SPI core always reports a "MODALIAS=spi:&lt;foo&gt;", even if the device was
registered via OF. This means that this module won't auto-load if a DT has
for example has a node with a compatible "infineon,slb9670" string.

In that case kmod will expect a "MODALIAS=of:N*T*Cinfineon,slb9670" uevent
but instead will get a "MODALIAS=spi:slb9670", which is not present in the
kernel module aliases:

$ modinfo drivers/char/tpm/tpm_tis_spi.ko | grep alias
alias:          of:N*T*Cgoogle,cr50C*
alias:          of:N*T*Cgoogle,cr50
alias:          of:N*T*Ctcg,tpm_tis-spiC*
alias:          of:N*T*Ctcg,tpm_tis-spi
alias:          of:N*T*Cinfineon,slb9670C*
alias:          of:N*T*Cinfineon,slb9670
alias:          of:N*T*Cst,st33htpm-spiC*
alias:          of:N*T*Cst,st33htpm-spi
alias:          spi:cr50
alias:          spi:tpm_tis_spi
alias:          acpi*:SMO0768:*

To workaround this issue, add in the SPI device ID table all the entries
that are present in the OF device ID table.

Reported-by: Alexander Wellbrock &lt;a.wellbrock@mailbox.org&gt;
Signed-off-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Tested-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwrng: exynos - Fix runtime PM imbalance on error</title>
<updated>2021-07-14T15:06:21+00:00</updated>
<author>
<name>Łukasz Stelmach</name>
<email>l.stelmach@samsung.com</email>
</author>
<published>2021-05-05T18:29:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=56e208fd789a09beeca8524ff389486fdee0320c'/>
<id>urn:sha1:56e208fd789a09beeca8524ff389486fdee0320c</id>
<content type='text'>
[ Upstream commit 0cdbabf8bb7a6147f5adf37dbc251e92a1bbc2c7 ]

pm_runtime_resume_and_get() wraps around pm_runtime_get_sync() and
decrements the runtime PM usage counter in case the latter function
fails and keeps the counter balanced.

Signed-off-by: Łukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&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>Merge tag 'char-misc-5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2021-05-20T16:31:52+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-05-20T16:31:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=50f09a3dd5877bda888fc25c3d98937dcfb85539'/>
<id>urn:sha1:50f09a3dd5877bda888fc25c3d98937dcfb85539</id>
<content type='text'>
Pull char/misc driver fixes from Greg KH:
 "Here is a big set of char/misc/other driver fixes for 5.13-rc3.

  The majority here is the fallout of the umn.edu re-review of all prior
  submissions. That resulted in a bunch of reverts along with the
  "correct" changes made, such that there is no regression of any of the
  potential fixes that were made by those individuals. I would like to
  thank the over 80 different developers who helped with the review and
  fixes for this mess.

  Other than that, there's a few habanna driver fixes for reported
  issues, and some dyndbg fixes for reported problems.

  All of these have been in linux-next for a while with no reported
  problems"

* tag 'char-misc-5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (82 commits)
  misc: eeprom: at24: check suspend status before disable regulator
  uio_hv_generic: Fix another memory leak in error handling paths
  uio_hv_generic: Fix a memory leak in error handling paths
  uio/uio_pci_generic: fix return value changed in refactoring
  Revert "Revert "ALSA: usx2y: Fix potential NULL pointer dereference""
  dyndbg: drop uninformative vpr_info
  dyndbg: avoid calling dyndbg_emit_prefix when it has no work
  binder: Return EFAULT if we fail BINDER_ENABLE_ONEWAY_SPAM_DETECTION
  cdrom: gdrom: initialize global variable at init time
  brcmfmac: properly check for bus register errors
  Revert "brcmfmac: add a check for the status of usb_register"
  video: imsttfb: check for ioremap() failures
  Revert "video: imsttfb: fix potential NULL pointer dereferences"
  net: liquidio: Add missing null pointer checks
  Revert "net: liquidio: fix a NULL pointer dereference"
  media: gspca: properly check for errors in po1030_probe()
  Revert "media: gspca: Check the return value of write_bridge for timeout"
  media: gspca: mt9m111: Check write_bridge for timeout
  Revert "media: gspca: mt9m111: Check write_bridge for timeout"
  media: dvb: Add check on sp8870_readreg return
  ...
</content>
</entry>
<entry>
<title>char: hpet: add checks after calling ioremap</title>
<updated>2021-05-13T15:33:36+00:00</updated>
<author>
<name>Tom Seewald</name>
<email>tseewald@gmail.com</email>
</author>
<published>2021-05-03T11:56:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=b11701c933112d49b808dee01cb7ff854ba6a77a'/>
<id>urn:sha1:b11701c933112d49b808dee01cb7ff854ba6a77a</id>
<content type='text'>
The function hpet_resources() calls ioremap() two times, but in both
cases it does not check if ioremap() returned a null pointer. Fix this
by adding null pointer checks and returning an appropriate error.

Signed-off-by: Tom Seewald &lt;tseewald@gmail.com&gt;
Link: https://lore.kernel.org/r/20210503115736.2104747-30-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
