On 12/19/2017 1:23 PM, Stanislaw Gruszka wrote:
> On Tue, Dec 19, 2017 at 12:36:36PM +0100, Arend van Spriel wrote:
>> On 12/15/2017 1:20 PM, Stanislaw Gruszka wrote:
>>> On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote:
>>>> # cat /sys/kernel/debug/brcmfmac/0000:03:00.0/revinfo
>>>
>>> vendorid: 0x14e4
>>> deviceid: 0x43ec
>>> radiorev: 0.41.32.105
>>> chipnum: 17238 (4356)
>>> chiprev: 2
>>> chippkg: 2
>>> corerev: 48
>>> boardid: 0x0777
>>> boardvendor: 0x14e4
>>> boardrev: P103
>>> driverrev: 7.35.180.119
>>> ucoderev: 0
>>> bus: 0
>>> phytype: 11
>>> phyrev: 17
>>> anarev: 0
>>> nvramrev: 00000000
>>
>> Thanks for the info. I was looking for the board info. It seems we
>> do not have an nvram file for that specific board.
>>
>> For SDIO devices I would suggest to use the module parameter
>> 'ignore_probe_fail' so we could do post-mortem stuff with the driver
>> bound to the device, but for PCIe there are not much debug options.
>> Let me work on that. May take a bit longer though.
>
> What about the revert of the firmware change if proper
> fix can not be soon available ?

Hi Stanislaw,

I had my colleague run some tests as he has the device, but he is an 
ocean away. So he could get the new firmware running with nvram file. 
For the old firmware the device could boot without nvram, but the scan 
results were showing that the device was not operating optimally. Could 
you try the new firmware with the attached sample nvram file and let me 
know if that works for you?

Regards,
Arend