From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michal Kazior <michal.kazior@tieto.com>
Date: Fri, 14 Jun 2013 14:48:21 +0200
Subject: [ath9k-devel] [PATCH 3/3] ath10k: create debugfs interface to
 trigger fw crash
In-Reply-To: <8738skna5d.fsf@kamboji.qca.qualcomm.com>
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>
Message-ID: <51BB1115.7010803@tieto.com>
List-Id: <ath9k-devel.lists.ath9k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: ath9k-devel@lists.ath9k.org

On 14/06/13 14:34, Kalle Valo wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This can be useful for testing.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> 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.


-- Pozdrawiam / Best regards, Michal Kazior.