Pull staging driver updates from Greg KH: "Here is the big set of staging driver patches for 6.0-rc1. Another round where we removed more lines of code than added, always a nice progression. Some of that came from the movement of the vme code back into staging, and removal of some other of the vme driver code as there are no known users and it is very obsolete and unmaintained. It can be added back easily if someone offers to maintain it. Other than that this merge has lots of little things: - huge cleanups for r8188eu driver - minor cleanups for other wifi drivers - tiny loop fixes for greybus code - other small coding style fixes All of these have been in linux-next for a while with no reported issues" * tag 'staging-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (191 commits) staging: r8188eu: fix potential uninitialised variable use in rtw_pwrctrl.c staging: r8188eu: remove initializer from ret in rtw_pwr_wakeup staging: vt6655: Convert macro vt6655_mac_clear_stck_ds to function staging: vt6655: Rename MACvClearStckDS staging: fbtft: core: set smem_len before fb_deferred_io_init call staging: r8188eu: convert rtw_pwr_wakeup to correct error code semantics staging: r8188eu: make dump_chip_info() static staging: r8188eu: remove DoReserved prototype staging: r8188eu: remove OnAtim prototype staging: r8188eu: remove SetHwReg8188EU() staging: r8188eu: make update_TSF() and correct_TSF() static staging: r8188eu: remove unused parameter from update_TSF() staging: r8188eu: remove unused parameter from correct_TSF() staging: r8188eu: remove HW_VAR_SET_OPMODE from SetHwReg8188EU() staging: pi433: remove duplicated comments staging: qlge: refine variable name staging: vt6655: Convert macro vt6655_mac_word_reg_bits_off to function staging: vt6655: Convert macro vt6655_mac_reg_bits_off to function staging: vt6655: Convert macro vt6655_mac_word_reg_bits_on to function staging: vt6655: Convert macro vt6655_mac_reg_bits_on to function ...
The ANDROID config symbol is only used to guard the binder config symbol and to inject completely random config changes. Remove it as it is obviously a bad idea. Acked-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220629150102.1582425-2-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The VME subsystem graduated from staging into a top-level subsystem in
2012, with commit db3b9e990e75 ("Staging: VME: move VME drivers out of
staging") stating:
The VME device drivers have not moved out yet due to some API
questions they are still working through, that should happen soon,
hopefully.
However, this never happened: maintenance of drivers/vme effectively
stopped in 2017, with all subsequent changes being treewide cleanups.
No hardware driver remains in staging, only the limited user-level
access, and I just removed one of the two bridge drivers and the only
remaining board.
drivers/staging/vme/devices/ was recently moved to
drivers/staging/vme_user/, but as the vme_user driver is the only one
remaining for this subsystem, it is easier to just move the remaining
three source files into this directory rather than keeping the original
hierarchy.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20220606084109.4108188-3-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull more SCSI updates from James Bottomley: "Mostly small bug fixes plus other trivial updates. The major change of note is moving ufs out of scsi and a minor update to lpfc vmid handling" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (24 commits) scsi: qla2xxx: Remove unused 'ql_dm_tgt_ex_pct' parameter scsi: qla2xxx: Remove setting of 'req' and 'rsp' parameters scsi: mpi3mr: Fix kernel-doc scsi: lpfc: Add support for ATTO Fibre Channel devices scsi: core: Return BLK_STS_TRANSPORT for ALUA transitioning scsi: sd_zbc: Prevent zone information memory leak scsi: sd: Fix potential NULL pointer dereference scsi: mpi3mr: Rework mrioc->bsg_device model to fix warnings scsi: myrb: Fix up null pointer access on myrb_cleanup() scsi: core: Unexport scsi_bus_type scsi: sd: Don't call blk_cleanup_disk() in sd_probe() scsi: ufs: ufshcd: Delete unnecessary NULL check scsi: isci: Fix typo in comment scsi: pmcraid: Fix typo in comment scsi: smartpqi: Fix typo in comment scsi: qedf: Fix typo in comment scsi: esas2r: Fix typo in comment scsi: storvsc: Fix typo in comment scsi: ufs: Split the drivers/scsi/ufs directory scsi: qla1280: Remove redundant variable ...
Pull hardware timestamping subsystem from Thierry Reding: "This contains the new HTE (hardware timestamping engine) subsystem that has been in the works for a couple of months now. The infrastructure provided allows for drivers to register as hardware timestamp providers, while consumers will be able to request events that they are interested in (such as GPIOs and IRQs) to be timestamped by the hardware providers. Note that this currently supports only one provider, but there seems to be enough interest in this functionality and we expect to see more drivers added once this is merged" [ Linus Walleij mentions the Intel PMC in the Elkhart and Tiger Lake platforms as another future timestamp provider ] * tag 'hte/for-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: dt-bindings: timestamp: Correct id path dt-bindings: Renamed hte directory to timestamp hte: Uninitialized variable in hte_ts_get() hte: Fix off by one in hte_push_ts_ns() hte: Fix possible use-after-free in tegra_hte_test_remove() hte: Remove unused including <linux/version.h> MAINTAINERS: Add HTE Subsystem hte: Add Tegra HTE test driver tools: gpio: Add new hardware clock type gpiolib: cdev: Add hardware timestamp clock type gpio: tegra186: Add HTE support gpiolib: Add HTE support dt-bindings: Add HTE bindings hte: Add Tegra194 HTE kernel provider drivers: Add hardware timestamp engine (HTE) subsystem Documentation: Add HTE subsystem guide
Pull staging driver updates from Greg KH:
"Here is the big set of staging driver updates for 5.19-rc1.
Lots of forward progress happened this development cycle, one driver
(wfx wireless driver) got merged into the real portion of the kernel,
and another one (unisys) was removed as no one is around anymore to
take care of it and no one has the hardware. Combined with loads of
tiny driver cleanups overall we removed 13k lines of code from the
tree, a nice improvement.
Other than the wfx and unisys driver changes the major points of this
merge is:
- r8188eu driver cleanups. So many cleanups. It's amazing just how
many things have been cleaned up here, and yet, how many remain to
go. Lots of work happened here, and it doesn't look to slow down
any time soon.
- other wifi driver cleanups. Not as many as the r8188eu driver, but
still pretty impressive from a janitorial point of view.
- bcm2853 driver cleanups
- other very minor driver cleanups
All of these have been in the linux-next tree for weeks with no
reported issues"
* tag 'staging-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (363 commits)
staging: r8188eu: remove include/rtw_debug.h
staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan()
staging: r8188eu: delete rtw_wx_read/write32()
staging: r8188eu: Remove multiple assignments
staging: r8188eu: add check for kzalloc
staging: r8188eu: fix warnings in rtw_wlan_util
staging: r8188eu: fix warnings in rtw_pwrctrl
staging: r8188eu: fix warnings in rtw_p2p
staging: rtl8712: fix uninit-value in r871xu_drv_init()
staging: rtl8712: fix uninit-value in usb_read8() and friends
staging: rtl8712: add error handler in r8712_usbctrl_vendorreq()
staging: r8188eu: remove _drv_ defines from include/rtw_debug.h
staging: vc04_services: remove unused macro
staging: rtl8192u: remove null check after call container_of()
staging: rtl8192e: remove null check after call container_of()
staging: ks7010: remove null check after call container_of()
staging: r8188eu: remove HW_VAR_AC_PARAM_BE from SetHwReg8188EU()
staging: r8188eu: assoc_rsp and assoc_rsp_len are not used
staging: r8188eu: last_rx_mgnt_pkts is set but not used
staging: r8188eu: simplify error handling in recv_func_prehandle
...
Split the drivers/scsi/ufs directory into 'core' and 'host' directories under the drivers/ufs/ directory. Move shared header files into the include/ufs/ directory. This separation makes it clear which header files UFS drivers are allowed to include (include/ufs/*.h) and which header files UFS drivers are not allowed to include (drivers/ufs/core/*.h). Update the MAINTAINERS file. Add myself as a UFS reviewer. Link: https://lore.kernel.org/r/20220511212552.655341-1-bvanassche@acm.org Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Avri Altman <avri.altman@wdc.com> Cc: Bean Huo <beanhuo@micron.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Keoseong Park <keosung.park@samsung.com> Tested-by: Bean Huo <beanhuo@micron.com> Tested-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Acked-by: Avri Altman <avri.altman@wdc.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some devices can timestamp system lines/signals/Buses in real-time using the hardware counter or other hardware means which can give finer granularity and help avoid jitter introduced by software timestamping. To utilize such functionality, this patchset creates HTE subsystem where devices can register themselves as providers so that the consumers devices can request specific line from the providers. The patch also adds compilation support in Makefile and menu options in Kconfig. The provider does following: - Registers chip with the framework. - Provides translation hook to convert logical line id. - Provides enable/disable, request/release callbacks. - Pushes timestamp data to HTE subsystem. The consumer does following: - Initializes line attribute. - Gets HTE timestamp descriptor. - Requests timestamp functionality. - Puts HTE timestamp descriptor. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
The CXL specification claims S3 support at a hardware level, but at a system software level there are some missing pieces. Section 9.4 (CXL 2.0) rightly claims that "CXL mem adapters may need aux power to retain memory context across S3", but there is no enumeration mechanism for the OS to determine if a given adapter has that support. Moreover the save state and resume image for the system may inadvertantly end up in a CXL device that needs to be restored before the save state is recoverable. I.e. a circular dependency that is not resolvable without a third party save-area. Arrange for the cxl_mem driver to fail S3 attempts. This still nominaly allows for suspend, but requires unbinding all CXL memory devices before the suspend to ensure the typical DRAM flow is taken. The cxl_mem unbind flow is intended to also tear down all CXL memory regions associated with a given cxl_memdev. It is reasonable to assume that any device participating in a System RAM range published in the EFI memory map is covered by aux power and save-area outside the device itself. So this restriction can be minimized in the future once pre-existing region enumeration support arrives, and perhaps a spec update to clarify if the EFI memory map is sufficent for determining the range of devices managed by platform-firmware for S3 support. Per Rafael, if the CXL configuration prevents suspend then it should fail early before tasks are frozen, and mem_sleep should stop showing 'mem' as an option [1]. Effectively CXL augments the platform suspend ->valid() op since, for example, the ACPI ops are not aware of the CXL / PCI dependencies. Given the split role of platform firmware vs OS provisioned CXL memory it is up to the cxl_mem driver to determine if the CXL configuration has elements that platform firmware may not be prepared to restore. Link: https://lore.kernel.org/r/CAJZ5v0hGVN_=3iU8OLpHY3Ak35T5+JcBM-qs8SbojKrpd0VXsA@mail.gmail.com [1] Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/165066828317.3907920.5690432272182042556.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The Unisys sub-tree of drivers/staging contains three drivers for the "Unisys Secure Partition" (s-Par(R)): visorhba, visorinput, visornic. They have no maintainers, in fact the only one that is listed in MAINTAINERS has an unreacheable email address. During 2021 and 2022 several patches have been submitted to these drivers but nobody at Unisys cared of reviewing the changes. Probably, also the "sparmaintainer" internal list of unisys.com is not anymore read by interested Unisys' engineers. Therefore, remove the drivers/staging/unisys directory and delete the relevant entries in the MAINTAINERS, Kconfig, Makefile files, then remove also the drivers/visorbus directory which is not anymore needed (it contained the driver for the virtualized bus for the Unisys s-Par firmware). Cc: David Kershner <david.kershner@unisys.com> Cc: <sparmaintainer@unisys.com> Cc: Ken Cox <jkc@redhat.com> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20220414103217.32058-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>