------- Original Message ------- On Friday, June 16th, 2023 at 2:06 PM, Anastasia Klimchuk aklm@chromium.org wrote:
Leonard, Thank you so much for your ideas and patches! Will have a look at these. As for signing off the patches, we recently updated the policy (in the same way as Linux did) so now it doesn't have to be a real real name. However it still needs to be a known identity, for example if everyone knows you by the nickname that's fine. If at any point in future you decide to send a patch for review from yourself, you are very welcome.
-- Anastasia.
Hi Anastasia,
Thank you for responding. I hope my notes will end up being of some use.
Thank you also for clarifying your contribution policy, though I'm afraid it still doesn't apply in my case.
There's another issue I've encountered since my e-mail. Since you indicates it's not a total waste of time to report such issues, I will.
Currently, if any write-protection mechanism is active on a chip, flashrom will try to read the WP state, unlock it, and then restore the WP protection state.
There's a corner case which the logic doesn't handle well. It's possible for WP ranges to be *locked* via OTP, but that actually the "protection" allows access everywhere (or anywhere needed, anyway). Currently, flashrom produces a warning message in `prepare_flash_access` with the notice "Failed to unlock flash status reg with wp support". However, there's no actual reason to try to unlock the register, since the "protection", while locked, doesn't hinder any access. In other words, flashrom tries to unlock the register seemingly only because it's locked, and not because a region targeted for write is protected.
Even stranger is the fact that `prepare_flash_access` is called from `flashrom_image_read`. That mean trying to *read* such a chip produces a warning about failing to disable write-protection.
The read does succeed though, so this is would be a low-priority quirk.
Kind regards,