To verify that Auto Update is possible, the mpfs_auto_update_state()
function performs a "Query Security Service Request" to the system
controller.

Previously, the check was performed on the first element of the
response message, which was accessed using a 32-bit pointer. This
caused the bitwise operation to reference incorrect data, as the
response should be inspected at the byte level. Fixed this by casting
the response to a  u8 * pointer, ensuring the check correctly inspects
the appropriate byte of the response message.

Additionally, rename "UL_Auto Update" to "UL_IAP" to match the
PolarFire Family System Services User Guide.

Signed-off-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

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
  ...

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>

fw_upload's poll_complete() is really intended for use with
asynchronous write() implementations - or at least those where the
write() loop may terminate without the kernel yet being aware of whether
or not the firmware upload has succeeded. For auto-update, write() is
only ever called once and will only return when uploading has completed,
be that by passing or failing. The core fw_upload code only calls
poll_complete() after the final call to write() has returned.

However, the poll_complete() implementation in the auto-update driver
was written to expect poll_complete() to be called from another context,
and it waits for a completion signalled from write(). Since
poll_complete() is actually called from the same context, after the
write() loop has terminated, wait_for_completion() never sees the
completion get signalled and always times out, causing programming to
always report a failing.

Since write() is full synchronous, and its return value will indicate
whether or not programming passed or failed, poll_complete() serves no
purpose and can be cut down to simply return FW_UPLOAD_ERR_NONE.

Cc: stable@vger.kernel.org
Fixes: ec5b0f1193ad4 ("firmware: microchip: add PolarFire SoC Auto Update support")
Reported-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Tested-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

After successfully programming the SPI flash with an MFPS auto update
image, the error sysfs attribute reports programming:timeout.
This is caused by an incorrect check on the return value from
wait_for_completion_timeout() in mpfs_auto_update_poll_complete().

Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

There's a bunch of structs created and freed every time the mailbox is
used. Move them to use the scope-based cleanup infrastructure to avoid
manually tearing them down. mpfs_auto_update_available() didn't free the
memory that it used (albeit it allocated exactly once during probe) so
that gets moved over too.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

This buffer is used exclusively by mpfs_auto_update_set_image_address(),
so move the management of it there, employing the recently added cleanup
infrastructure to avoid littering the function with gotos.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

Updating the FPGA image might bring with it changes visible to Linux,
so it is helpful to also co-locate dt-overlays that describe the new
image contents. If these are packaged in a specific format [1] (detected
by first 4 bytes being MCHP, since FPGA images have no magic), load
the file to the reserved 1 MiB region immediately after the directory in
flash. The Beagle-V Fire's "gateware" already creates these files and
puts them in flash [2].

Link: https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/how-to/re-programming-the-fpga-from-linux.md#main-header-format
Link: https://openbeagle.org/beaglev-fire/gateware/-/blob/main/gateware_scripts/generate_gateware_overlays.py?ref_type=heads [2]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

As it says on the tin. It can be kinda confusing when "22830" is in hex,
so prefix the hex numbers with a "0x".

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

If validation fails, both prints are made. Skip the success one in the
failure case.

Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>