linux.git/drivers/firmware/xilinx, branch for-next Linux kernel source tree Merge tag 'char-misc-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc 2024-11-29T19:58:27+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-11-29T19:58:27+00:00 2eff01ee2881becc9daaa0d53477ec202136b1f4 Pull char/misc/IIO/whatever driver subsystem updates from Greg KH: "Here is the 'big and hairy' char/misc/iio and other small driver subsystem updates for 6.13-rc1. Loads of things in here, and even a fun merge conflict! - rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present. Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :) - IIO driver updates, too many to list individually, that subsystem keeps growing and growing... - Interconnect driver updates - nvmem driver updates - pwm driver updates - platform_driver::remove() fixups, loads of them - counter driver updates - misc driver updates (keba?) - binder driver updates and fixes - loads of other small char/misc/etc driver updates and additions, full details in the shortlog. All of these have been in linux-next for a while, with no other reported issues other than that merge conflict" * tag 'char-misc-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (401 commits) mei: vsc: Fix typo "maintstepping" -> "mainstepping" firmware: Switch back to struct platform_driver::remove() misc: isl29020: Fix the wrong format specifier scripts/tags.sh: Don't tag usages of DEFINE_MUTEX fpga: Switch back to struct platform_driver::remove() mei: vsc: Improve error logging in vsc_identify_silicon() mei: vsc: Do not re-enable interrupt from vsc_tp_reset() dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Add SAR2130P compatible dt-bindings: spmi: spmi-mtk-pmif: Add compatible for MT8188 spmi: pmic-arb: fix return path in for_each_available_child_of_node() iio: Move __private marking before struct element priv in struct iio_dev docs: iio: ad7380: add adaq4370-4 and adaq4380-4 iio: adc: ad7380: add support for adaq4370-4 and adaq4380-4 iio: adc: ad7380: use local dev variable to shorten long lines iio: adc: ad7380: fix oversampling formula dt-bindings: iio: adc: ad7380: add adaq4370-4 and adaq4380-4 compatible parts bus: mhi: host: pci_generic: Use pcim_iomap_region() to request and map MHI BAR bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian misc: atmel-ssc: Use of_property_present() for non-boolean properties misc: keba: Add hardware dependency ... 
Pull char/misc/IIO/whatever driver subsystem updates from Greg KH:
 "Here is the 'big and hairy' char/misc/iio and other small driver
  subsystem updates for 6.13-rc1.

  Loads of things in here, and even a fun merge conflict!

   - rust misc driver bindings and other rust changes to make misc
     drivers actually possible.

     I think this is the tipping point, expect to see way more rust
     drivers going forward now that these bindings are present. Next
     merge window hopefully we will have pci and platform drivers
     working, which will fully enable almost all driver subsystems to
     start accepting (or at least getting) rust drivers.

     This is the end result of a lot of work from a lot of people,
     congrats to all of them for getting this far, you've proved many of
     us wrong in the best way possible, working code :)

   - IIO driver updates, too many to list individually, that subsystem
     keeps growing and growing...

   - Interconnect driver updates

   - nvmem driver updates

   - pwm driver updates

   - platform_driver::remove() fixups, loads of them

   - counter driver updates

   - misc driver updates (keba?)

   - binder driver updates and fixes

   - loads of other small char/misc/etc driver updates and additions,
     full details in the shortlog.

  All of these have been in linux-next for a while, with no other
  reported issues other than that merge conflict"

* tag 'char-misc-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (401 commits)
  mei: vsc: Fix typo "maintstepping" -> "mainstepping"
  firmware: Switch back to struct platform_driver::remove()
  misc: isl29020: Fix the wrong format specifier
  scripts/tags.sh: Don't tag usages of DEFINE_MUTEX
  fpga: Switch back to struct platform_driver::remove()
  mei: vsc: Improve error logging in vsc_identify_silicon()
  mei: vsc: Do not re-enable interrupt from vsc_tp_reset()
  dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Add SAR2130P compatible
  dt-bindings: spmi: spmi-mtk-pmif: Add compatible for MT8188
  spmi: pmic-arb: fix return path in for_each_available_child_of_node()
  iio: Move __private marking before struct element priv in struct iio_dev
  docs: iio: ad7380: add adaq4370-4 and adaq4380-4
  iio: adc: ad7380: add support for adaq4370-4 and adaq4380-4
  iio: adc: ad7380: use local dev variable to shorten long lines
  iio: adc: ad7380: fix oversampling formula
  dt-bindings: iio: adc: ad7380: add adaq4370-4 and adaq4380-4 compatible parts
  bus: mhi: host: pci_generic: Use pcim_iomap_region() to request and map MHI BAR
  bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian
  misc: atmel-ssc: Use of_property_present() for non-boolean properties
  misc: keba: Add hardware dependency
  ...
firmware: Switch back to struct platform_driver::remove() 2024-11-12T11:55:56+00:00 Uwe Kleine-König u.kleine-koenig@baylibre.com 2024-11-12T08:35:20+00:00 5770e9f237b6ee1cd17e06ecbc69c5e05efceacb After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/firmware to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/36974feb6035201d53384557259ec72fe311053b.1731397962.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.

Convert all platform drivers below drivers/firmware to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/36974feb6035201d53384557259ec72fe311053b.1731397962.git.u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: xilinx: fix feature check logic for TF-A specific APIs 2024-10-02T10:55:51+00:00 Ronak Jain ronak.jain@amd.com 2024-09-20T05:55:46+00:00 55ed774d0130adaa4ef12aefeb8e0638011cbe43 Currently, Linux is passing only API ID for feature of TF-A specific APIs but for feature check of TF-A specific APIs, TF-A is checking for Module ID + API ID as a result incorrect version is received for all TF-A specific APIs. So, fix feature check logic to pass valid arguments to get correct version. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Link: https://lore.kernel.org/r/20240920055546.2658783-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
Currently, Linux is passing only API ID for feature of TF-A specific
APIs but for feature check of TF-A specific APIs, TF-A is checking
for Module ID + API ID as a result incorrect version is received for
all TF-A specific APIs. So, fix feature check logic to pass valid
arguments to get correct version.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Link: https://lore.kernel.org/r/20240920055546.2658783-1-ronak.jain@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
firmware: xilinx: add support for new SMC call format 2024-10-02T10:54:45+00:00 Ronak Jain ronak.jain@amd.com 2024-09-20T05:55:01+00:00 92fb71333d5737d0296fb968a653dfda4b225175 Added zynqmp_pm_invoke_fw_fn() to use new SMC format in which lower 12 bits of SMC id are fixed and firmware header is moved to subsequent SMC arguments. The new SMC format supports full request and response buffers. Added zynqmp_pm_get_sip_svc_version() to get SiP SVC version number to check if TF-A is newer or older and use the SMC format accordingly to handle backward compatibility. Used new SMC format for PM_QUERY_DATA API as more response values are required in it. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Link: https://lore.kernel.org/r/20240920055501.2658642-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
Added zynqmp_pm_invoke_fw_fn() to use new SMC format in which
lower 12 bits of SMC id are fixed and firmware header is moved to
subsequent SMC arguments. The new SMC format supports full request and
response buffers.

Added zynqmp_pm_get_sip_svc_version() to get SiP SVC version
number to check if TF-A is newer or older and use the SMC format
accordingly to handle backward compatibility.

Used new SMC format for PM_QUERY_DATA API as more response values are
required in it.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Link: https://lore.kernel.org/r/20240920055501.2658642-1-ronak.jain@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
firmware: xilinx: add a warning print for unsupported feature 2024-10-02T10:51:02+00:00 Ronak Jain ronak.jain@amd.com 2024-09-20T05:54:10+00:00 e8415a8aecdb73cadfcfd1f1e1307d84413a5eb8 As per the current code base, feature check API is used to check the version in zynqmp_pm_pinctrl_set_config() before requesting the firmware, and if the expected version is not found then it will return an error. So now when the latest kernel tries to access the tri-state functionality with older firmware, observe failure prints during booting. The failure prints, [ 1.204850] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 37 param 2 value 0 [ 2.699455] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 44 param 2 value 0 [ 2.708424] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 46 param 2 value 0 [ 2.717387] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 48 param 2 value 0 Now, these error prints mislead the user whether it is an actual failure or the feature itself is not there in the firmware. So, just to avoid confusion around this, add some debug prints before returning an error code. With that, it is easier to know whether it is an actual failure or the feature is unsupported. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Link: https://lore.kernel.org/r/20240920055410.2658465-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
As per the current code base, feature check API is used to check the
version in zynqmp_pm_pinctrl_set_config() before requesting the
firmware, and if the expected version is not found then it will
return an error. So now when the latest kernel tries to access the
tri-state functionality with older firmware, observe failure prints
during booting.

The failure prints,
[    1.204850] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 37 param 2 value 0
[    2.699455] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 44 param 2 value 0
[    2.708424] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 46 param 2 value 0
[    2.717387] zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin 48 param 2 value 0

Now, these error prints mislead the user whether it is an actual
failure or the feature itself is not there in the firmware. So, just
to avoid confusion around this, add some debug prints before
returning an error code. With that, it is easier to know whether it is
an actual failure or the feature is unsupported.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Link: https://lore.kernel.org/r/20240920055410.2658465-1-ronak.jain@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
firmware: xilinx: use u32 for reset ID in reset APIs 2024-10-02T07:15:30+00:00 Ronak Jain ronak.jain@amd.com 2024-08-30T10:00:42+00:00 f33d6099edf78e3c97900c0173fedbfecc025a9e Refactors the reset handling mechanisms by replacing the reset ID's enum type with a u32. This update improves flexibility, allowing the reset ID to accommodate a broader range of values, including those that may not fit into predefined enum values. The use of u32 for reset ID enhances extensibility, especially for hardware platforms or features where more granular control of reset operations is required. By shifting to a general integer type, this change reduces constraints and simplifies integration with other system components that rely on non-enum-based reset IDs. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Link: https://lore.kernel.org/r/20240830100042.3163511-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
Refactors the reset handling mechanisms by replacing the reset ID's
enum type with a u32. This update improves flexibility, allowing the
reset ID to accommodate a broader range of values, including those
that may not fit into predefined enum values.

The use of u32 for reset ID enhances extensibility, especially for
hardware platforms or features where more granular control of reset
operations is required. By shifting to a general integer type, this
change reduces constraints and simplifies integration with other
system components that rely on non-enum-based reset IDs.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Link: https://lore.kernel.org/r/20240830100042.3163511-1-ronak.jain@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
firmware: xilinx: Add missing debug firmware interfaces 2024-10-02T07:15:30+00:00 Ronak Jain ronak.jain@amd.com 2024-07-30T08:43:42+00:00 848f2bbb363d4cdb4202db328a103fd3c34e21a2 Add missing PM EEMI APIs interface in debug firmware driver. The debugfs firmware driver interface is intended for testing and debugging the EEMI APIs only. This interface does not contain any checking regarding improper usage, and the number, type and valid ranges of the arguments. This interface must be used with a lot of care. In fact, accessing this interface during normal PM operation will very likely cause unexpected problems. The debugfs interface shouldn't be used in the production system and hence it is disabled by default in defconfig. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20240730084342.1683231-1-ronak.jain@amd.com 
Add missing PM EEMI APIs interface in debug firmware driver.

The debugfs firmware driver interface is intended for testing and
debugging the EEMI APIs only. This interface does not contain any
checking regarding improper usage, and the number, type and valid
ranges of the arguments. This interface must be used with a lot of
care. In fact, accessing this interface during normal PM operation
will very likely cause unexpected problems.

The debugfs interface shouldn't be used in the production system and
hence it is disabled by default in defconfig.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20240730084342.1683231-1-ronak.jain@amd.com
firmware: xilinx: Move FIRMWARE_VERSION_MASK to xlnx-zynqmp.h 2024-06-03T11:07:56+00:00 Ronak Jain ronak.jain@amd.com 2024-04-25T09:59:13+00:00 494c55a1ec0ab40198cf43f5a41c7c5e0b70e7fc Move FIRMWARE_VERSION_MASK macro to xlnx-zynqmp.h so that other drivers can use it for verifying the supported firmware version. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Anand Ashok Dumbre <anand.ashok.dumbre@amd.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://lore.kernel.org/r/20240425095913.919390-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
Move FIRMWARE_VERSION_MASK macro to xlnx-zynqmp.h so that other
drivers can use it for verifying the supported firmware version.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Signed-off-by: Anand Ashok Dumbre <anand.ashok.dumbre@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/20240425095913.919390-1-ronak.jain@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
firmware: xilinx: Add ZynqMP efuse access API 2024-03-07T20:21:53+00:00 Praveen Teja Kundanala praveen.teja.kundanala@amd.com 2024-02-24T11:45:10+00:00 e34b943068d30f20db31f28100affdaaedc7efab Add zynqmp_pm_efuse_access API in the ZynqMP firmware for read/write access of efuse memory. Signed-off-by: Praveen Teja Kundanala <praveen.teja.kundanala@amd.com> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240224114516.86365-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Add zynqmp_pm_efuse_access API in the ZynqMP
firmware for read/write access of efuse memory.

Signed-off-by: Praveen Teja Kundanala <praveen.teja.kundanala@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20240224114516.86365-6-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: xilinx: Export function to use in other module 2024-01-04T16:02:49+00:00 Jay Buddhabhatti jay.buddhabhatti@amd.com 2023-12-19T05:50:24+00:00 0c4b2255b7afbcc80f4efcc8f67425162f49c263 Export zynqmp_pm_get_family_info() to access and find family information in other module. Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Link: https://lore.kernel.org/r/20231219055025.27570-2-jay.buddhabhatti@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Export zynqmp_pm_get_family_info() to access and find family information
in other module.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Link: https://lore.kernel.org/r/20231219055025.27570-2-jay.buddhabhatti@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>