Re: PCI trouble on mvebu (Turris Omnia)

From: "™֟☻̭҇ Ѽ ҉ ®" <vtolkm@googlemail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh@kernel.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: PCI trouble on mvebu (Turris Omnia)
Date: Tue, 27 Oct 2020 22:01:00 +0000	[thread overview]
Message-ID: <15545174-46bf-8a35-0612-950a3dbefd0a@gmail.com> (raw)
In-Reply-To: <87y2jruziw.fsf@toke.dk>

[-- Attachment #1.1.1: Type: text/plain, Size: 3037 bytes --]

On 27/10/2020 22:31, Toke Høiland-Jørgensen wrote:
>>> To follow up on this, everything seems to work just fine (ath10k init at
>>> boot + regulatory db load) if I simply set:
>>>
>>> CONFIG_EXTRA_FIRMWARE="ath10k/QCA988X/hw2.0/board.bin ath10k/QCA988X/hw2.0/firmware-5.bin regulatory.db regulatory.db.p7s"
>>>
>>> -Toke
>>>
>> That works on my node only for the regulatory files but not the ath10
>> firmware with kconfig:
>>
>>    Symbol: EXTRA_FIRMWARE_DIR [=/srv/fw]
>>    Type  : string
>>    Defined at drivers/base/firmware_loader/Kconfig:63
>>      Prompt: Firmware blobs root directory
>>      Depends on: FW_LOADER [=y] && EXTRA_FIRMWARE [=regulatory.db
>> regulatory.db.p7s board.bin firmware-5.bin]!=
>>      Location:
>>       -> Device Drivers
>>         -> Generic Driver Options
>>           -> Firmware loader
>>             -> Firmware loading facility (FW_LOADER [=y])
>>               -> Build named firmware blobs into the kernel binary
>> (EXTRA_FIRMWARE [=regulatory.db regulatory.db.p7s board.bin
>> firmware-5.bin])
> I think that's because you're missing the path prefix
> (ath10k/QCA988X/hw2.0/) from board.bin and firmware-5.bin?
> request_firmware() uses the full path...
>
> -Toke

Well, that would be weird/strange having to specify the path prefix for 
build-in firmware,considering:

  CONFIG_FW_LOADER:

  This enables the firmware loading facility in the kernel. The kernel
  will first look for built-in firmware, if it has any. Next, it will
  look for the requested firmware in a series of filesystem paths:

        o firmware_class path module parameter or kernel boot param
        o /lib/firmware/updates/UTS_RELEASE
        o /lib/firmware/updates
        o /lib/firmware/UTS_RELEASE
        o /lib/firmware

----

Nevertheless, I tried with same path prefix as per your kconfig but the 
compilation fails, which I am not surprised since the ath10 blobs are 
not located at that path

   UPD     drivers/base/firmware_loader/builtin/regulatory.db.gen.S
   UPD drivers/base/firmware_loader/builtin/regulatory.db.p7s.gen.S
make[4]: *** No rule to make target 
'/srv/fw/ath10k/QCA988X/hw2.0/board.bin', needed by 
'drivers/base/firmware_loader/builtin/ath10k/QCA988X/hw2.0/board.bin.gen.o'. 
Stop.
make[4]: *** Waiting for unfinished jobs....
   UPD 
drivers/base/firmware_loader/builtin/ath10k/QCA988X/hw2.0/board.bin.gen.S
make[3]: *** [scripts/Makefile.build:500: 
drivers/base/firmware_loader/builtin] Error 2
make[2]: *** [scripts/Makefile.build:500: drivers/base/firmware_loader] 
Error 2
make[1]: *** [scripts/Makefile.build:500: drivers/base] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1799: drivers] Error 2
make: *** Waiting for unfinished jobs....

I suspect that since you are booting the kernel directly from my build 
box over tftp it accesses the ath10 firmware blobs on the build box.

[-- Attachment #1.1.2: OpenPGP_0x729CFF47A416598B.asc --]
[-- Type: application/pgp-keys, Size: 3163 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]