Wen Gong <wgong@xxxxxxxxxxxxxx> writes: > When firmware assert, it need coredump to analyze, this patch will > collect the register and memory info for sdio chip. > > The coredump configuration is different between PCIE and SDIO for > the same reversion, so this patch add bus type to distinguish PCIE > and SDIO chip for coredump. > > Tested with QCA6174 SDIO with firmware > WLAN.RMH.4.4.1-00007-QCARMSWP-1. > > Signed-off-by: Wen Gong <wgong@xxxxxxxxxxxxxx> [...] > +void ath10k_sdio_check_fw_reg(struct ath10k *ar, u32 *fast_dump) > +{ > + int ret = 0; > + u32 param; > + > + ret = ath10k_sdio_read_host_interest_value(ar, HI_ITEM(hi_option_flag2), ¶m); > + > + *fast_dump = ((param & HI_OPTION_SDIO_CRASH_DUMP_ENHANCEMENT_FW) > + == HI_OPTION_SDIO_CRASH_DUMP_ENHANCEMENT_FW); The commit log tells nothing about fast, it should always document the design decisions. Why this fast dump, what's the benefit? Why not always use the fast dump and forget the slow dump (or vice versa)? There needs to be really good reasons to have all this complexity to support both slow and fast dumps. > + ath10k_err(ar, "check fw reg : %x\n", param); > +} This is a debug message, not an error. And debug messages should use format "sdio hi_option_flag2 %x\n". -- Kalle Valo