Search Linux Wireless

RE: [PATCH 5/6] mwifiex: use generic name 'device dump'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Johannes,

> From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, May 26, 2015 8:01 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@xxxxxxxxxxxxxxx; Cathy Luo; Avinash Patil
> Subject: Re: [PATCH 5/6] mwifiex: use generic name 'device dump'
> 
> On Tue, 2015-05-26 at 06:34 -0700, Amitkumar Karwar wrote:
> > Currently we are dumping driver information also inside firmware dump
> > API. We will call it as device dump and dump driver and firmware data
> > separately.
> 
> Honestly, I don't think this matters. I called it 'devcoredump' or
> 'device' because there were people saying it might be used to dump
> hardware state, rather than firmware state (my original thought was to
> call the framework 'fwcoredump')
> 
> In your driver, it's really only dumping firmware state (as far as I can
> tell), so I don't think the name matters.
> 

Thanks for your review. We are dumping driver data as well along with firmware state. Hence we thought of renaming 'fw_dump' with 'device_dump'.

static void mwifiex_sdio_device_dump_work(struct mwifiex_adapter *adapter)
{
        mwifiex_drv_info_dump(adapter);
        mwifiex_sdio_fw_dump(adapter);
        mwifiex_upload_device_dump(adapter);
}


static void mwifiex_pcie_device_dump_work(struct mwifiex_adapter *adapter)
{
        mwifiex_drv_info_dump(adapter);
        mwifiex_pcie_fw_dump(adapter);
        mwifiex_upload_device_dump(adapter);
}

> If you prefer "device dump" that's surely fine, but changing all the
> debugfs file names etc. just because I called the framework
> "devcoredump" isn't really needed I think :)

Debugfs file name is changed because 'device_dump' will now take care of dumping both driver data and firmware state.

> 
> Note that the framework is really also built to support "spontaneous"
> data collection, e.g. when the driver noticed the firmware doing
> something strange. You seem to support "user-triggered" only, which is
> perfectly reasonable again if you want it, but not necessary.

Currently we are triggering the dump operation in our command timeout handler as well. This would help us debug possible firmware bug causing timeout.

Regards,
Amitkumar

��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux