summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-11-13net: stmmac: Introduce dwmac1000 ptp_clock_info and operationsMaxime Chevallier
The PTP configuration for GMAC3_X differs from the other implementations in several ways : - There's only one external snapshot trigger - The snapshot configuration is done through the PTP_TCR register, whereas the other dwmac variants have a dedicated ACR (auxiliary control reg) for that purpose - The layout for the PTP_TCR register also differs, as bits 24/25 are used for the snapshot configuration. These bits are reserved on other variants. On GMAC3_X, we also can't discover the number of snapshot triggers automatically. The GMAC3_X has one PPS output, however it's configuration isn't supported yet so report 0 n_per_out for now. Introduce a dedicated set of ptp_clock_info ops and configuration parameters to reflect these differences specific to GMAC3_X. This was tested on dwmac_socfpga. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20241112170658.2388529-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-13net: stmmac: Only update the auto-discovered PTP clock featuresMaxime Chevallier
Some DWMAC variants such as dwmac1000 don't support discovering the number of output pps and auxiliary snapshots. Allow these parameters to be defined in default ptp_clock_info, and let them be updated only when the feature discovery yielded a result. Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20241112170658.2388529-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-13net: stmmac: Use per-hw ptp clock opsMaxime Chevallier
The auxiliary snapshot configuration was found to differ depending on the dwmac version. To prepare supporting this, allow specifying the ptp_clock_info ops in the hwif array Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20241112170658.2388529-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-13net: stmmac: Don't modify the global ptp ops directlyMaxime Chevallier
The stmmac_ptp_clock_ops are copied into the stmmac_priv structure before being registered to the PTP core. Some adjustments are made prior to that, such as the number of snapshots or max adjustment parameters. Instead of modifying the global definition, then copying into the local private data, let's first copy then modify the local parameters. Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20241112170658.2388529-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-13net: phy: c45: don't use temporary linkmode bitmaps in ↵Heiner Kallweit
genphy_c45_ethtool_get_eee genphy_c45_eee_is_active() populates both bitmaps only if it returns successfully. So we can avoid the overhead of the temporary bitmaps. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/b0832102-28ab-4223-b879-91fb1fc11278@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-13Merge tag 'wireless-next-2024-11-13' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.13 Most likely the last -next pull request for v6.13. Most changes are in Realtek and Qualcomm drivers, otherwise not really anything noteworthy. Major changes: mac80211 * EHT 1024 aggregation size for transmissions ath12k * switch to using wiphy_lock() and remove ar->conf_mutex * firmware coredump collection support * add debugfs support for a multitude of statistics ath11k * dt: document WCN6855 hardware inputs ath9k * remove include/linux/ath9k_platform.h ath5k * Arcadyan ARV45XX AR2417 & Gigaset SX76[23] AR241[34]A support rtw88: * 8821au and 8812au USB adapters support rtw89 * thermal protection * firmware secure boot for WiFi 6 chip * tag 'wireless-next-2024-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (154 commits) Revert "wifi: iwlegacy: do not skip frames with bad FCS" wifi: mac80211: pass MBSSID config by reference wifi: mac80211: Support EHT 1024 aggregation size in TX net: rfkill: gpio: Add check for clk_enable() wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() wifi: Switch back to struct platform_driver::remove() wifi: ipw2x00: libipw_rx_any(): fix bad alignment wifi: brcmfmac: release 'root' node in all execution paths wifi: iwlwifi: mvm: don't call power_update_mac in fast suspend wifi: iwlwifi: s/IWL_MVM_INVALID_STA/IWL_INVALID_STA wifi: iwlwifi: bump minimum API version in BZ/SC to 92 wifi: iwlwifi: move IWL_LMAC_*_INDEX to fw/api/context.h wifi: iwlwifi: be less noisy if the NIC is dead in S3 wifi: iwlwifi: mvm: tell iwlmei when we finished suspending wifi: iwlwifi: allow fast resume on ax200 wifi: iwlwifi: mvm: support new initiator and responder command version wifi: iwlwifi: mvm: use wiphy locked debugfs for low-latency wifi: iwlwifi: mvm: MLO scan upon channel condition degradation wifi: iwlwifi: mvm: support new versions of the wowlan APIs wifi: iwlwifi: mvm: allow always calling iwl_mvm_get_bss_vif() ... ==================== Link: https://patch.msgid.link/20241113172918.A8A11C4CEC3@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-14nouveau/dp: handle retries for AUX CH transfers with GSP.Dave Airlie
eb284f4b3781 drm/nouveau/dp: Honor GSP link training retry timeouts tried to fix a problem with panel retires, however it appears the auxch also needs the same treatment, so add the same retry wrapper around it. This fixes some eDP panels after a suspend/resume cycle. Fixes: eb284f4b3781 ("drm/nouveau/dp: Honor GSP link training retry timeouts") Cc: stable@vger.kernel.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241111034126.2028401-2-airlied@gmail.com
2024-11-14nouveau: handle EBUSY and EAGAIN for GSP aux errors.Dave Airlie
The upper layer transfer functions expect EBUSY as a return for when retries should be done. Fix the AUX error translation, but also check for both errors in a few places. Fixes: eb284f4b3781 ("drm/nouveau/dp: Honor GSP link training retry timeouts") Cc: stable@vger.kernel.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241111034126.2028401-1-airlied@gmail.com
2024-11-14nouveau: fw: sync dma after setup is called.Dave Airlie
When this code moved to non-coherent allocator the sync was put too early for some firmwares which called the setup function, move the sync down after the setup function. Reported-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Tested-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Reviewed-by: Lyude Paul <lyude@redhat.com> Fixes: 9b340aeb26d5 ("nouveau/firmware: use dma non-coherent allocator") Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241114004603.3095485-1-airlied@gmail.com
2024-11-13PCI: hotplug: Add OCTEON PCI hotplug controller driverShijith Thotton
Add a PCI hotplug controller driver for the OCTEON PCIe device. The OCTEON PCIe device is a multi-function device where function 0 serves as the PCI hotplug controller. There is an out-of-band management console interface to firmware running on function 0 whereby an administrator can disable functions to save power or enable them with one of several personalities (virtio-net, virtio-crypto, NVMe, etc) for the other functions. Function 0 initiates hotplug events handled by this driver when the other functions are enabled or disabled. +--------------------------------+ | Root Port | +--------------------------------+ | PCIe | +---------------------------------------------------------------+ | OCTEON PCIe Multifunction Device | +---------------------------------------------------------------+ | | | | | | | | +---------------------+ +----------------+ +-----+ +----------------+ | Function 0 | | Function 1 | | ... | | Function 7 | | (Hotplug controller)| | (Hotplug slot) | | | | (Hotplug slot) | +---------------------+ +----------------+ +-----+ +----------------+ | | +-------------------------+ | Controller Firmware | +-------------------------+ The hotplug controller driver enables hotplugging of non-controller functions within the same device. During probing, the driver removes the non-controller functions and registers them as PCI hotplug slots. These slots are added back by the driver, only upon request from the device firmware. The controller uses MSI-X interrupts to notify the host of hotplug events initiated by the OCTEON firmware. Additionally, the driver allows users to enable or disable individual functions via sysfs slot entries, as provided by the PCI hotplug framework. Link: https://lore.kernel.org/r/20241111134523.2796699-1-sthotton@marvell.com Co-developed-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Shijith Thotton <sthotton@marvell.com> [bhelgaas: use pci_info() when possible] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-11-13vfio/virtio: Enable live migration once VIRTIO_PCI was configuredYishai Hadas
Now that the driver supports live migration, only the legacy IO functionality depends on config VIRTIO_PCI_ADMIN_LEGACY. As part of that we introduce a bool configuration option as a sub menu under the driver's main live migration feature named VIRTIO_VFIO_PCI_ADMIN_LEGACY, to control the legacy IO functionality. This will let users configuring the kernel, know which features from the description might be available in the resulting driver. As of that, move the legacy IO into a separate file to be compiled only once CONFIG_VIRTIO_VFIO_PCI_ADMIN_LEGACY was configured and let the live migration depends only on VIRTIO_PCI. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20241113115200.209269-8-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13vfio/virtio: Add PRE_COPY support for live migrationYishai Hadas
Add PRE_COPY support for live migration. This functionality may reduce the downtime upon STOP_COPY as of letting the target machine to get some 'initial data' from the source once the machine is still in its RUNNING state and let it prepares itself pre-ahead to get the final STOP_COPY data. As the Virtio specification does not support reading partial or incremental device contexts. This means that during the PRE_COPY state, the vfio-virtio driver reads the full device state. As the device state can be changed and the benefit is highest when the pre copy data closely matches the final data we read it in a rate limiter mode. This means we avoid reading new data from the device for a specified time interval after the last read. With PRE_COPY enabled, we observed a downtime reduction of approximately 70-75% in various scenarios compared to when PRE_COPY was disabled, while keeping the total migration time nearly the same. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20241113115200.209269-7-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13vfio/virtio: Add support for the basic live migration functionalityYishai Hadas
Add support for basic live migration functionality in VFIO over virtio-net devices, aligned with the virtio device specification 1.4. This includes the following VFIO features: VFIO_MIGRATION_STOP_COPY, VFIO_MIGRATION_P2P. The implementation registers with the VFIO subsystem using vfio_pci_core and then incorporates the virtio-specific logic for the migration process. The migration follows the definitions in uapi/vfio.h and leverages the virtio VF-to-PF admin queue command channel for execution device parts related commands. Additional Notes: ----------------- The kernel protocol between the source and target devices contains a header with metadata, including record size, tag, and flags. The record size allows the target to recognize and read a complete image from the source before passing the device part data. This adheres to the virtio device specification, which mandates that partial device parts cannot be supplied. The tag and flags serve as placeholders for future extensions of the kernel protocol between the source and target, ensuring backward and forward compatibility. Both the source and target comply with the virtio device specification by using a device part object with a unique ID as part of the migration process. Since this resource is limited to a maximum of 255, its lifecycle is confined to periods with an active live migration flow. According to the virtio specification, a device has only two modes: RUNNING and STOPPED. As a result, certain VFIO transitions (i.e., RUNNING_P2P->STOP, STOP->RUNNING_P2P) are treated as no-ops. When transitioning to RUNNING_P2P, the device state is set to STOP, and it will remain STOPPED until the transition out of RUNNING_P2P->RUNNING, at which point it returns to RUNNING. During transition to STOP, the virtio device only stops initiating outgoing requests(e.g. DMA, MSIx, etc.) but still must accept incoming operations. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20241113115200.209269-6-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13PCI: Warn if a running device is unaware of resetKeith Busch
If a reset is issued to a running device with a driver that didn't register the notification callbacks, the driver may be unaware of this event and have an inconsistent view of the device's state. Log a warning of this event because there's nothing else indicating the event occured, which could be confusing when debugging such situations. Link: https://lore.kernel.org/r/20241025222755.3756162-2-kbusch@meta.com Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Amey Narkhede <ameynarkhede03@gmail.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13PCI: Add 'reset_subordinate' to reset hierarchy below bridgeKeith Busch
The "bus" and "cxl_bus" reset methods reset a device by asserting Secondary Bus Reset on the bridge leading to the device. These only work if the device is the only device below the bridge. Add a sysfs 'reset_subordinate' attribute on bridges that can assert Secondary Bus Reset regardless of how many devices are below the bridge. This resets all the devices below a bridge in a single command, including the locking and config space save/restore that reset methods normally do. This may be the only way to reset devices that don't support other reset methods (ACPI, FLR, PM reset, etc). Link: https://lore.kernel.org/r/20241025222755.3756162-1-kbusch@meta.com Signed-off-by: Keith Busch <kbusch@kernel.org> [bhelgaas: commit log, add capable(CAP_SYS_ADMIN) check] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Amey Narkhede <ameynarkhede03@gmail.com>
2024-11-13i2c: designware: Fix spelling and other issues in the commentsAndy Shevchenko
Fix spelling and other issues, such as kernel-doc reported about, in the comments. While at it, fix some indentation issues as well. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: designware: Use sda_hold_time variable name everywhereAndy Shevchenko
Currently the PCI glue driver uses sda_hold variable name, while the rest of the driver use sda_hold_time. This makes things harder to grep. Use sda_hold_time variable name everywhere. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: designware: Remove 'cond' from i2c_dw_scl_hcnt()Andy Shevchenko
The 'cond' parameter is not being used (always default, hence drop it and hence make it consistent with i2c_dw_scl_lcnt(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: designware: Get rid of redundant 'else'Andy Shevchenko
In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: designware: Use temporary variable for struct deviceAndy Shevchenko
Use temporary variable for struct device to make code neater. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: amd-asf: Clear remote IRR bit to get successive interruptShyam Sundar S K
To ensure successive interrupts upon packet reception, it is necessary to clear the remote IRR bit by writing the interrupt number to the EOI register. The base address for this operation is provided by the BIOS and retrieved by the driver by traversing the ASF object's namespace. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: amd-asf: Add routine to handle the ASF slave processShyam Sundar S K
Add support for handling ASF slave process events as described in the AMD ASF databook. This involves implementing the correct programming sequence to manage each ASF packet appropriately. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: amd-asf: Add i2c_algorithm operations to support AMD ASF with SMBusShyam Sundar S K
Implement the i2c_algorithm operations to enable support for AMD ASF (Alert Standard Format) with SMBus. This enhancement includes: - Adding functionality to identify and select the supported ASF functions. - Implementing mechanisms for registering and deregistering I2C slave devices. - Providing support for data transfer operations over ASF. Additionally, include a 'select' Kconfig entry as the current patch utilizes .reg_slave() and .unreg_slave() callbacks, which are controlled by CONFIG_I2C_SLAVE. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: amd-asf: Add ACPI support for AMD ASF ControllerShyam Sundar S K
The AMD ASF controller is presented to the operating system as an ACPI device. The AMD ASF driver can use ACPI to obtain information about the ASF controller's attributes, such as the ASF address space and interrupt number, and to handle ASF interrupts. Currently, the piix4 driver assumes that a specific port address is designated for AUX operations. However, with the introduction of ASF, the same port address may also be used by the ASF controller. Therefore, a check needs to be added to ensure that if ASF is advertised and enabled in ACPI, the AUX port should not be configured. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: piix4: Export i2c_piix4 driver functions as libraryShyam Sundar S K
Export the following i2c_piix4 driver functions as a library so that the AMD ASF driver can utilize these core functionalities from the i2c_piix4 driver: - piix4_sb800_region_request(): Request access to a specific SMBus region on the SB800 chipset. - piix4_sb800_region_release(): Release the previously requested SMBus region on the SB800 chipset. - piix4_transaction(): Handle SMBus transactions between the SMBus controller and connected devices. - piix4_sb800_port_sel(): Select the appropriate SMBus port on the SB800 chipset. By making these functions available as a library, enable the AMD ASF driver to leverage the established mechanisms in the i2c_piix4 driver, promoting code reuse and consistency across different drivers. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: piix4: Move i2c_piix4 macros and structures to common headerShyam Sundar S K
Add a separate header file to relocate the common code from the i2c_piix4 driver, allowing the AMD ASF driver to utilize the same code. Update the MAINTAINERS file to include information about the new common header file. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: piix4: Change the parameter list of piix4_transaction functionShyam Sundar S K
Currently, `piix4_transaction()` accepts only one parameter, which is the `i2c_adapter` information. This approach works well as long as SB800 SMBus port accesses are confined to the piix4 driver. However, with the implementation of a separate ASF driver and the varying address spaces across drivers, it is necessary to change the function parameter list of `piix4_transaction()` to include the port address. This modification allows other drivers that use piix4 to pass the specific port details they need to operate on. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: i801: Add support for Intel Panther LakeJarkko Nikula
Add SMBus PCI IDs on Intel Panther Lake-P and -U. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Convert to kernel-docAndy Shevchenko
Convert existing descriptions to kernel-doc format and unify the rest of the comments to follow the modern style. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Prefer to use octal permissionAndy Shevchenko
Octal permissions are preferred over the symbolics ones for readbility. This ceases warning message pointed by checkpatch. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Unify the name of the variable to hold an error codeAndy Shevchenko
There are two different names used for the variable that holds an error code. Unify to use one variant in all cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Use read_poll_timeout()Andy Shevchenko
Simplify the code by using read_poll_timeout(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Utilize temporary variable to hold device pointerAndy Shevchenko
Introduce a temporary variable to hold a device pointer. It can be utilized in the ->probe() and save a bit of LoCs. To make it consistent, rename currently used dev to pdev. While at it, convert the only error message to dev_err_probe(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: switch i2c registration to devm functionsAndy Shevchenko
Switch from i2c_add_adapter() to resource managed devm_i2c_add_adapter() for matching rest of driver initialization, and more concise code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Use custom private data structureAndy Shevchenko
Use custom private data structure instead of global variables. With that, remove not anymore true comment. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Switch to memory mapped IO accessorsAndy Shevchenko
Convert driver to use memory mapped IO accessors. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Use string_choices API instead of ternary operatorAndy Shevchenko
Use modern string_choices API instead of manually determining the output using ternary operator. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: isch: Pass pointer to struct i2c_adapter downAndy Shevchenko
There are a lot of messaging calls that use global variable of struct i2c_adapter. Instead, to make code better and flexible for further improvements, pass the pointer to the actual adapter used for transfers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: cadence: Add atomic transfer support for controller version 1.4Manikanta Guntupalli
Rework the read and write code paths in the driver to support operation in atomic contexts in master mode. This change does not apply to slave mode because there is no way to handle interruptions in that context. Adjust the message timeout to include some extra time. For non-atomic contexts, 500 ms is added to the timeout. For atomic contexts, 2000 ms is added because transfers happen in polled mode, requiring more time to account for the polling overhead. Similar changes have been implemented in other drivers, including: commit 3a5ee18d2a32 ("i2c: imx: implement master_xfer_atomic callback") commit 445094c8a9fb ("i2c: exynos5: add support for atomic transfers") commit ede2299f7101 ("i2c: tegra: Support atomic transfers") commit fe402bd09049 ("i2c: meson: implement the master_xfer_atomic callback") Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: cadence: Split cdns_i2c_master_xfer for Atomic ModeManikanta Guntupalli
The cdns_i2c_master_xfer function has been refactored to separate the common code. This change facilitates better support for atomic mode operations by isolating the shared logic. Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13i2c: cadence: Relocate cdns_i2c_runtime_suspend and cdns_i2c_runtime_resume ↵Manikanta Guntupalli
to facilitate atomic mode Relocate cdns_i2c_runtime_suspend, cdns_i2c_runtime_resume and cdns_i2c_init functions to avoid prototype statement in atomic mode changes. Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-13virtio-pci: Introduce APIs to execute device parts admin commandsYishai Hadas
Introduce APIs to handle the execution of device parts admin commands. These APIs cover functionalities such as mode setting, object creation and destruction, and operations like parts get/set and metadata retrieval. These APIs will be utilized in upcoming patches within this series. Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20241113115200.209269-5-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13virtio: Manage device and driver capabilities via the admin commandsYishai Hadas
Manage device and driver capabilities via the admin commands. The device exposes its supported features and resource object limits via an administrative command called VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY, using the 'self group type.' Each capability is identified by a unique ID, and the driver communicates the functionality and resource limits it plans to utilize. The capability VIRTIO_DEV_PARTS_CAP specifically represents the device's parts resource object limit. Manage the device's parts resource object ID using a common IDA for both get and set operations. Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20241113115200.209269-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13virtio: Extend the admin command to include the result sizeYishai Hadas
Extend the admin command by incorporating a result size field. This allows higher layers to determine the actual result size from the backend when this information is not included in the result_sg. The additional information introduced here will be used in subsequent patches of this series. Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20241113115200.209269-3-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13hisi_acc_vfio_pci: register debugfs for hisilicon migration driverLongfang Liu
On the debugfs framework of VFIO, if the CONFIG_VFIO_DEBUGFS macro is enabled, the debug function is registered for the live migration driver of the HiSilicon accelerator device. After registering the HiSilicon accelerator device on the debugfs framework of live migration of vfio, a directory file "hisi_acc" of debugfs is created, and then three debug function files are created in this directory: vfio | +---<dev_name1> | +---migration | +--state | +--hisi_acc | +--dev_data | +--migf_data | +--cmd_state | +---<dev_name2> +---migration +--state +--hisi_acc +--dev_data +--migf_data +--cmd_state dev_data file: read device data that needs to be migrated from the current device in real time migf_data file: read the migration data of the last live migration from the current driver. cmd_state: used to get the cmd channel state for the device. +----------------+ +--------------+ +---------------+ | migration dev | | src dev | | dst dev | +-------+--------+ +------+-------+ +-------+-------+ | | | | +------v-------+ +-------v-------+ | | saving_migf | | resuming_migf | read | | file | | file | | +------+-------+ +-------+-------+ | | copy | | +------------+----------+ | | +-------v--------+ +-------v--------+ | data buffer | | debug_migf | +-------+--------+ +-------+--------+ | | cat | cat | +-------v--------+ +-------v--------+ | dev_data | | migf_data | +----------------+ +----------------+ When accessing debugfs, user can obtain the most recent status data of the device through the "dev_data" file. It can read recent complete status data of the device. If the current device is being migrated, it will wait for it to complete. The data for the last completed migration function will be stored in debug_migf. Users can read it via "migf_data". Signed-off-by: Longfang Liu <liulongfang@huawei.com> Reviewed-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Link: https://lore.kernel.org/r/20241112073322.54550-4-liulongfang@huawei.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2024-11-13Merge tag 'pm-6.12-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix a locking issue in the asymmetric CPU capacity setup code in the intel_pstate driver that may lead to a deadlock if CPU online/offline runs in parallel with the code in question, which is unlikely but not impossible (Rafael Wysocki)" * tag 'pm-6.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Rearrange locking in hybrid_init_cpu_capacity_scaling()
2024-11-13Merge tag 'tpmdd-next-6.12-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull tpm fixes from Jarkko Sakkinen: "Two bug fixes for TPM bus encryption (the remaining reported issues in the feature)" * tag 'tpmdd-next-6.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm: Disable TPM on tpm2_create_primary() failure tpm: Opt-in in disable PCR integrity protection
2024-11-13PCI: Enable runtime PM of the host bridgeKrishna chaitanya chundru
The controller driver is the parent device of the PCIe host bridge, PCI-PCI bridge and PCIe endpoint as shown below. PCIe controller (Top level parent & parent of host bridge) | v PCIe Host bridge (Parent of PCI-PCI bridge) | v PCI-PCI bridge (Parent of endpoint driver) | v PCIe endpoint driver Now, when the controller device goes to runtime suspend, PM framework will check the runtime PM state of the child device (host bridge) and will find it to be disabled. So it will allow the parent (controller device) to go to runtime suspend. Only if the child device's state was 'active' it will prevent the parent to get suspended. It is a property of the runtime PM framework that it can only follow continuous dependency chains. That is, if there is a device with runtime PM disabled in a dependency chain, runtime PM cannot be enabled for devices below it and above it in that chain both at the same time. Since runtime PM is disabled for host bridge, the state of the child devices under the host bridge is not taken into account by PM framework for the top level parent, PCIe controller. So the PM framework allows the controller driver to enter runtime PM irrespective of the state of the devices under the host bridge. And this causes the topology breakage and also possible PM issues like controller driver going to runtime suspend while the endpoint driver is doing transfers. Because of the above, in order to enable runtime PM for a PCIe controller device, one needs to ensure that runtime PM is enabled for all devices in every dependency chain between it and any PCIe endpoint (as runtime PM is enabled for PCIe endpoints). This means that runtime PM needs to be enabled for the host bridge device, which is present in all of these dependency chains. After this change, the host bridge device will be runtime-suspended by the runtime PM framework automatically after suspending its last child and it will be runtime-resumed automatically before resuming its first child which will allow the runtime PM framework to track dependencies between the host bridge device and all of its descendants. The PM framework expects parent runtime PM to be enabled before enabling runtime PM of the child. Ensure pm_runtime_enable() is called for the controller drivers before calling pci_host_probe(). Link: https://lore.kernel.org/r/20241111-runtime_pm-v7-2-9c164eefcd87@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-11-13PCI: starfive: Enable controller runtime PM before probing host bridgeMayank Rana
A PCI controller device, e.g., StarFive, is parent to PCI host bridge device. We must enable runtime PM of the controller before enabling runtime PM of the host bridge, which will happen in pci_host_probe(), to avoid this warning: pcie-starfive 940000000.pcie: Enabling runtime PM for inactive device with active children Fix this issue by enabling StarFive controller device's runtime PM before calling pci_host_probe() in plda_pcie_host_init(). Link: https://lore.kernel.org/r/20241111-runtime_pm-v7-1-9c164eefcd87@quicinc.com Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>