Re: Help me grok the ath(4) device attach code

> On May 31, 2023, at 1:52 PM, John Nielsen <lists@jnielsen.net> wrote:
> 
>> On May 30, 2023, at 11:17 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> 
>> On Tue, 30 May 2023 at 22:12, John Nielsen <lists@jnielsen.net <mailto:lists@jnielsen.net>> wrote:
>>>> On May 30, 2023, at 10:56 PM, Adrian Chadd <adrian@freebsd.org <mailto:adrian@freebsd.org>> wrote:
>>>> 
>>>> On Tue, 30 May 2023 at 20:56, John Nielsen <lists@jnielsen.net <mailto:lists@jnielsen.net>> wrote:
>>>>> > On May 30, 2023, at 8:02 PM, Adrian Chadd <adrian@freebsd.org <mailto:adrian@freebsd.org>> wrote:
>>>>> > 
>>>>> > Err, if it's coming up w/ that MAC then it's not finding and attaching right to the OTP/EEPROM calibration information. That's the big red flag that it in general won't work correctly.
>>>>> > 
>>>>> > Can you provide the rest of the ath_hal messages? I'd like to see what it's saying during boot around it checking the EEPROM/OTP contents. It's possible there's some work around required for this NIC.
>>>>> 
>>>>> He speaks! Thanks for taking the time. I just realized that ath_hal_printf doesn’t prepend “ath%d” so I’ve been missing those messages when grep-ing. Here’s the whole snippet:
>>>>> 
>>>>> ath0: <Atheros AR946x/AR948x> mem 0xf7a00000-0xf7a7ffff at device 0.0 on pci4
>>>>> ar9300_flash_map: unimplemented for now
>>>>> Restoring Cal data from DRAM
>>>>> Restoring Cal data from EEPROM
>>>>> Restoring Cal data from Flash
>>>>> Restoring Cal data from Flash
>>>>> Restoring Cal data from OTP
>>>>> ar9300_eeprom_restore_internal[4338] No vaid CAL, calling default template
>>>>> ar9300_hw_attach: ar9300_eeprom_attach returned 0
>>>> 
>>>> Yeah, this bit right here is the problem. It's not finding a valid calibration.
>>> 
>>>> oh err, is there a wifi enable/disable switch or something? maybe it's asserted and somehow it's mucking up the NIC?
>>> 
>>> There is a physical switch and it’s in the “enable” position.
>>> 
>>>>  I wonder what ath9k is doing here? Is there some weird pci based workaround/flag for the given NIC PCI id?
>>> 
>>> That was the first breadcrumb BZ threw me but I can’t find anything. There are some .driver_data hints for adjacent subdevice IDs but none for this one (Dell 0x020d) in either FreeBSD or Linux that I could find.
>>> 
>>> [snip]
>>> There is this commit in ath9k which mentions an alternative EEPROM address, but I’m not sure if that’s relevant. From what I can tell the probe should succeed at the normal base_address 0x3ff instead of needing to try the “4k” one 0xfff.
>>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath9k?id=528782ecf59f7bab2f1368628a479f49be59b512
>> 
>> Yeah i'd try that. It'd be nice if I knew that the NIC used OTP or EEPROM though.
>> 
>> There's known issues with all the Atheros chips (sigh) with how the EEPROM and PCIe bus reset .. interact.
>> (If the bus reset is too short then the EEPROM state machine gets stuck and nothing gets read.) It makes debugging this hard because the NIC itself will work in another device fine, because it's the BIOS/ACPI code. :(
> 
> The 4k EEPROM read didn’t work. But I did notice that where it says it’s restoring Cal data from OTP it actually just does an EEPROM read again. Shouldn’t this line be a call to ar9300_otp_read() instead of ar9300_eeprom_restore_internal_address()?
> 
> https://cgit.freebsd.org/src/tree/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c#n4292
> 
> Otherwise it doesn’t use the 0x14000 (0x30000 for some cards) OTP offset as a starting point.

I’d love to know if I’m up in the night about my theory above about the OTP call not actually happening. In the meantime I’ll carry on either trying to find/build a Linux kernel with CONFIG_ATH_DEBUG enabled that I can boot on the laptop (to see which EEPROM retrieval/check actually succeeds) and/or try to reimplement bits from the ath9k ar9300_eeprom_restore_internal() to match its behavior on FreeBSD.
( https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c#n3266 )

Thanks,

JN