On Wed, 24 Apr 2019 at 17:31, Raul Rangel <rrangel@xxxxxxxxxxxx> wrote: > > On Tue, Apr 23, 2019 at 08:29:15AM +0200, Ulf Hansson wrote: > > On Tue, 16 Apr 2019 at 20:33, Raul E Rangel <rrangel@xxxxxxxxxxxx> wrote: > > > > > > I am not able to make a single event class for all these registers. They > > > all have different struct sizes and different printf formats. > > > > > > Thanks for the reviews! > > > > > > Changes in v2: > > > - Made trace_sd_scr print out flags. > > > - Add BUILD_BUG_ON to make sure tracing stays in sync with structs. > > > - memcpy using sizeof(__entry->raw) > > > > > > Raul E Rangel (4): > > > mmc: core: Add trace event for SD SCR response > > > mmc: core: Add trace event for SD SSR response > > > mmc: core: Add trace event for SD OCR response > > > mmc: core: Add trace event for CSD response > > > > > > drivers/mmc/core/mmc.c | 4 + > > > drivers/mmc/core/sd.c | 10 ++ > > > drivers/mmc/core/sd_ops.c | 6 ++ > > > include/trace/events/mmc.h | 204 +++++++++++++++++++++++++++++++++++++ > > > 4 files changed, 224 insertions(+) > > > > > > -- > > > 2.21.0.392.gf8f6787159e-goog > > > > > > > Why do you need this? We already have these card registers reflected > > though sysfs files, isn't that sufficient? > > > I was not actually aware that the registers were exposed via sysfs. I > was debugging a problem where the host controller was returning all > zeros when reading from the card. I wasn't aware that it was returning > all zeros until I added tracing. It made it quite easy to diagnose the > problem by just diffing the two traces. This sounds like a quite an unusual problem, and I don't think having the buffers printed via tracing is worth it. Moreover, we already have tracing per command/request (but don't print the buffers), that should cover most of error cases during init, don't you think? [...] Kind regards Uffe
