Hi Neil, Thanks for your feedback!
Sorry, it took me a while to respond. On Fri, May 29, 2026 at 09:54:32AM +0200, Neil Armstrong wrote: [..] > > > > > > > > The for NVMe, can it support write-through like SCSI FUA (Force Unit > > > Access) which bypasses the cache on writes, with slower writes > > > but safer and simpler than calling a flush before OS boot. > > > > Yes, I've seen there was FUA patch [1], which was then reverted [2]. > > > > For our purposes, flush seems to be enough: the use case is > > updating NVMe-backed boot counter from a custom bootflow. > > OK the FUA was reverted because Bin's comment was not adressed: > https://lore.kernel.org/u-boot/caeuhbmu02gnqeefuqnrsj8r5xezkmktualp1+bmbyqndztu...@mail.gmail.com/ > > I would prefer having FUA added so all board could have this enabled > and not have to update their boot flow to call flush, this was basically > why the SCSI FUA was enabled. I will take a look into FUA. The problem I was solving is providing a guarantee that GPT headers will be updated correctly on the NVMe device. I have a new bootcount device which implements a counter backed by GPT PTE flags (the top 16 bits) [1] Patch [2] adds new APIs to update 16 bit flags in both primary and backup GPT headers (the proposed write_gpt_pte() call). This is where I originally used new flush command: to guarantee that NVMe received all the updates before it is handed over to the OS. [1] https://lore.kernel.org/u-boot/[email protected]/ [2] https://lore.kernel.org/u-boot/[email protected]/ > > As Bin's comment, perhaps a way would be to disable the Write Cache if > the cache is present as init time (WCE), and it's even simpler, or > get the enable state of the WC and use FUA if enabled. > > Because the same question remains with the flush command, it's > only valid if the WC is present and is enabled. > > Thanks, > Neil > > > > > [1] > > https://lore.kernel.org/u-boot/20211019104049.v3.1.Ic581ec99f46b6dfa2e0b1922e670a333ac859e82@changeid/ > > [2] > > https://lore.kernel.org/u-boot/cagi-rul96gk5nfhx73uqqd_4sfbyt3gnwqhfphps+h58s20...@mail.gmail.com/ -- Denis
