From: Ben Greear <greearb@candelatech.com>
To: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: ath10k <ath10k@lists.infradead.org>
Subject: Re: Checking on interest in some patches...
Date: Tue, 13 Jan 2015 09:08:45 -0800 [thread overview]
Message-ID: <54B5511D.6030206@candelatech.com> (raw)
In-Reply-To: <878uh67qga.fsf@kamboji.qca.qualcomm.com>
On 01/13/2015 05:36 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> Previously, I was at a dead end trying to get support for CT firmware features,
>> expanded crash dump features, and other things accepted upstream.
>>
>> I am working on porting my changes to the 3.19 kernel, and was curious if
>> there is any change of opinion on possibly accepting at least some CT firmware
>> support or the crash dump features. If so, I'll clean up and re-post once
>> I have tested them.
>
> We have now four different firmware branches to support and I fear even
> more to come. Adding yet another branch is quite daunting from
> maintenance point of view.
No worse than the current code...and mine isn't really a new branch,
just a few small deviations from the existing 10.1 firmware. Even if you
don't want some of the larger changes, it would be nice to get in some of
the small and easy things like ibss support, lots of vdevs, maybe tx-rate
reporting, etc.
> Crash dump support is already upstream, but what's missing is porting it
> to use Johannes' device coredump (commit 833c95456a70) and RAM dump
> part. (And I guess we also want some sort register dump?)
>
> Last year I implemented the RAM dump part, but only did some quick
> verification and that's why I haven't submitted it yet. I think I need
> to submit it as RFC instead of bitrotting on my hard drive.
I have some well tested RAM and ROM and debuglog dump patches. Similar
to the patches we had worked on before. ROM and RAM require new ie header
on firmware, and 3.19 ath10k broke dbglog on upstream 10.1 firmware, but aside
from that, it works great :)
I have register dump supported over regular WMI api (shown in debugfs) in CT firmware,
but it is not part of the crash dump. At least for me, that has not
been a problem.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
prev parent reply other threads:[~2015-01-13 17:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 20:01 Checking on interest in some patches Ben Greear
2015-01-13 13:36 ` Kalle Valo
2015-01-13 17:08 ` Ben Greear [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54B5511D.6030206@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=kvalo@qca.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.