You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Revert: "dma-trace: allocate trace buffer only after enabling traces"
A logical, not "real" git revert of commit eca2089 ("dma-trace:
allocate trace buffer only after enabling traces")
Move dma_trace_buffer_init() away from dma_trace_enable() and back to
dma_trace_init_early()
Restore the early traces removed by that commit. There was no rationale in
the commit message and it was merged without review in PR #255.
Earlier refactorings tried hard to trace early:
- commit 36e425e ("dma-trace: move to earlier initialisation point")
- commit 2b86cb3 ("trace: dma: Make sure we can trace platform
device initialisation.")
... so it's really not clear why early tracing was removed later. "Rage
quit" to avoid unidentified bugs?
This could have been to save one or two 4k HOST_PAGE_SIZE when the
kernel does not enable DMA traces but I can't see what real-world use
case would leverage such savings _at run-time_; what happens then when
the user changes her mind? We don't have any validation for a use case
so dynamic.
Tracing can be disabled at _compile-time_, recently fixed by
commit 571cc29 ("xtensa/cmake: fix !CONFIG_TRACE")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
0 commit comments