Re: [PATCH v5 5/6] nfc: s3fwrn5: support the S3NRN4V variant

[David Heidelberg]

On 12/08/2026 00:01, Jorijn van der Graaf wrote:
> The S3NRN4V (e.g. on the Fairphone 6, SM7635) is a later part in the
> Samsung NFC controller line this driver covers. It needs different
> bring-up, selected with a new samsung,s3nrn4v compatible:
>
>   - It ships with working firmware, and its bootloader reports a
>     hardware version this driver has no flash base address for, so the
>     firmware download step is skipped. Its RF calibration data is
>     loaded with the proprietary DUAL_OPTION command (the HW and SW
>     blobs merged into a single stream) instead of the
>     START/SET/STOP_RFREG sequence. The upload is version-gated on
>     DUAL_OPTION GET_VER, matching the vendor stack: GET_VER reports
>     the chip's current calibration versions, and the push is skipped
>     when both match the blobs (each blob carries its version in its
>     last 16 bytes). post_setup runs on every device-up, so the
>     gate is what keeps the chip's calibration store from being rewritten
>     each time NFC is enabled.
>
>   - Its reference clock speed is configured with the single-byte FW_CFG
>     form, sent from the ->init hook, before CORE_RESET, in the same
>     order the vendor stack sends it. The vendor HAL uses the
>     single-byte form for this generation, and its vendor configuration
>     sets the selector to 0x11, which selects the 19.2 MHz reference.
>     Without this command the chip completes NCI initialization but
>     goes silent on RF_DISCOVER -- the command times out unanswered and
>     polling never starts (verified on hardware).
>
> The calibration data is requested from a chip-scoped directory,
> samsung/s3nrn4v/hwreg.bin and samsung/s3nrn4v/swreg.bin, rather than
> the flat sec_s3fwrn5_rfreg.bin name the older parts use.
>
> The variant is carried as match data by both the OF and the I2C device
> id tables so the two match paths agree.
>
> Existing S3FWRN5 / S3FWRN82 setups keep the firmware-download path and
> the legacy rfreg sequence, unchanged.
>
> Assisted-by: Claude:claude-opus-4-8
> Assisted-by: Claude:claude-fable-5
> Assisted-by: Claude:claude-opus-5

I was going to make a joke about over-assisted stuff with two-lines of 
Assisted-by before, but... :)

Here's my mental model:

 - It's good to know that you used an LLM (hence Assisted-by).
 - Someone may want to reproduce some generated code, so knowing which model was
   used is useful.
 - When you put THREE ;-) models there, I think it's getting a bit useless, as
   we don't know which part was generated or adjusted by which model. At this
   point, it feels somewhat pointless.

My recommendation would be to keep just one line for the model used for:

a) the majority of the changes
b) the last model used (at least for notable changes)
c) the most powerful model doing the generation and/or review

I personally don't mind either approach. There have been discussions about 
dropping Assisted-by completely, but so far it makes sense to me to keep it, 
just in moderation.

Also, the patchset is shaping up nicely! :)

Thank you for your work,
David

[...]