mirror of
https://github.com/DarkFlippers/unleashed-firmware.git
synced 2026-10-22 15:21:20 +00:00
Mykhailo ShevchukandClaude Opus 5
65d271d751
* LF RFID: say what the write-target masking actually fixes The comment landed in #1164 credited the change with stopping the settings page writing unknown bits back into the file. It cannot: lfrfid_settings_set_write_targets() has masked its input since the feature landed in #1146 and is the only writer of that file, so those bits were always dropped on save. The claim came from the issue and I carried it through review without checking it. What the mask on read is really for: in tree, lfrfid_scene_write.c stashes the raw value as scene state and tests it against 0, so a newer-only bit made "everything switched off" report "No enabled chip can write this protocol" instead of pointing at Settings. Out of tree, the getter is exported, and an app cannot re-mask against an enum it does not have. Also moves the obligation next to the rule that creates it, at the top of the file where the next target gets appended, and drops a clause that restated the log line below it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * LF RFID: port the last two iButton settings guards #1164 aligned the masking but left the rest of the divergence in place. _Static_assert: lfrfid_settings_set_write_targets() builds the whole LFRFIDSettings from a designated initialiser, so a second setting added later would be zeroed on every save with no error and no symptom until a user noticed a choice that would not stick. ibutton_settings.c has guarded this since #1153; this is the same assert with the same message. The unchecked storage_simply_mkdir() return gets the twin's second sentence, so the next reader does not have to re-derive that the save below reports the failure. LFRFID_WRITE_TARGET_MASK_ALL's doc pointed at MASK_DEFAULT, which has never existed anywhere in the tree; ibutton_write_targets.h already names the function correctly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * CHANGELOG: correct the LF RFID write-targets entry The entry described a settings-corruption round trip that the code could not produce - the setter has always masked. Replaced with the symptom that was real. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * LF RFID: bound the getter's promise to this firmware, not the app's SDK Review of the previous commit caught it making the same shape of over-claim it was written to delete. "every bit it is handed is nameable" is not true for an app: the mask applied is this firmware's LFRFID_WRITE_TARGET_MASK_ALL, and an app built against an older SDK has a narrower LFRFIDWriteTargetMax, so its own loop never reaches the bit. The firmware can name that target; the app has no way to learn it exists. What actually holds is the bound - what comes back is this firmware's targets, never whatever the file happened to contain. The CHANGELOG quoted one of the two write-screen messages and paraphrased the other, so half of it could not be grepped; both are quoted now. The file-top clause becomes its own sentence rather than a fourth one hanging off an already long one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>