From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kalle Valo Date: Fri, 14 Jun 2013 15:51:31 +0300 Subject: [ath9k-devel] [PATCH 3/3] ath10k: create debugfs interface to trigger fw crash In-Reply-To: <51BB1115.7010803@tieto.com> (Michal Kazior's message of "Fri, 14 Jun 2013 14:48:21 +0200") References: <1371042604-1822-1-git-send-email-michal.kazior@tieto.com> <1371042604-1822-4-git-send-email-michal.kazior@tieto.com> <8738skna5d.fsf@kamboji.qca.qualcomm.com> <51BB1115.7010803@tieto.com> Message-ID: <87txl0lusr.fsf@kamboji.qca.qualcomm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Michal Kazior writes: > On 14/06/13 14:34, Kalle Valo wrote: >> Michal Kazior writes: >> >>> This can be useful for testing. >>> >>> Signed-off-by: Michal Kazior >> >> This is handy. >> >>> +static ssize_t ath10k_read_simulate_fw_crash(struct file *file, >>> + char __user *user_buf, >>> + size_t count, loff_t *ppos) >>> +{ >>> + const char buf[] = "To simulate firmware crash write anything to this" >>> + " file.\nThis will force firmware to report a crash" >>> + " to the host system.\n"; >>> + return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf)); >>> +} >> >> But I'm not sure if just writing something to the file is a good idea. >> Should it have some sort of protection, for example that user needs to >> write a keyword or something? > > There are a few types of firmware failures that can be triggered. And > there's also a delay that can be specified. So in theory we could > accept parameters. > > I wanted to keep things simple though. I didn't need anything more > fancy than this to test firmware crashes/recovery. Sorry, I wasn't clear above. I was just worried that a user might accidentally crash the firmware through this interface by writing to a wrong file. Not very likely scenario, but can happen anyway. Having some sort of extra check (like a keyword) would avoid that case. -- Kalle Valo