linux-stable.git/drivers/misc, branch v5.10.9 Linux kernel stable tree habanalabs: Fix memleak in hl_device_reset 2021-01-19T17:27:25+00:00 Dinghao Liu dinghao.liu@zju.edu.cn 2020-12-26T07:27:14+00:00 8c3520e21f6b048901534463233d7aa73900a112 [ Upstream commit b000700d6db50c933ce8b661154e26cf4ad06dba ] When kzalloc() fails, we should execute hl_mmu_fini() to release the MMU module. It's the same when hl_ctx_init() fails. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b000700d6db50c933ce8b661154e26cf4ad06dba ]

When kzalloc() fails, we should execute hl_mmu_fini()
to release the MMU module. It's the same when
hl_ctx_init() fails.

Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
habanalabs: register to pci shutdown callback 2021-01-19T17:27:25+00:00 Oded Gabbay ogabbay@kernel.org 2020-12-14T10:52:06+00:00 c78cff56baad24ebb10d748e1a1b78bae203debe [ Upstream commit fcaebc7354188b0d708c79df4390fbabd4d9799d ] We need to make sure our device is idle when rebooting a virtual machine. This is done in the driver level. The firmware will later handle FLR but we want to be extra safe and stop the devices until the FLR is handled. Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit fcaebc7354188b0d708c79df4390fbabd4d9799d ]

We need to make sure our device is idle when rebooting a virtual
machine. This is done in the driver level.

The firmware will later handle FLR but we want to be extra safe and
stop the devices until the FLR is handled.

Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
habanalabs/gaudi: retry loading TPC f/w on -EINTR 2021-01-19T17:27:24+00:00 Oded Gabbay ogabbay@kernel.org 2020-12-09T21:07:58+00:00 68a9abf536ff3c54b80983780315d8426da43125 [ Upstream commit 98e8781f008372057bd5cb059ca6b507371e473d ] If loading the firmware file for the TPC f/w was interrupted, try to do it again, up to 5 times. Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 98e8781f008372057bd5cb059ca6b507371e473d ]

If loading the firmware file for the TPC f/w was interrupted, try
to do it again, up to 5 times.

Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
habanalabs: adjust pci controller init to new firmware 2021-01-19T17:27:24+00:00 Oded Gabbay ogabbay@kernel.org 2020-12-09T17:50:46+00:00 8d0522d9688c787b33fa2dca17ee298829fafaba [ Upstream commit 377182a3cc5ae6cc17fb04d06864c975f9f71c18 ] When the firmware security is enabled, the pcie_aux_dbi_reg_addr register in the PCI controller is blocked. Therefore, ignore the result of writing to this register and assume it worked. Also remove the prints on errors in the internal ELBI write function. If the security is enabled, the firmware is responsible for setting this register correctly so we won't have any problem. If the security is disabled, the write will work (unless something is totally broken at the PCI level and then the whole sequence will fail). In addition, remove a write to register pcie_aux_dbi_reg_addr+4, which was never actually needed. Moreover, PCIE_DBI registers are blocked to access from host when firmware security is enabled. Use a different register to flush the writes. Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 377182a3cc5ae6cc17fb04d06864c975f9f71c18 ]

When the firmware security is enabled, the pcie_aux_dbi_reg_addr
register in the PCI controller is blocked. Therefore, ignore
the result of writing to this register and assume it worked. Also
remove the prints on errors in the internal ELBI write function.

If the security is enabled, the firmware is responsible for setting
this register correctly so we won't have any problem.

If the security is disabled, the write will work (unless something
is totally broken at the PCI level and then the whole sequence
will fail).

In addition, remove a write to register pcie_aux_dbi_reg_addr+4,
which was never actually needed.

Moreover, PCIE_DBI registers are blocked to access from host when
firmware security is enabled. Use a different register to flush the
writes.

Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
misc: vmw_vmci: fix kernel info-leak by initializing dbells in vmci_ctx_get_chkpt_doorbells() 2021-01-06T13:56:52+00:00 Anant Thazhemadam anant.thazhemadam@gmail.com 2020-11-22T22:45:34+00:00 f290cffdf761a52b34a405777557d6518b4488ea commit 31dcb6c30a26d32650ce134820f27de3c675a45a upstream. A kernel-infoleak was reported by syzbot, which was caused because dbells was left uninitialized. Using kzalloc() instead of kmalloc() fixes this issue. Reported-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com Tested-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20201122224534.333471-1-anant.thazhemadam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 31dcb6c30a26d32650ce134820f27de3c675a45a upstream.

A kernel-infoleak was reported by syzbot, which was caused because
dbells was left uninitialized.
Using kzalloc() instead of kmalloc() fixes this issue.

Reported-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com
Tested-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com
Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Link: https://lore.kernel.org/r/20201122224534.333471-1-anant.thazhemadam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
misc: pci_endpoint_test: fix return value of error branch 2020-12-30T10:53:45+00:00 Xiongfeng Wang wangxiongfeng2@huawei.com 2020-11-19T12:49:18+00:00 096ee6ebd01e81305e6646b27d5ec238cbaa963d [ Upstream commit 1749c90489f2afa6b59dbf3ab59d58a9014c84a1 ] We return 'err' in the error branch, but this variable may be set as zero before. Fix it by setting 'err' as a negative value before we goto the error label. Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Link: https://lore.kernel.org/r/1605790158-6780-1-git-send-email-wangxiongfeng2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 1749c90489f2afa6b59dbf3ab59d58a9014c84a1 ]

We return 'err' in the error branch, but this variable may be set as
zero before. Fix it by setting 'err' as a negative value before we
goto the error label.

Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Link: https://lore.kernel.org/r/1605790158-6780-1-git-send-email-wangxiongfeng2@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'at24-fixes-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-current 2020-12-11T22:23:30+00:00 Wolfram Sang wsa@kernel.org 2020-12-11T22:23:30+00:00 e977aaf899a6d3b3d6658da66e262b6e307ae3a2 at24 fixes for v5.10 - fix NVMEM name with custom AT24 device name 
at24 fixes for v5.10

- fix NVMEM name with custom AT24 device name
Revert "mei: virtio: virtualization frontend driver" 2020-12-06T09:36:17+00:00 Michael S. Tsirkin mst@redhat.com 2020-12-05T19:38:46+00:00 264f53b41946dcabb2b3304190839ab5670c7825 This reverts commit d162219c655c8cf8003128a13840d6c1e183fb80. The device uses a VIRTIO device ID out of a not-for-production range. Releasing Linux using an ID out of this range will make it conflict with development setups. An official request to reserve an ID for an MEI device is yet to be submitted to the virtio TC, thus there's no chance it will be reserved and fixed in time before the next release. Once requested it usually takes 2-3 weeks to land in the spec, which means the device can be supported with the official ID in the next Linux version if contributors act quickly. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Alexander Usyskin <alexander.usyskin@intel.com> Cc: Wang Yu <yu1.wang@intel.com> Cc: Liu Shuo <shuo.a.liu@intel.com> Link: https://lore.kernel.org/r/20201205193625.469773-1-mst@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit d162219c655c8cf8003128a13840d6c1e183fb80.

The device uses a VIRTIO device ID out of a not-for-production range.
Releasing Linux using an ID out of this range will make it conflict with
development setups. An official request to reserve an ID for an MEI
device is yet to be submitted to the virtio TC, thus there's no chance
it will be reserved and fixed in time before the next release.

Once requested it usually takes 2-3 weeks to land in the spec, which
means the device can be supported with the official ID in the next Linux
version if contributors act quickly.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Alexander Usyskin <alexander.usyskin@intel.com>
Cc: Wang Yu <yu1.wang@intel.com>
Cc: Liu Shuo <shuo.a.liu@intel.com>
Link: https://lore.kernel.org/r/20201205193625.469773-1-mst@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
misc: eeprom: at24: fix NVMEM name with custom AT24 device name 2020-12-04T09:46:36+00:00 Diego Santa Cruz Diego.SantaCruz@spinetix.com 2020-12-03T21:47:03+00:00 4e302c3b568eaf2aeebba804c07aba5d921a8c9e When the "label" property is set on the AT24 EEPROM the NVMEM devid is set to NVMEM_DEVID_NONE, but it is not effective since there is a leftover line setting it back to NVMEM_DEVID_AUTO a few lines after. Fixes: 61f764c307f6 ("eeprom: at24: Support custom device names for AT24 EEPROMs") Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> 
When the "label" property is set on the AT24 EEPROM the NVMEM devid is
set to NVMEM_DEVID_NONE, but it is not effective since there is a
leftover line setting it back to NVMEM_DEVID_AUTO a few lines after.

Fixes: 61f764c307f6 ("eeprom: at24: Support custom device names for AT24 EEPROMs")
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
habanalabs: put devices before driver removal 2020-11-30T08:30:16+00:00 Ofir Bitton obitton@habana.ai 2020-11-29T07:34:12+00:00 5555b7c56bdec7a29c789fec27f84d40f52fbdfa Driver never puts its device and control_device objects, hence a memory leak is introduced every driver removal. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> 
Driver never puts its device and control_device objects, hence
a memory leak is introduced every driver removal.

Signed-off-by: Ofir Bitton <obitton@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>