Thread (10 messages) flat view 10 messages, 3 authors, 2d ago

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

From: David Heidelberg <david@ixit.cz>
Date: 2026-08-12 11:18:47
Also in: linux-arm-msm, linux-devicetree, lkml, oe-linux-nfc

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

[...]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help