Ath10k leaves AR9880 in a state that will not enumerate again when CPU warm booted

David Dailey daileycrew at gmail.com
Thu Nov 13 06:53:06 PST 2014


Yes, we have a known platform issue I mentioned where we don't assert
any hw reset line to the PCIe slot during warm boot.  It does assert
on cold boot.  Sounds like this issue is the same one you describe and
unique to QCA parts.  I was hoping to get lucky and someone would know
how to re-init the PCI block via software before reboot as a work
around.  Thanks for the info.

Dave

On Wed, Nov 12, 2014 at 4:43 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> Is the length / number of card resets during a warm boot differ to cold boot?
>
> There's a known behavioural quirk where if the reset line isn't held
> for long enough or there's too short a gap between one and another
> reset assertion, the NIC doesn't fully initialise right.
>
>
>
> -a
>
>
> On 12 November 2014 13:34, David Dailey <daileycrew at gmail.com> wrote:
>> I discovered that this issue seems to follow at least 2 different
>> chipsets (AR9880 and AR9890) but doesn't happen with at least two BCM
>> chipsets.  And the enumeration failing after a warm boot doesn't
>> depend on ath10k loading at all.  Even with the module not present on
>> the system, the device doesn't enumerate after cold boot.  So it
>> appears this is something unique to the PCIe core on Atheros, not
>> ath10k.  I guess the only hope would be if somehow the unload of the
>> driver could restore the chipset back to a state where it would
>> enumerate again, but I don't have information on the chipset at that
>> level.
>>
>> Dave
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k



More information about the ath10k mailing list