On Thu, May 6, 2021 at 4:58 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > In SD spec v6.x the SD function extension registers for performance > enhancements were introduced. As a part of this an optional internal cache > on the SD card, can be used to improve performance. > > The let the SD card use the cache, the host needs to enable it and manage > flushing of the cache, so let's add support for this. > > Note that for an SD card supporting the cache it's mandatory for it, to > also support the poweroff notification feature. According to the SD spec, > if the cache has been enabled and a poweroff notification is sent to the > card, that implicitly also means that the card should flush its internal > cache. Therefore, dealing with cache flushing for REQ_OP_FLUSH block > requests is sufficient. > > Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> (...) > + /* > + * Set the Flush Cache bit in the performance enhancement register at > + * 261 bytes offset. > + */ > + fno = card->ext_perf.fno; > + page = card->ext_perf.page; > + offset = card->ext_perf.offset + 261; 261 looks a bit magic, can we add a define of some sort? I guess it has a name in the spec? > + err = sd_write_ext_reg(card, fno, page, offset, 0x1); > + if (err) { > + pr_warn("%s: error %d writing Cache Flush bit\n", > + mmc_hostname(host), err); > + goto out; > + } So this offset contains a single bit. > + if (reg_buf[0] & 0x1) > + err = -ETIMEDOUT; And that same bit is checked here. Is it always going to be one bit only or do we want to #include <linux/bits.h> #define SD_CACHE_FLUSH_FLAG BIT(0) Does it have a name in the spec we can use? > + /* > + * Set the Cache Enable bit in the performance enhancement register at > + * 260 bytes offset. > + */ > + err = sd_write_ext_reg(card, card->ext_perf.fno, card->ext_perf.page, > + card->ext_perf.offset + 260, 0x1); Same here we want to #define 260 to something symbolic, And here some define for BIT(0) as well. At least with BIT(0) in the call to sd_write_ext_reg() rather than 0x1 if I can say something. With the above nitpicking fixed up (I trust you): Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Yours, Linus Walleij