summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-11-04net: enetc: add i.MX95 EMDIO supportWei Fang
The verdor ID and device ID of i.MX95 EMDIO are different from LS1028A EMDIO, so add new vendor ID and device ID to pci_device_id table to support i.MX95 EMDIO. Signed-off-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-04net: enetc: remove ERR050089 workaround for i.MX95Vladimir Oltean
The ERR050089 workaround causes performance degradation and potential functional issues (e.g., RCU stalls) under certain workloads. Since new SoCs like i.MX95 do not require this workaround, use a static key to compile out enetc_lock_mdio() and enetc_unlock_mdio() at runtime, improving performance and avoiding unnecessary logic. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-04net: enetc: build enetc_pf_common.c as a separate moduleWei Fang
Compile enetc_pf_common.c as a standalone module to allow shared usage between ENETC v1 and v4 PF drivers. Add struct enetc_pf_ops to register different hardware operation interfaces for both ENETC v1 and v4 PF drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-04net: enetc: extract common ENETC PF parts for LS1028A and i.MX95 platformsWei Fang
The ENETC PF driver of LS1028A (rev 1.0) is incompatible with the version used on the i.MX95 platform (rev 4.1), except for the station interface (SI) part. To reduce code redundancy and prepare for a new driver for rev 4.1 and later, extract shared interfaces from enetc_pf.c and move them to enetc_pf_common.c. This refactoring lays the groundwork for compiling enetc_pf_common.c into a shared driver for both platforms' PF drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-04net: enetc: add initial netc-blk-ctrl driver supportWei Fang
The netc-blk-ctrl driver is used to configure Integrated Endpoint Register Block (IERB) and Privileged Register Block (PRB) of NETC. For i.MX platforms, it is also used to configure the NETCMIX block. The IERB contains registers that are used for pre-boot initialization, debug, and non-customer configuration. The PRB controls global reset and global error handling for NETC. The NETCMIX block is mainly used to set MII protocol and PCS protocol of the links, it also contains settings for some other functions. Note the IERB configuration registers can only be written after being unlocked by PRB, otherwise, all write operations are inhibited. A warm reset is performed when the IERB is unlocked, and it results in an FLR to all NETC devices. Therefore, all NETC device drivers must be probed or initialized after the warm reset is finished. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-04platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h modelShyam Sundar S K
Add SMU metrics table support for 1Ah family 60h model. This information will be used by the PMF driver to alter the system thermals. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241023063245.1404420-2-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-11-04drm/imagination: Break an object reference loopBrendan King
When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context. Signed-off-by: Brendan King <brendan.king@imgtec.com> Signed-off-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/8a25924f-1bb7-4d9a-a346-58e871dfb1d1@imgtec.com
2024-11-04drm/imagination: Add a per-file PVR context listBrendan King
This adds a linked list of VM contexts which is needed for the next patch to be able to correctly track VM contexts for destruction on file close. It is only safe for VM contexts to be removed from the list and destroyed when not in interrupt context. Signed-off-by: Brendan King <brendan.king@imgtec.com> Signed-off-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/e57128ea-f0ce-4e93-a9d4-3f033a8b06fa@imgtec.com
2024-11-04drm/i915/display: Allow fastset for change in HDR infoframeChaitanya Kumar Borah
Changes in Dynamic Range and Mastering infoframe should not trigger a full modeset. Therefore, allow fastset. DP SDP programming is already hooked up in the fastset flow but HDMI AVI infoframe update is not, add it. Any other infoframe that can be fastset should be added to the helper intel_hdmi_fastset_infoframes(). v3: - Create a wrapper intel_ddi_update_pipe_hdmi to stick to uniform naming (Jani) - Do not disable HDMI AVI infoframe if already disabled (Uma) v2: - Update HDMI AVI infoframe during fastset. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023044122.3889137-1-chaitanya.kumar.borah@intel.com
2024-11-04drm/i915/psr: WA for panels stating bad link status after PSR is enabledJouni Högander
We are currently seeing unexpected link trainings with several different eDP panels. These are caused by these panels stating bad link status in their dpcd registers. This can be observed by doing following test: 1. Boot up without Xe module loaded 2. Load Xe module with PSR disabled: $ modprobe xe enable_psr=0 3. Read panel link status register $ dpcd_reg read --offset 0x200e --count=1 0x200e: 00 4. Enable PSR, sleep for 2 seconds and disable PSR again: $ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug $ echo "-1" > /sys/kernel/debug/dri/0000:00:02.0/xe_params/enable_psr $ echo 0x0 > /sys/kernel/debug/dri/0/i915_edp_psr_debug $ sleep 2 $ cat /sys/kernel/debug/dri/0/i915_edp_psr_status | grep status $ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug Source PSR/PanelReplay status: DEEP_SLEEP [0x80310030] 5. Now read panel link status registers again: $ dpcd_reg read --offset 0x200e --count=1 0x200e: 80 Workaround this by not trusting link status registers after PSR is enabled until first short pulse interrupt is received. v2: - clear link_ok flag on pipe disable - remove useless comment - modify intel_dp_needs_link_retrain return statement Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029122415.1789528-1-jouni.hogander@intel.com
2024-11-04gpio: altera: Drop legacy-of-mm-gpiochip.h headerAndy Shevchenko
Remove legacy-of-mm-gpiochip.h header file, replace of_* functions and structs with appropriate alternatives. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241031101836.2434308-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: pcie-idio-24: Replace deprecated PCI functionsWilliam Breathitt Gray
pcim_iomap_regions() and pcim_iomap_table() have been deprecated in commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()"). Replace these functions with pcim_iomap_region(). In order to match the rest of the code in idio_24_probe(), utilize dev_err_probe() to handle error for pcim_enable_device(). Signed-off-by: William Breathitt Gray <wbg@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241101-pci_iomap_region_gpio_acces-v1-2-26eb1dc93e45@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: pci-idio-16: Replace deprecated PCI functionsWilliam Breathitt Gray
pcim_iomap_regions() and pcim_iomap_table() have been deprecated in commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()"). Replace these functions with pcim_iomap_region(). In order to match the rest of the code in idio_16_probe(), utilize dev_err_probe() to handle error for pcim_enable_device(). Signed-off-by: William Breathitt Gray <wbg@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241101-pci_iomap_region_gpio_acces-v1-1-26eb1dc93e45@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: cdev: don't report GPIOs requested as interrupts as usedBartosz Golaszewski
GPIOs used as shared irqs can still be requested by user-space (or kernel drivers for that matter) yet we report them as used over the chardev ABI. Drop the test for FLAG_USED_AS_IRQ from gpio_desc_to_lineinfo(). Reviewed-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241031200842.22712-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: sysfs: emit chardev line-state events on edge storeBartosz Golaszewski
In order to emit line-state events on edge changes in sysfs, update the EDGE flags in the descriptor in gpio_sysfs_request_irq() and emit the event on a successful store. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241031-gpio-notify-sysfs-v4-5-142021c2195c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: sysfs: emit chardev line-state events on active-low changesBartosz Golaszewski
The sysfs active_low attribute doesn't go through the usual paths so it doesn't emit the line-state event. Add the missing call to gpiod_line_state_notify() to gpio_sysfs_set_active_low(). Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241031-gpio-notify-sysfs-v4-4-142021c2195c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: sysfs: emit chardev line-state events on GPIO exportBartosz Golaszewski
We already emit a CONFIG_RELEASED event when a line is unexported over sysfs (this is handled by gpiod_free()) but we don't do the opposite when it's exported. This adds the missing call to gpiod_line_state_notify(). Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241031-gpio-notify-sysfs-v4-3-142021c2195c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: sysfs: use cleanup guards for the sysfs_lock mutexBartosz Golaszewski
Shrink the code and remove some goto labels by using guards around the sysfs_lock mutex. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241031-gpio-notify-sysfs-v4-2-142021c2195c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04gpio: sysfs: use cleanup guards for gpiod_data::mutexBartosz Golaszewski
Shrink the code and drop some goto labels by using lock guards around gpiod_data::mutex. Reviewed-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20241031-gpio-notify-sysfs-v4-1-142021c2195c@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04drm/i915/dp: Add FEC Enable Retry mechanismChaitanya Kumar Borah
Currently, even though there is a bit to control FEC enable/disable individually, the FEC Decode Enable sequence is sent by the SOC only once TRANS_CONF enable is set. This ties the FEC enabling too tightly to modeset and therefore cannot be re-issued (in case of failure) without a modeset. From PTL, FEC_DECODE_EN sequence can be sent to a DPRX independent of TRANS_CONF enable. This allows us to re-issue an FEC_DECODE_EN sequence without a modeset. Hence allowing us to have a retry mechanism in case the DPRX does not respond with an FEC_ENABLE within certain amount of time. While at it, replace struct drm_i915_private with struct intel_display v4: - More code refactor [Jani] - use struct intel_display [Jani] - Optimize logging [Jani] v3: - Make the commit message more legible [Jani] - Refactor code to re-use existing code [Jani] - Do away with platform dependent FEC enable checks [Jani] v2: - Refactor code to avoid duplication and improve readability [Jani] - In case of PTL, wait for FEC status directly after FEC enable [Srikanth] - Wait for FEC_ENABLE_LIVE_STATUS to be cleared before re-enabling FEC [Srikanth] Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241024061002.4085137-1-chaitanya.kumar.borah@intel.com
2024-11-04gpiolib: clean up debugfs separator handlingJohan Hovold
Add the newline separator before generating the gpio chip entry to make the code easier to read. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241028125000.24051-4-johan+linaro@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-04Merge tag 'v6.12-rc6' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.12-rc6
2024-11-04Backmerge v6.12-rc6 of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Backmerge Linus tree for some drm-fixes needed for msm and xe merges. Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-11-03soc: qcom: llcc: Add LLCC configuration for the QCS8300 platformJingyi Wang
Add LLCC configuration for the QCS8300 platform. There is an errata on LB_CNT information on QCS8300 platform, hardcode num_banks to get the correct value. Signed-off-by: Jingyi Wang <quic_jingyw@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241031-qcs8300_llcc-v3-2-bb56952cb83b@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-03soc: qcom: llcc: Add configuration data for QCS615Song Xue
Add LLCC configuration support for the QCS615 platform. Signed-off-by: Song Xue <quic_songxue@quicinc.com> Link: https://lore.kernel.org/r/20241010-add_llcc_support_for_qcs615-v2-2-044432450a75@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-03soc: qcom: llcc: add support for SAR2130P and SAR1130PDmitry Baryshkov
Implement necessary support for the LLCC control on the SAR1130P and SAR2130P platforms. These two platforms use different ATTR1_MAX_CAP shift and also require manual override for num_banks. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241026-sar2130p-llcc-v3-3-2a58fa1b4d12@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-03soc: qcom: llcc: use deciman integers for bit shift valuesDmitry Baryshkov
As pointed out by Konrad Dybcio, we generally should be using decimal numbers to represent bit positions / bit shifts rather than hex numbers. Use decimals for consistency. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241026-sar2130p-llcc-v3-2-2a58fa1b4d12@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-04drm/exynos: exynos7_drm_decon: add driver data and support for Exynos7870Kaustabh Chakraborty
Add support for Exynos 7870 DECON in the Exynos 7 DECON driver. Some Exynos 7 series SoCs (Exynos 7580 onwards) have different register values. In order to address such changes, include a driver data struct (named decon_data) so that correct base addresses and shift values can be provided. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-11-04drm/exynos: exynos7_drm_decon: properly clear channels during bindKaustabh Chakraborty
The DECON channels are not cleared properly as the windows aren't shadow protected. When accompanied with an IOMMU, it pagefaults, and the kernel panics. Implement shadow protect/unprotect, along with a standalone update, for channel clearing to properly take effect. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-11-04drm/exynos: exynos7_drm_decon: fix ideal_clk by converting it to HzKaustabh Chakraborty
The clkdiv values are incorrect as ideal_clk is in kHz and the clock rate of vclk is in Hz. Multiply 1000 to ideal_clk to bring it to Hz. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-11-04drm/exynos: exynos7_drm_decon: fix uninitialized crtc reference in functionsKaustabh Chakraborty
Modify the functions to accept a pointer to struct decon_context instead. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-11-04drm/exynos: remove unused prototype for crtcKwanghoon Son
exynos_drm_crtc_wait_pending_update, exynos_drm_crtc_finish_update are not used anymore. Signed-off-by: Kwanghoon Son <k.son@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-11-04drm/exynos: gsc: Fix typo in commentShen Lichuan
Replace 'initailization' with 'initialization' in the comment. Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-11-04tpm: Lock TPM chip in tpm_pm_suspend() firstJarkko Sakkinen
Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved. Cc: stable@vger.kernel.org # v6.4+ Fixes: 99d464506255 ("tpm: Prevent hwrng from activating during resume") Reported-by: Mike Seo <mikeseohyungjin@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219383 Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Tested-by: Mike Seo <mikeseohyungjin@gmail.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-11-03net/mlx5e: do not create xdp_redirect for non-uplink repWilliam Tu
XDP and XDP socket require extra SQ/RQ/CQs. Most of these resources are dynamically created: no XDP program loaded, no resources are created. One exception is the SQ/CQ created for XDP_REDRIECT, used for other netdev to forward packet to mlx5 for transmit. The patch disables creation of SQ and CQ used for egress XDP_REDIRECT, by checking whether ndo_xdp_xmit is set or not. For netdev without XDP support such as non-uplink representor, this saves around 0.35MB of memory, per representor netdevice per channel. Signed-off-by: William Tu <witu@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241031125856.530927-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net/mlx5e: move XDP_REDIRECT sq to dynamic allocationWilliam Tu
Dynamically allocating xdpsq, used by egress side XDP_REDIRECT. mlx5 has multiple XDP sqs. Under struct mlx5e_channel: 1. rx_xdpsq: used for XDP_TX, an XDP prog handles the rx packet and transmits using the same queue as rx. 2. xdpsq: used by egress side XDP_REDIRECT. This is for another interface to redirect packet to the mlx5 interface, using ndo_xdp_xmit . 3. xsksq: used by XSK. XSK has its own dedicated channel, and it also has resources of 1 and 2. The patch changes only the 2. xdpsq. Signed-off-by: William Tu <witu@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241031125856.530927-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net/mlx5: HWS, renamed the files in accordance with naming conventionYevgeny Kliteynik
Removed the 'mlx5hws_' file name prefix from the internal HWS files. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241031125856.530927-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net/mlx5: DR, moved all the SWS code into a separate directoryYevgeny Kliteynik
After adding HWS support in a separate folder, moving all the SWS code into its own folder as well. Now SWS and HWS implementation are located in their appropriate folders: - steering/sws/ - steering/hws/ Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241031125856.530927-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net/mlx5: Rework esw qos domain init and cleanupCosmin Ratiu
The first approach was flawed, because there are situations where the esw mode change fails, leaving the qos domain as NULL. Various calls into the QoS infra then trigger a NULL pointer access and unhappiness. Improve that by a combination of: - Allocating the QoS domain on esw init and cleaning it up on teardown. - Refactoring mode change to only call qos domain init but not cleanup. - Making qos domain init idempotent - not change anything if nothing needs changing. Together, these should guarantee that, as long as the memory allocations succeed, there should always be a valid qos domain until the esw cleanup, no matter what mode changes happen (or failures thereof). Fixes: 107a034d5c1e ("net/mlx5: qos: Store rate groups in a qos domain") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241031125856.530927-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: xgmac: Enable FPE for tc-mqprio/tc-taprioFurong Xu
The FPE on XGMAC is ready, it is time to update dwxgmac_tc_ops to let user configure FPE via tc-mqprio/tc-taprio. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/0575ef1553d572b7c8bc1baafa3fb7ac641073e0.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: xgmac: Complete FPE supportFurong Xu
Implement the necessary fpe_map_preemption_class callback for xgmac. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/d0347f2b8a71fee372e53293fe26a6538775ec5d.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: xgmac: Rename XGMAC_RQ to XGMAC_FPRQFurong Xu
Synopsys XGMAC Databook defines MAC_RxQ_Ctrl1 register: RQ: Frame Preemption Residue Queue XGMAC_FPRQ is more readable and more consistent with GMAC4. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/611991edf9e9d6fac8b29c3fe952791b193ca179.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: Get the TC number of net_device by netdev_get_num_tc()Furong Xu
netdev_get_num_tc() is the right method, we should not access net_device.num_tc directly. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/6298463f4655a76faf94e4273a4205c13ca17c77.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: Refactor FPE functions to generic versionFurong Xu
FPE implementation for DWMAC4 and DWXGMAC differs only for: 1) Offset address of MAC_FPE_CTRL_STS and MTL_FPE_CTRL_STS 2) FPRQ(Frame Preemption Residue Queue) field in MAC_RxQ_Ctrl1 3) Bit offset of Frame Preemption Interrupt Enable Refactor FPE functions to avoid code duplication and to simplify the code flow by avoiding the use of function pointers. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/49de4607bae69ffe751b13329a3c07a990b82419.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: Introduce stmmac_fpe_supported()Furong Xu
A single "priv->dma_cap.fpesel" checks HW capability only, while both HW capability and driver capability shall be checked by later refactoring to prevent unexpected behavior for FPE on unsupported MAC cores and keep FPE as an optional implementation for current and new MAC cores. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/01e9cd13aedd38cb0e9a5d9875c475ce35250188.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: Rework macro definitions for gmac4 and xgmacFurong Xu
Rename and add macro definitions to better reuse them in common code. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/510b85288b13aa2cce5adf849291009c6f29a84a.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03net: stmmac: Introduce separate files for FPE implementationFurong Xu
By moving FPE related code info separate files, FPE implementation becomes a separate module initially. No functional change intended. Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/e9ddf4fbf0fc053ae30592aa6c4363e72a4d8e62.1730449003.git.0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03r8169: align RTL8126 EEE config with vendor driverHeiner Kallweit
Align the EEE config for RTL8126A with vendor driver r8126 to avoid compatibility issues. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/71e4859e-4cd0-4b6b-b7fa-621d7721992f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03r8169: align RTL8125/RTL8126 PHY config with vendor driverHeiner Kallweit
This aligns some parameters with vendor driver r8125/r8126 to avoid compatibility issues. Note that for RTL8125B there's no functional change, just the open-coded version of the function is replaced. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/a8a9d896-fbe6-41f2-bf87-666567d3cdb3@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-03r8169: align RTL8125 EEE config with vendor driverHeiner Kallweit
Align the EEE config for RTL8125A/RTL8125B with vendor driver r8125. This should help to avoid compatibility issues. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/044c925e-8669-4b98-87df-95b4056f4f5f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-16 02:46:20 +0000