user/sven/linux.git/drivers/misc, branch v4.14.205

eeprom: at25: set minimum read/write access stride to 1

2020-10-29T08:07:20Z

commit 284f52ac1c6cfa1b2e5c11b84653dd90e4e91de7 upstream. SPI eeproms are addressed by byte. Signed-off-by: Christian Eggers Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200728092959.24600-1-ceggers@arri.de Signed-off-by: Greg Kroah-Hartman

misc: vop: add round_up(x,4) for vring_size to avoid kernel panic

2020-10-29T08:07:17Z

[ Upstream commit cc1a2679865a94b83804822996eed010a50a7c1d ] Since struct _mic_vring_info and vring are allocated together and follow vring, if the vring_size() is not four bytes aligned, which will cause the start address of struct _mic_vring_info is not four byte aligned. For example, when vring entries is 128, the vring_size() will be 5126 bytes. The _mic_vring_info struct layout in ddr looks like: 0x90002400: 00000000 00390000 EE010000 0000C0FF Here 0x39 is the avail_idx member, and 0xC0FFEE01 is the magic member. When EP use ioread32(magic) to reads the magic in RC's share memory, it will cause kernel panic on ARM64 platform due to the cross-byte io read. Here read magic in user space use le32toh(vr0->info->magic) will meet the same issue. So add round_up(x,4) for vring_size, then the struct _mic_vring_info will store in this way: 0x90002400: 00000000 00000000 00000039 C0FFEE01 Which will avoid kernel panic when read magic in struct _mic_vring_info. Signed-off-by: Sherry Sun Signed-off-by: Joakim Zhang Link: https://lore.kernel.org/r/20200929091106.24624-4-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

mic: vop: copy data to kernel space then write to io memory

2020-10-29T08:07:16Z

[ Upstream commit 675f0ad4046946e80412896436164d172cd92238 ] Read and write io memory should address align on ARCH ARM. Change to use memcpy_toio to avoid kernel panic caused by the address un-align issue. Signed-off-by: Sherry Sun Signed-off-by: Joakim Zhang Link: https://lore.kernel.org/r/20200929091106.24624-5-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

misc: mic: scif: Fix error handling path

2020-10-29T08:07:06Z

[ Upstream commit a81072a9c0ae734b7889929b0bc070fe3f353f0e ] Inside __scif_pin_pages(), when map_flags != SCIF_MAP_KERNEL it will call pin_user_pages_fast() to map nr_pages. However, pin_user_pages_fast() might fail with a return value -ERRNO. The return value is stored in pinned_pages->nr_pages. which in turn is passed to unpin_user_pages(), which expects pinned_pages->nr_pages >=0, else disaster. Fix this by assigning pinned_pages->nr_pages to 0 if pin_user_pages_fast() returns -ERRNO. Fixes: ba612aa8b487 ("misc: mic: SCIF memory registration and unregistration") Cc: John Hubbard Cc: Ira Weiny Cc: Dan Carpenter Reviewed-by: John Hubbard Signed-off-by: Souptick Joarder Link: https://lore.kernel.org/r/1600570295-29546-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

VMCI: check return value of get_user_pages_fast() for errors

2020-10-29T08:07:04Z

[ Upstream commit 90ca6333fd65f318c47bff425e1ea36c0a5539f6 ] In a couple of places in qp_host_get_user_memory(), get_user_pages_fast() is called without properly checking for errors. If e.g. -EFAULT is returned, this negative value will then be passed on to qp_release_pages(), which expects a u64 as input. Fix this by only calling qp_release_pages() when we have a positive number returned. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Signed-off-by: Alex Dewar Link: https://lore.kernel.org/r/20200825164522.412392-1-alex.dewar90@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

cxl: Fix kobject memleak

2020-08-21T07:48:08Z

[ Upstream commit 85c5cbeba8f4fb28e6b9bfb3e467718385f78f76 ] Currently the error return path from kobject_init_and_add() is not followed by a call to kobject_put() - which means we are leaking the kobject. Fix it by adding a call to kobject_put() in the error path of kobject_init_and_add(). Fixes: b087e6190ddc ("cxl: Export optional AFU configuration record in sysfs") Reported-by: Hulk Robot Signed-off-by: Wang Hai Acked-by: Andrew Donnellan Acked-by: Frederic Barrat Link: https://lore.kernel.org/r/20200602120733.5943-1-wanghai38@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

misc: atmel-ssc: lock with mutex instead of spinlock

2020-07-22T07:22:28Z

commit b037d60a3b1d1227609fd858fa34321f41829911 upstream. Uninterruptible context is not needed in the driver and causes lockdep warning because of mutex taken in of_alias_get_id(). Convert the lock to mutex to avoid the issue. Cc: stable@vger.kernel.org Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support") Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.pl Signed-off-by: Greg Kroah-Hartman

mei: bus: don't clean driver pointer

2020-07-22T07:22:27Z

commit e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream. It's not needed to set driver to NULL in mei_cl_device_remove() which is bus_type remove() handler as this is done anyway in __device_release_driver(). Actually this is causing an endless loop in driver_detach() on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty. as the check is always true in __device_release_driver() if (dev->driver != drv) return; The non upstream patch is causing this behavior, titled: 'vfio -- release device lock before userspace requests' Nevertheless the fix is correct also for the upstream. Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/ Cc: Cc: Andy Whitcroft Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman

mei: release me_cl object reference

2020-05-27T14:43:11Z

commit fc9c03ce30f79b71807961bfcb42be191af79873 upstream. Allow me_cl object to be freed by releasing the reference that was acquired by one of the search functions: __mei_me_cl_by_uuid_id() or __mei_me_cl_by_uuid() Cc: Reported-by: 亿一 Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20200512223140.32186-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman

misc: echo: Remove unnecessary parentheses and simplify check for zero

2020-04-24T06:00:51Z

[ Upstream commit 85dc2c65e6c975baaf36ea30f2ccc0a36a8c8add ] Clang warns when multiple pairs of parentheses are used for a single conditional statement. drivers/misc/echo/echo.c:384:27: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] if ((ec->nonupdate_dwell == 0)) { ~~~~~~~~~~~~~~~~~~~~^~~~ drivers/misc/echo/echo.c:384:27: note: remove extraneous parentheses around the comparison to silence this warning if ((ec->nonupdate_dwell == 0)) { ~ ^ ~ drivers/misc/echo/echo.c:384:27: note: use '=' to turn this equality comparison into an assignment if ((ec->nonupdate_dwell == 0)) { ^~ = 1 warning generated. Remove them and while we're at it, simplify the zero check as '!var' is used more than 'var == 0'. Reported-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin