aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-06-14Merge tag 'imx-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixesArnd Bergmann1-1/+1
i.MX fixes for 5.19: - Correct i.MX7 power domain for HSIC USB PHY node to fix an USB Host issue, that is all downstream events will be lost if USB host is runtime suspended. - Fix i.MX8M blk-ctrl LCDIF2 power domain to point to refer to the correct clock. - Correct i.MX6Q/DL PU regulator ramp delay to fix some peripherals power-up failure especially when the chip is at a low temperature. - Fix capacitive touch reset polarity for imx6qdl-colibri board. * tag 'imx-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: soc: imx: imx8m-blk-ctrl: fix display clock for LCDIF2 power domain ARM: dts: imx6qdl-colibri: Fix capacitive touch reset polarity ARM: dts: imx6qdl: correct PU regulator ramp delay ARM: dts: imx7: Move hsic_phy power domain to HSIC PHY node Link: https://lore.kernel.org/r/20220614095515.GU254723@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-06-14drm/ttm: fix bulk move handling v2Christian König2-24/+50
The resource must be on the LRU before ttm_lru_bulk_move_add() is called and we need to check if the BO is pinned or not before adding it. Additional to that we missed taking the LRU spinlock in ttm_bo_unpin(). Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Acked-by: Luben Tuikov <luben.tuikov@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613080816.4965-1-christian.koenig@amd.com Fixes: fee2ede15542 ("drm/ttm: rework bulk move handling v5")
2022-06-14ata: libata-core: get rid of *else* branches in ata_id_n_sectors()Sergey Shtylyov1-11/+9
Using *else* after *return* doesn't make much sense -- getting rid of such *else* branches reduces the indentation levels and thus reduces # of LoC... Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-06-14spi: microchip-core: fix potentially incorrect return from probeConor Dooley1-1/+1
If platform_get_irqi() returns 0, the error case will be triggered but probe() will return 0 rather than an error. Ape the other drivers using this pattern and return -ENXIO. Reported-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/linux-spi/20220609055533.95866-2-yang.lee@linux.alibaba.com/ Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Link: https://lore.kernel.org/r/20220614065809.1969177-1-conor.dooley@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-14platform/chrome: cros_ec: Always expose last resume resultStephen Boyd1-4/+4
The last resume result exposing logic in cros_ec_sleep_event() incorrectly requires S0ix support, which doesn't work on ARM based systems where S0ix doesn't exist. That's because cros_ec_sleep_event() only reports the last resume result when the EC indicates the last sleep event was an S0ix resume. On ARM systems, the last sleep event is always S3 resume, but the EC can still detect sleep hang events in case some other part of the AP is blocking sleep. Always expose the last resume result if the EC supports it so that this works on all devices regardless of S0ix support. This fixes sleep hang detection on ARM based chromebooks like Trogdor. Cc: Rajat Jain <rajatja@chromium.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220614075726.2729987-1-swboyd@chromium.org
2022-06-14platform/chrome: cros_ec_proto: Fix spelling mistake "unknwon" -> "unknown"Colin Ian King1-1/+1
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220614064909.47804-1-colin.i.king@gmail.com
2022-06-13amd-xgbe: Use platform_irq_count()Jean-Philippe Brucker1-2/+2
The AMD XGbE driver currently counts the number of interrupts assigned to the device by inspecting the pdev->resource array. Since commit a1a2b7125e10 ("of/platform: Drop static setup of IRQ resource from DT core") removed IRQs from this array, the driver now attempts to get all interrupts from 1 to -1U and gives up probing once it reaches an invalid interrupt index. Obtain the number of IRQs with platform_irq_count() instead. Fixes: a1a2b7125e10 ("of/platform: Drop static setup of IRQ resource from DT core") Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20220609161457.69614-1-jean-philippe@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-13net: phy: fixed_phy: set phy_mask before calling mdiobus_register()Rasmus Villemoes1-0/+1
There's no point probing for phys on this artificial bus, so we can save a little bit of boot time by telling mdiobus_register() not to do that. This doesn't have any functional change, since, at this point, fixed_mdio_read() returns 0xffff for all addresses/registers, so mdiobus_scan() -> get_phy_device() -> get_phy_c22_id() will return -ENODEV, which is just ignored. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20220606200208.1665417-1-linux@rasmusvillemoes.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-14soc: imx: imx8m-blk-ctrl: fix display clock for LCDIF2 power domainAlexander Stein1-1/+1
LCDIF2 has its own display clock, use this one. Fixes: 07614fed00e9 ("soc: imx: imx8m-blk-ctrl: Add i.MX8MP media blk-ctrl") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Martyn Welch <martyn.welch@collabora.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2022-06-13scsi: iscsi: Exclude zero from the endpoint ID rangeSergey Gorenko1-1/+6
The kernel returns an endpoint ID as r.ep_connect_ret.handle in the iscsi_uevent. The iscsid validates a received endpoint ID and treats zero as an error. The commit referenced in the fixes line changed the endpoint ID range, and zero is always assigned to the first endpoint ID. So, the first attempt to create a new iSER connection always fails. Link: https://lore.kernel.org/r/20220613123854.55073-1-sergeygo@nvidia.com Fixes: 3c6ae371b8a1 ("scsi: iscsi: Release endpoint ID when its freed") Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Sergey Gorenko <sergeygo@nvidia.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-06-13scsi: ufs: ufs-renesas: Add support for Renesas R-Car UFS controllerYoshihiro Shimoda3-0/+425
Add support for Renesas R-Car UFS controller which needs vendor-specific initialization. Link: https://lore.kernel.org/r/20220603110524.1997825-5-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-06-13scsi: ufs: core: Add UFSHCD_QUIRK_HIBERN_FASTAUTOYoshihiro Shimoda1-2/+7
Add UFSHCD_QUIRK_HIBERN_FASTAUTO quirk for host controllers which supports auto-hibernate the capability but only FASTAUTO mode. Link: https://lore.kernel.org/r/20220603110524.1997825-4-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-06-13scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESSYoshihiro Shimoda1-0/+2
Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not support 64-bit addressing. Link: https://lore.kernel.org/r/20220603110524.1997825-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-06-13scsi: ufs: host: ufs-exynos: Add support for FSD UFS HCIAlim Akhtar2-0/+141
Adds support of UFS HCI which is found in Tesla Full Self-Driving (FSD) SoC. Link: https://lore.kernel.org/r/20220610104119.66401-7-alim.akhtar@samsung.com Co-developed-by: Bharat Uppal <bharat.uppal@samsung.com> Signed-off-by: Bharat Uppal <bharat.uppal@samsung.com> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-06-13scsi: ufs: host: ufs-exynos: Add mphy apb clock maskAlim Akhtar1-1/+2
Bit[3] of HCI_CLKSTOP_CTRL register is for enabling/disabling MPHY APB clock. Lets add it to CLK_STOP_MASK, so that the same can be controlled during clock masking/unmasking. Link: https://lore.kernel.org/r/20220610104119.66401-6-alim.akhtar@samsung.com Tested-by: Chanho Park <chanho61.park@samsung.com> Reviewed-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-06-13PCI: aardvark: Fix reporting Slot capabilities on emulated bridgePali Rohár1-9/+24
Slot capabilities are currently not reported because emulated bridge does not report the PCI_EXP_FLAGS_SLOT flag. Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers are supported. Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read function to static buffer as it is only statically filled the PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this register. Set Presence State Bit to 1 since there is no support for unplugging the card and there is currently no platform able to detect presence of a card - in such a case the bit needs to be set to 1. Finally correctly set Physical Slot Number to 1 since there is only one port and zero value is reserved for ports within the same silicon as Root Port which is not our case for Aardvark HW. Link: https://lore.kernel.org/r/20220524132827.8837-3-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-06-13PCI: aardvark: Add support for AER registers on emulated bridgePali Rohár1-0/+79
Aardvark controller supports Advanced Error Reporting configuration registers. Export these registers on the emulated root bridge via new .read_ext() and .write_ext() methods. Note that in the Advanced Error Reporting Capability header the offset to the next Extended Capability header is set, but it is not documented in Armada 3700 Functional Specification. Since this change adds support only for Advanced Error Reporting, explicitly clear PCI_EXT_CAP_NEXT bits in AER capability header. Now the pcieport driver correctly detects AER support and allows PCIe AER driver to start receiving ERR interrupts. Kernel log now says: pcieport 0000:00:00.0: AER: enabled with IRQ 52 Link: https://lore.kernel.org/r/20220524132827.8837-2-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2022-06-13drm/msm: Switch ordering of runpm put vs devfreq_idleRob Clark1-1/+2
In msm_devfreq_suspend() we cancel idle_work synchronously so that it doesn't run after we power of the hw or in the resume path. But this means that we want to ensure that idle_work is not scheduled *after* we no longer hold a runpm ref. So switch the ordering of pm_runtime_put() vs msm_devfreq_idle(). v2. Only move the runpm _put_autosuspend, and not the _mark_last_busy() Fixes: 9bc95570175a ("drm/msm: Devfreq tuning") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20210927152928.831245-1-robdclark@gmail.com Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220608161334.2140611-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-06-13net/mlx5: Remove not used MLX5_CAP_BITS_RW_MASKShay Drory1-7/+0
Remove not used MLX5_CAP_BITS_RW_MASK. While at it, remove CAP_MASK, MLX5_CAP_OFF_CMDIF_CSUM and MLX5_DEV_CAP_FLAG_*, since MLX5_CAP_BITS_RW_MASK was their only user. Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-06-13net/mlx5: group fdb cleanup to single functionShay Drory1-8/+10
Currently, the allocation of fdb software objects are done is single function, oppose to the cleanup of them. Group the cleanup of fdb software objects to single function. Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-06-13net/mlx5: Add support EXECUTE_ASO action for flow entryJianbo Liu1-0/+33
Attach flow meter to FTE with object id and index. Use metadata register C5 to store the packet color meter result. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-06-13RDMA/mlx5: Support handling of modify-header pattern ICM areaYevgeny Kliteynik2-18/+36
Add support for allocate/deallocate and registering MR of the new type of ICM area. Support exists only for devices that support sw_owner_v2. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-06-13net/mlx5: Manage ICM of type modify-header patternYevgeny Kliteynik1-0/+42
Added support for managing new type of ICM for devices that support sw_owner_v2. Signed-off-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-06-13nvme-pci: disable write zeros support on UMIC and Samsung SSDsrasheed.hsueh1-0/+8
Like commit 5611ec2b9814 ("nvme-pci: prevent SK hynix PC400 from using Write Zeroes command"), UMIS and Samsung has the same issue: [ 6305.633887] blk_update_request: operation not supported error, dev nvme0n1, sector 340812032 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 So also disable Write Zeroes command on UMIS and Samsung. Signed-off-by: rasheed.hsueh <rasheed.hsueh@lcfc.corp-partner.google.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme-pci: avoid the deepest sleep state on ZHITAI TiPro7000 SSDsNing Wang1-0/+2
When ZHITAI TiPro7000 SSDs entered deepest power state(ps4) it has the same APST sleep problem as Kingston A2000. by chance the system crashes and displays the same dmesg info: https://bugzilla.kernel.org/show_bug.cgi?id=195039#c65 As the Archlinux wiki suggest (enlat + exlat) < 25000 is fine and my testing shows no system crashes ever since. Therefore disabling the deepest power state will fix the APST sleep issue. https://wiki.archlinux.org/title/Solid_state_drive/NVMe This is the APST data from 'nvme id-ctrl /dev/nvme1' NVME Identify Controller: vid : 0x1e49 ssvid : 0x1e49 sn : [...] mn : ZHITAI TiPro7000 1TB fr : ZTA32F3Y [...] ps 0 : mp:3.50W operational enlat:5 exlat:5 rrt:0 rrl:0 rwt:0 rwl:0 idle_power:- active_power:- ps 1 : mp:3.30W operational enlat:50 exlat:100 rrt:1 rrl:1 rwt:1 rwl:1 idle_power:- active_power:- ps 2 : mp:2.80W operational enlat:50 exlat:200 rrt:2 rrl:2 rwt:2 rwl:2 idle_power:- active_power:- ps 3 : mp:0.1500W non-operational enlat:500 exlat:5000 rrt:3 rrl:3 rwt:3 rwl:3 idle_power:- active_power:- ps 4 : mp:0.0200W non-operational enlat:2000 exlat:60000 rrt:4 rrl:4 rwt:4 rwl:4 idle_power:- active_power:- Signed-off-by: Ning Wang <ningwang35@outlook.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme-pci: sk hynix p31 has bogus namespace idsKeith Busch1-0/+2
Add the quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216049 Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme-pci: smi has bogus namespace idsKeith Busch1-1/+2
Add the quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216096 Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme-pci: phison e12 has bogus namespace idsKeith Busch1-0/+2
Add the quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216049 Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme-pci: add NVME_QUIRK_BOGUS_NID for ADATA XPG GAMMIX S50Stefan Reiter1-0/+2
ADATA XPG GAMMIX S50 drives report bogus eui64 values that appear to be the same across drives in one system. Quirk them out so they are not marked as "non globally unique" duplicates. Signed-off-by: Stefan Reiter <stefan@pimaker.at> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme-pci: add trouble shooting steps for timeoutsKeith Busch1-0/+8
Many users have encountered IO timeouts with a CSTS value of 0xffffffff, which indicates a failure to read the register. While there are various potential causes for this observation, faulty NVMe APST has been the culprit quite frequently. Add the recommended troubleshooting steps in the error output when this condition occurs. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme: add bug report info for global duplicate idKeith Busch3-0/+45
The recent global id check is finding poorly implemented devices in the wild. Include relavant device information in the output to help quicken an appropriate quirk patch. Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13nvme: add device name to warning in uuid_show()Thomas Weißschuh1-2/+2
This provides more context to users. Old message: [ 00.000000] No UUID available providing old NGUID New message: [ 00.000000] block nvme0n1: No UUID available providing old NGUID Fixes: d934f9848a77 ("nvme: provide UUID value to userspace") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-06-13spi: tegra quad: Add Tegra Grace featuresMark Brown1-2/+31
Merge series from Krishna Yarlagadda <kyarlagadda@nvidia.com>: Add multiple chip select lines supported on Tegra 241
2022-06-13Revert "fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled"Javier Martinez Canillas1-1/+1
This reverts commit fa0e256450f27a7d85f65c63f05e6897954a1d53. The kernel test robot reported that attempting to build the vesafb driver fails on some architectures, because these don't define a `struct screen_info`. This leads to linking errors, for example on parisc with allyesconfig: hppa-linux-ld: drivers/video/fbdev/vesafb.o: in function `vesafb_probe': >> (.text+0x738): undefined reference to `screen_info' >> hppa-linux-ld: (.text+0x73c): undefined reference to `screen_info' hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': >> (.init.text+0x28): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x30): undefined reference to `screen_info' hppa-linux-ld: (.init.text+0x78): undefined reference to `screen_info' The goal of commit fa0e256450f2 ("fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled") was to have more build coverage for the driver but it wrongly assumed that all architectures would define a screen_info. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220610085450.1341880-1-javierm@redhat.com
2022-06-13can: netlink: allow configuring of fixed data bit rates without need for do_set_data_bittiming callbackMarc Kleine-Budde1-1/+2
This patch is similar to 7e193a42c37c ("can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback") but for data bit rates instead of bit rates. Usually CAN devices support configurable data bit rates. The limits are defined by struct can_priv::data_bittiming_const. Another way is to implement the struct can_priv::do_set_data_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::data_bittiming_const or struct can_priv::do_set_data_bittiming is implemented. In commit 431af779256c ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::data_bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_data_bittiming callback on devices with fixed data bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/20220613143633.4151884-1-mkl@pengutronix.de Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates") Acked-by: Max Staudt <max@enpas.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-06-13gpio: realtek-otto: Make the irqchip immutableSander Vanheule1-2/+8
Since commit 6c846d026d49 ("gpio: Don't fiddle with irqchips marked as immutable") a warning is issued for the realtek-otto driver: gpio gpiochip0: (18003500.gpio): not an immutable chip, please consider fixing it! Make the driver's irqchip immutable to fix this. Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-06-13platform/surface: aggregator_registry: Add support for keyboard cover on Surface Pro 8Maximilian Luz1-1/+36
Add support for the detachable keyboard cover on the Surface Pro 8. The keyboard cover on the Surface Pro 8 is, unlike the keyboard covers of earlier Surface Pro generations, handled via the Surface System Aggregator Module (SSAM). The keyboard and touchpad (as well as other HID input devices) of this cover are standard SSAM HID client devices (just like keyboard and touchpad on e.g. the Surface Laptop 3 and 4), however, some care needs to be taken as they can be physically detached (similarly to the Surface Book 3). Specifically, the respective SSAM client devices need to be removed when the keyboard cover has been detached and (re-)initialized when the keyboard cover has been (re-)attached. On the Surface Pro 8, detachment of the keyboard cover (and by extension its devices) is managed via the KIP subsystem. Therefore, said devices need to be registered under the KIP device hub, which in turn will remove and re-create/re-initialize those devices as needed. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-13-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13platform/surface: aggregator_registry: Add KIP device hubMaximilian Luz1-2/+101
Add a Surface System Aggregator Module (SSAM) client device hub for hot-removable devices managed via the KIP subsystem. The KIP subsystem (full name unknown, abbreviation has been obtained through reverse engineering) is a subsystem that manages hot-removable SSAM client devices. Specifically, it manages HID input devices contained in the detachable keyboard cover of the Surface Pro 8 and Surface Pro X. The KIP subsystem handles a single group of devices (e.g. all devices contained in the keyboard cover) and cannot handle devices individually. Thus we model it as a client device hub, which (hot-)removes all devices contained under it once removal of the hub (e.g. keyboard cover) has been detected and (re-)adds all devices once the physical hub device has been (re-)attached. To do this, use the previously generified SSAM subsystem hub framework. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-12-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13platform/surface: aggregator_registry: Change device ID for base hubMaximilian Luz1-2/+2
Use the target category of the (base) hub as instance id in the (virtual) hub device UID. This makes association of the hub with the respective subsystem easier. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-11-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13platform/surface: aggregator_registry: Generify subsystem hub functionalityMaximilian Luz1-116/+153
The Surface System Aggregator Module (SSAM) has multiple subsystems that can manage detachable devices. At the moment, we only support the "base" (BAS/0x11) subsystem, which is used on the Surface Book 3 to manage devices (including keyboard, touchpad, and secondary battery) connected to the base of the device. The Surface Pro 8 has a new type-cover with keyboard and touchpad, which is managed via the KIP/0x0e subsystem. The general procedure is the same, but with slightly different events and setup. To make implementation of the KIP hub easier and prevent duplication, generify the parts of the base hub that we can use for the KIP hub (or any potential future subsystem hubs). This also switches over to use the newly introduced "hot-remove" functionality, which should prevent communication issues when devices have been detached. Lastly, also drop the undocumented and unused sysfs "state" attribute of the base hub. It has at best been useful for debugging. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-10-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13HID: surface-hid: Add support for hot-removalMaximilian Luz1-1/+37
Add support for hot-removal of SSAM HID client devices. Once a device has been hot-removed, further communication with it should be avoided as it may fail and time out. While the device will be removed as soon as we detect hot-removal, communication may still occur during teardown, especially when unregistering notifiers. While hot-removal is a surprise event that can happen at any time, try to avoid communication as much as possible once it has been detected to prevent timeouts that can slow down device removal and cause issues, e.g. when quickly re-attaching the device. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-8-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13power/supply: surface_battery: Use client device wrappers for notifier registrationMaximilian Luz1-2/+2
Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20220527023447.2460025-7-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13power/supply: surface_charger: Use client device wrappers for notifier registrationMaximilian Luz1-2/+2
Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20220527023447.2460025-6-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13platform/surface: aggregator_registry: Use client device wrappers for notifier registrationMaximilian Luz1-3/+3
Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-5-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13platform/surface: aggregator: Allow notifiers to avoid communication on unregisteringMaximilian Luz1-18/+35
When SSAM client devices have been (physically) hot-removed, communication attempts with those devices may fail and time out. This can even extend to event notifiers, due to which timeouts may occur during device removal, slowing down that process. Add a parameter to the notifier unregister function that allows skipping communication with the EC to prevent this. Furthermore, add wrappers for registering and unregistering notifiers belonging to SSAM client devices that automatically check if the device has been marked as hot-removed and communication should be avoided. Note that non-SSAM client devices can generally not be hot-removed, so also add a convenience wrapper for those, defaulting to allow communication. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220527023447.2460025-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-13drm/msm: Fix convert to drm_of_get_data_lanes_countMarek Vasut2-2/+4
Add missing header file into dsi_host.c and encode data-lanes string directly into the warning message in the driver to avoid build issues detected by lkp. Fixes: 185443efa26a ("drm/msm: Convert to drm_of_get_data_lanes_count") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Rob Clark <robdclark@gmail.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sean Paul <sean@poorly.run> To: dri-devel@lists.freedesktop.org Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220612143349.105766-1-marex@denx.de
2022-06-13spi: s3c64xx: set pointers to null using NULL rather than 0Colin Ian King1-5/+5
There are pointers being set to null using use. Use NULL instead. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20220612203428.2754823-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-13spi: micro: fix unreasonable clk_prepare_enable() on error in mchp_corespi_probe()Peng Wu1-1/+1
Fix the unreasonable clk_prepare_enable() with clk_disable_unprepare() before return from mchp_corespi_probe() in the error handling case. Signed-off-by: Peng Wu <wupeng58@huawei.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20220611021117.40494-1-wupeng58@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-13i2c: designware: Use standard optional ref clock implementationSerge Semin2-5/+11
Even though the DW I2C controller reference clock source is requested by the method devm_clk_get() with non-optional clock requirement the way the clock handler is used afterwards has a pure optional clock semantic (though in some circumstances we can get a warning about the clock missing printed in the system console). There is no point in reimplementing that functionality seeing the kernel clock framework already supports the optional interface from scratch. Thus let's convert the platform driver to using it. Note by providing this commit we get to fix two problems. The first one was introduced in commit c62ebb3d5f0d ("i2c: designware: Add support for an interface clock"). It causes not having the interface clock (pclk) enabled/disabled in case if the reference clock isn't provided. The second problem was first introduced in commit b33af11de236 ("i2c: designware: Do not require clock when SSCN and FFCN are provided"). Since that modification the deferred probe procedure has been unsupported in case if the interface clock isn't ready. Fixes: c62ebb3d5f0d ("i2c: designware: Add support for an interface clock") Fixes: b33af11de236 ("i2c: designware: Do not require clock when SSCN and FFCN are provided") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-06-13ASoC: hdmi-codec: Update to modern DAI terminologyMark Brown5-14/+15
As part of retiring the old defines used to specify DAI formats update the hdmi_codec driver to use the modern names, including the variables in the struct hdmi_codec_daifmt exported to the DRM drivers. In updating this I did note that the only use of this information in DRM drivers is to reject clock provider settings, thinking about what this hardware is doing I rather suspect that there might not be any hardware out there which needs the configuration so it may be worth considering just having hdmi-codec support only clock consumer. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220602103029.3498791-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>