summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-06-20staging: rtl8192e: remove comparison to trueMichael Straube
Remove a comparison to true reported by checkpatch. CHECK: Using comparison to true is error prone Signed-off-by: Michael Straube <straube.linux@gmail.com> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/20230619150953.22484-5-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: rtl8192e: remove return statement from void functionMichael Straube
Remove unnecessary return statement from the void function rtl92e_config_mac(). Issue found by checkpatch. WARNING: void function return statements are not generally useful Signed-off-by: Michael Straube <straube.linux@gmail.com> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/20230619150953.22484-4-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: rtl8192e: convert else if sequence to switchMichael Straube
Convert a sequence of else if statements that all check the same variable to a single switch statement. With a switch statement it is easier to see what is going on. Additionally this clears a checkpatch warning. WARNING: braces {} are not necessary for any arm of this statement Signed-off-by: Michael Straube <straube.linux@gmail.com> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/20230619150953.22484-3-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: rtl8192e: clean up brace coding style issuesMichael Straube
Clean up brace coding style in if/else statements to improve readability and clear checkpatch issues. CHECK: braces {} should be used on all arms of this statement CHECK: Unbalanced braces around else statement Signed-off-by: Michael Straube <straube.linux@gmail.com> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/20230619150953.22484-2-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: rtl8723bs: Fix blank line issuesFranziska Naepelt
Fix the following checkpatch blank line issues: - CHECK: Please don't use multiple blank lines - CHECK: Blank lines aren't necessary before a close brace '}' - CHECK: Blank lines aren't necessary after an open brace '{' Signed-off-by: Franziska Naepelt <franziska.naepelt@gmail.com> Link: https://lore.kernel.org/r/20230619181246.19112-1-franziska.naepelt@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: rtl8723bs: Fix block comment issueFranziska Naepelt
Fix the following checkpatch block comment issue: - WARNING: Block comments use * on subsequent lines Signed-off-by: Franziska Naepelt <franziska.naepelt@gmail.com> Link: https://lore.kernel.org/r/20230619181230.19070-1-franziska.naepelt@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: rtl8723bs: Fix indentation issuesFranziska Naepelt
Fix the following checkpatch indentation issues: - WARNING: suspect code indent for conditional statements (32, 48) - WARNING: suspect code indent for conditional statements (24, 24) - ERROR: code indent should use tabs where possible Signed-off-by: Franziska Naepelt <franziska.naepelt@gmail.com> Link: https://lore.kernel.org/r/20230619180351.18925-1-franziska.naepelt@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20staging: vchiq_arm: Remove extra struct vchiq_instance declarationUmang Jain
Additional declaration of struct vchiq_instance was introduced in the commit 726e79f8a648 ("staging: vchiq_arm: pass vchiq instance to service callbacks"). Drop the extra declaration. Fixes: 726e79f8a648 ("staging: vchiq_arm: pass vchiq instance to service callbacks") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Link: https://lore.kernel.org/r/20221221074047.233473-1-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-20accel/qaic: Call DRM helper function to destroy prime GEMPranjal Ramajor Asha Kanojiya
smatch warning: drivers/accel/qaic/qaic_data.c:620 qaic_free_object() error: dereferencing freed memory 'obj->import_attach' obj->import_attach is detached and freed using dma_buf_detach(). But used after free to decrease the dmabuf ref count using dma_buf_put(). drm_prime_gem_destroy() handles this issue and performs the proper clean up instead of open coding it in the driver. Fixes: ff13be830333 ("accel/qaic: Add datapath") Reported-by: Sukrut Bellary <sukrut.bellary@linux.com> Closes: https://lore.kernel.org/all/20230610021200.377452-1-sukrut.bellary@linux.com/ Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230614161528.11710-1-quic_jhugo@quicinc.com
2023-06-20swim: fix a missing FMODE_ -> BLK_OPEN_ conversion in floppy_openChristoph Hellwig
Fix a missing conversion to the new BLK_OPEN constant in swim. Fixes: 05bdb9965305 ("block: replace fmode_t with a block-specific type for block open flags") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230620043051.707196-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-06-20mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019Marek Vasut
This microSD card never clears Flush Cache bit after cache flush has been started in sd_flush_cache(). This leads e.g. to failure to mount file system. Add a quirk which disables the SD cache for this specific card from specific manufacturing date of 11/2019, since on newer dated cards from 05/2023 the cache flush works correctly. Fixes: 08ebf903af57 ("mmc: core: Fixup support for writeback-cache for eMMC and SD") Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230620102713.7701-1-marex@denx.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20platform/x86:intel/pmc: Add Meteor Lake IOE-M PMC related mapsXi Pardee
Add device ID and register maps for the PMC in IO expansion die M in Meteor Lake. Signed-off-by: Xi Pardee <xi.pardee@intel.com> Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-9-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Add Meteor Lake IOE-P PMC related mapsXi Pardee
Add device ID and register maps for the PMC in IO expansion die P in Meteor Lake. Signed-off-by: Xi Pardee <xi.pardee@intel.com> Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-8-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Use SSRAM to discover pwrm base address of primary PMCXi Pardee
On older platforms, the base address for PMC was hardcoded in the driver. Newer platforms can now retrieve the base address from SSRAM. Use SSRAM to discover pwrm base address on Meteor Lake platform. If this method fails, it will fall back to the hardcoded value. Signed-off-by: Xi Pardee <xi.pardee@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-7-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Discover PMC devicesDavid E. Box
On platforms with multiple PMCs, additional PMC devices are discovered in the SSRAM device associated with the primary PMC. Add support for discovering PMC devices from SSRAM. Use PMC devid to assign the corresponding register map. Signed-off-by: Xi Pardee <xi.pardee@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-6-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Enable debugfs multiple PMC supportXi Pardee
Enable debugfs support for multiple PMC. These debugfs attributes show information for all enabled PMCs. pch_ip_power_gating_status substate_status_registers substate_live_status_registers ltr_show ltr_ignore Signed-off-by: Xi Pardee <xi.pardee@intel.com> Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-5-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Add support to handle multiple PMCsXi Pardee
To support platforms with multiple PMCs, add a PMC device structure to support each PMC instance. Signed-off-by: Xi Pardee <xi.pardee@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-4-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Combine core_init() and core_configure()Xi Pardee
Combine core_init() and core_configure() functions to have a cleaner setup for platforms. Signed-off-by: Xi Pardee <xi.pardee@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-3-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86:intel/pmc: Update maps for Meteor Lake P/M platformsXi Pardee
Fix the IP name errors in the register maps used by the following debugfs attributes in the Meteor Lake SOC-M PMC. pfear_sts lpm_sts ltr_show Fixes: c5ad454a12c6 ("platform/x86: intel/pmc/core: Add Meteor Lake support to pmc core driver") Signed-off-by: Xi Pardee <xi.pardee@intel.com> Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-2-rajvi.jingar@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86/intel: tpmi: Remove hardcoded unit and offsetSrinivas Pandruvada
Use sizeof(u32) for TPMI entry size units. Also add a define for capability offset unit size. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20230617014447.2543592-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-06-20platform/x86: int3472: discrete: Log a warning if the pin-numbers don't matchHans de Goede
The INT3472 discrete code assumes that the ACPI GPIO resources are in the same order as the pin-info _DSM entries. The returned pin-info includes the pin-number in bits 15-8. Add a check that this matches with the ACPI GPIO resource pin-number in case the assumption is not true with some ACPI tables. Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-7-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Use FIELD_GET() on the GPIO _DSM return valueHans de Goede
Add defines for the various fields encoded in the GPIO _DSM integer return value and then use FIELD_GET() to get field values. Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-6-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Add alternative "AVDD" regulator supply nameHans de Goede
Add an "AVDD" regulator supply name alias to the supply-map which gets registered for the INT3472 GPIO regulator. This is necessary for the ov2680 driver which expects "AVDD" rather then "avdd". Updating the ov2680 driver to use "avdd" is not possible because that will break compatibility with existing DT / DTB files. Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230616172132.37859-5-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Add support for 1 GPIO regulator shared ↵Hans de Goede
between 2 sensors On the Lenovo Miix 510-12IKB there is 1 GPIO regulator, with its GPIO listed in the INT3472 device belonging to the OV5648 back sensor. But this regulator also needs to be enabled for the OV2680 front sensor to work. Add support to skl_int3472_register_regulator() to add supply map entries pointing to both sensors based on a DMI quirk table which gives the dev_name part of the supply map for the second sensor (the sensor without the GPIO listed in its matching INT3472 ACPI device). Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-4-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Remove sensor_config-sHans de Goede
Currently the only 2 sensor_config-s both specify "avdd" as supply-id. The INT3472 device is going to be the only supplier of a regulator for the sensor device. So there is no chance of collisions with other regulator suppliers and it is undesirable to need to manually add new entries to int3472_sensor_configs[] for each new sensor module which uses a GPIO regulator. Instead just always use "avdd" as supply-id when registering the GPIO regulator. If necessary for specific sensor drivers then other supply-ids can be added as aliases in the future, adding aliases will be safe since INT3472 will be the only regulator supplier for the sensor. Cc: Bingbu Cao <bingbu.cao@intel.com> Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230616172132.37859-3-hdegoede@redhat.com
2023-06-20platform/x86: int3472: discrete: Drop GPIO remapping supportHans de Goede
The only sensor driver which needs GPIO remapping support is the ov2680 driver and ACPI enumeration support + other necessary changes to the ov2680 driver were never upstreamed. A new series updating the ov2680 driver is pending upstream now and in this series the ov2680 driver is patched to look for "powerdown" as con-id, instead of relying on GPIO remapping in the int3472 code, so the GPIO remapping is no longer necessary. Tested-by: Hao Yao <hao.yao@intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-2-hdegoede@redhat.com
2023-06-20cpufreq: amd-pstate: Set default governor to schedutilMario Limonciello
The Kconfig currently defaults the governor to schedutil on x86_64 only when intel-pstate and SMP have been selected. If the kernel is built only with amd-pstate, the default governor should also be schedutil. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Tested-by: Perry Yuan <Perry.Yuan@amd.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IP v2.1.0Manivannan Sadhasivam
SoCs making use of Qcom PCIe controller IP v2.1.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-10-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IP v1.0.0Manivannan Sadhasivam
SoCs making use of Qcom PCIe controller IP v1.0.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-9-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2023-06-20PCI: qcom: Use post init sequence of IP v2.3.2 for v2.4.0Manivannan Sadhasivam
The post init sequence of IP v2.4.0 is same as v2.3.2. So let's reuse the v2.3.2 sequence which now also disables hotplug capability of the controller as it is not at all supported on any SoCs making use of this IP. Link: https://lore.kernel.org/r/20230619150408.8468-8-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IP v2.3.2Manivannan Sadhasivam
SoCs making use of Qcom PCIe controller IP v2.3.2 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-7-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IPs v2.3.3 and v2.9.0Manivannan Sadhasivam
SoCs making use of Qcom PCIe controller IPs v2.3.3 and v2.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's not set the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-6-manivannan.sadhasivam@linaro.org Tested-by: Sricharan Ramabadhran <quic_srichara@quicinc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-06-20PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0Manivannan Sadhasivam
SoCs making use of Qcom PCIe controller IPs v2.7.0 and v1.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-5-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-06-20PCI: qcom: Disable write access to read only registers for IP v2.9.0Manivannan Sadhasivam
In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. While at it, let's also add a newline after existing dw_pcie_dbi_ro_wr_en() guard function to align with rest of the driver. Link: https://lore.kernel.org/r/20230619150408.8468-4-manivannan.sadhasivam@linaro.org Fixes: 0cf7c2efe8ac ("PCI: qcom: Add IPQ60xx support") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-06-20PCI: qcom: Use DWC helpers for modifying the read-only DBI registersManivannan Sadhasivam
DWC core already exposes dw_pcie_dbi_ro_wr_{en/dis} helper APIs for enabling and disabling the write access to read only DBI registers. So let's use them instead of doing it manually. Also, the existing code doesn't disable the write access when it's done. This is also fixed now. Link: https://lore.kernel.org/r/20230619150408.8468-3-manivannan.sadhasivam@linaro.org Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-06-20PCI: qcom: Disable write access to read only registers for IP v2.3.3Manivannan Sadhasivam
In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. Link: https://lore.kernel.org/r/20230619150408.8468-2-manivannan.sadhasivam@linaro.org Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: <stable@vger.kernel.org>
2023-06-20mmc: core: disable TRIM on Kingston EMMC04G-M627Robert Marko
It seems that Kingston EMMC04G-M627 despite advertising TRIM support does not work when the core is trying to use REQ_OP_WRITE_ZEROES. We are seeing I/O errors in OpenWrt under 6.1 on Zyxel NBG7815 that we did not previously have and tracked it down to REQ_OP_WRITE_ZEROES. Trying to use fstrim seems to also throw errors like: [93010.835112] I/O error, dev loop0, sector 16902 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2 Disabling TRIM makes the error go away, so lets add a quirk for this eMMC to disable TRIM. Signed-off-by: Robert Marko <robimarko@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230619193621.437358-1-robimarko@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20mmc: mmci: stm32: add delay block support for STM32MP25Yann Gautier
On STM32MP25, the delay block is inside the SoC, and configured through the SYSCFG registers. The algorithm is also different from what was in STM32MP1 chip. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-7-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20mmc: mmci: stm32: prepare other delay block supportYann Gautier
Create an sdmmc_tuning_ops struct to ease support for another delay block peripheral. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-6-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20mmc: mmci: stm32: manage block gap hardware flow controlYann Gautier
In stm32 sdmmc variant revision v3.0, a block gap hardware flow control should be used with bus speed modes SDR104 and HS200. It is enabled by writing a non-null value to the new added register MMCI_STM32_FIFOTHRR. The threshold will be 2^(N-1) bytes, so we can use the ffs() function to compute the value N to be written to the register. The threshold used should be the data block size, but must not be bigger than the FIFO size. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-5-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20mmc: mmci: Add support for sdmmc variant revision v3.0Yann Gautier
This is an update of the SDMMC revision v2.2, with just an increased FIFO size, from 64B to 1kB. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-4-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20mmc: mmci: add stm32_idmabsize_align parameterYann Gautier
The alignment for the IDMA size depends on the peripheral version, it should then be configurable. Add stm32_idmabsize_align in the variant structure. And remove now unused (and wrong) MMCI_STM32_IDMABNDT_* macros. Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-3-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-06-20Merge tag 'devfreq-next-for-6.5' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Merge devfreq updates for v6.5 from Chanwoo Choi: "1. Reorder fieldls in 'struct devfreq_dev_status' in order to shrink the size of 'struct devfreqw_dev_status' without any behavior changes. 2. Add exynos-ppmu.c driver as a soft module dependency in order to prevent the freeze issue between exynos-bus.c devfreq driver and exynos-ppmu.c devfreq event driver. 3. Fix variable deferencing before NULL check on mtk-cci-devfreq.c" * tag 'devfreq-next-for-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: PM / devfreq: mtk-cci: Fix variable deferencing before NULL check PM / devfreq: exynos: add Exynos PPMU as a soft module dependency PM / devfreq: Reorder fields in 'struct devfreq_dev_status'
2023-06-20net: dsa: introduce preferred_default_local_cpu_port and use on MT7530Vladimir Oltean
Since the introduction of the OF bindings, DSA has always had a policy that in case multiple CPU ports are present in the device tree, the numerically smallest one is always chosen. The MT7530 switch family, except the switch on the MT7988 SoC, has 2 CPU ports, 5 and 6, where port 6 is preferable on the MT7531BE switch because it has higher bandwidth. The MT7530 driver developers had 3 options: - to modify DSA when the MT7531 switch support was introduced, such as to prefer the better port - to declare both CPU ports in device trees as CPU ports, and live with the sub-optimal performance resulting from not preferring the better port - to declare just port 6 in the device tree as a CPU port Of course they chose the path of least resistance (3rd option), kicking the can down the road. The hardware description in the device tree is supposed to be stable - developers are not supposed to adopt the strategy of piecemeal hardware description, where the device tree is updated in lockstep with the features that the kernel currently supports. Now, as a result of the fact that they did that, any attempts to modify the device tree and describe both CPU ports as CPU ports would make DSA change its default selection from port 6 to 5, effectively resulting in a performance degradation visible to users with the MT7531BE switch as can be seen below. Without preferring port 6: [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-20.00 sec 374 MBytes 157 Mbits/sec 734 sender [ 5][TX-C] 0.00-20.00 sec 373 MBytes 156 Mbits/sec receiver [ 7][RX-C] 0.00-20.00 sec 1.81 GBytes 778 Mbits/sec 0 sender [ 7][RX-C] 0.00-20.00 sec 1.81 GBytes 777 Mbits/sec receiver With preferring port 6: [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-20.00 sec 1.99 GBytes 856 Mbits/sec 273 sender [ 5][TX-C] 0.00-20.00 sec 1.99 GBytes 855 Mbits/sec receiver [ 7][RX-C] 0.00-20.00 sec 1.72 GBytes 737 Mbits/sec 15 sender [ 7][RX-C] 0.00-20.00 sec 1.71 GBytes 736 Mbits/sec receiver Using one port for WAN and the other ports for LAN is a very popular use case which is what this test emulates. As such, this change proposes that we retroactively modify stable kernels (which don't support the modification of the CPU port assignments, so as to let user space fix the problem and restore the throughput) to keep the mt7530 driver preferring port 6 even with device trees where the hardware is more fully described. Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dsa: mt7530: fix handling of LLDP framesArınç ÜNAL
LLDP frames are link-local frames, therefore they must be trapped to the CPU port. Currently, the MT753X switches treat LLDP frames as regular multicast frames, therefore flooding them to user ports. To fix this, set LLDP frames to be trapped to the CPU port(s). Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dsa: mt7530: fix handling of BPDUs on MT7530 switchArınç ÜNAL
BPDUs are link-local frames, therefore they must be trapped to the CPU port. Currently, the MT7530 switch treats BPDUs as regular multicast frames, therefore flooding them to user ports. To fix this, set BPDUs to be trapped to the CPU port. Group this on mt7530_setup() and mt7531_setup_common() into mt753x_trap_frames() and call that. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dsa: mt7530: fix trapping frames on non-MT7621 SoC MT7530 switchArınç ÜNAL
All MT7530 switch IP variants share the MT7530_MFC register, but the current driver only writes it for the switch variant that is integrated in the MT7621 SoC. Modify the code to include all MT7530 derivatives. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dsa: mt7530: set all CPU ports in MT7531_CPU_PMAPArınç ÜNAL
MT7531_CPU_PMAP represents the destination port mask for trapped-to-CPU frames (further restricted by PCR_MATRIX). Currently the driver sets the first CPU port as the single port in this bit mask, which works fine regardless of whether the device tree defines port 5, 6 or 5+6 as CPU ports. This is because the logic coincides with DSA's logic of picking the first CPU port as the CPU port that all user ports are affine to, by default. An upcoming change would like to influence DSA's selection of the default CPU port to no longer be the first one, and in that case, this logic needs adaptation. Since there is no observed leakage or duplication of frames if all CPU ports are defined in this bit mask, simply include them all. Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20net: dpaa2-mac: add 25gbase-r supportJosua Mayer
Layerscape MACs support 25Gbps network speed with dpmac "CAUI" mode. Add the mappings between DPMAC_ETH_IF_* and HY_INTERFACE_MODE_*, as well as the 25000 mac capability. Tested on SolidRun LX2162a Clearfog, serdes 1 protocol 18. Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-20Merge tag 'ieee802154-for-net-2023-06-19' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan Stefan Schmidt says: ==================== An update from ieee802154 for your *net* tree: Two small fixes and MAINTAINERS update this time. Azeem Shaikh ensured consistent use of strscpy through the tree and fixed the usage in our trace.h. Chen Aotian fixed a potential memory leak in the hwsim simulator for ieee802154. Miquel Raynal updated the MAINATINERS file with the new team git tree locations and patchwork URLs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-16 22:29:26 +0000