Re: ATH9 driver issues on ARM64

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc Kalle, ath9k list]

On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
> Hi,
> 
> Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/)
> on ARM64.  The end point is TP link wifi card with which supports
> only legacy interrupts.

If it works on other arches and the arm64 PCI enumeration works, my
first guess would be an INTx issue, e.g., maybe the driver is waiting
for an interrupt that never arrives.

> We are trying to test it on ARM64 with
> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> 
> EP is getting enumerated and able to link up. 
> 
> But when we start scan system gets hanged.

When you say the system hangs when you start a scan, I assume you mean
a wifi scan, not the PCI enumeration.  A problem with a wifi scan
might cause a *process* to hang, but it shouldn't hang the entire
system.

> When we took trace we see that after we start scan assert message is
> sent but there is no de assert from end point.

Are you talking about a trace from a PCIe analyzer?  Do you see an
Assert_INTx PCIe message on the link?

> What might cause end point not sending de assert ?

If the endpoint doesn't send a Deassert_INTx message, I expect that
would mean the driver didn't service the interrupt and remove the
condition that caused the device to assert the interrupt in the first
place.

If the driver didn't receive the interrupt, it couldn't service it, of
course.  You could add a printk in the ath9k interrupt service
routine to see if you ever get there.

> We are not seeing any issues on 32-bit ARM platform and X86
> platform. 

Can you collect a dmesg log (or, if the system hang means you can't
collect that, a console log with "ignore_loglevel"), and "lspci -vv"
output as root?  That should have clues about whether the INTx got
routed correctly.  /proc/interrupts should also show whether we're
receiving interrupts from the device.

Bjorn