linux-kernel - Re: [PATCH] arm64: dts: qcom: sa8540p-ride: correct name of remoteproc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Mar 2023 13:36:52 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Brian Masney <bmasney@...hat.com>
Cc:     andersson@...nel.org, quic_shazhuss@...cinc.com, agross@...nel.org,
        konrad.dybcio@...aro.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: qcom: sa8540p-ride: correct name of
 remoteproc_nsp0 firmware

On 08/03/2023 13:06, Brian Masney wrote:
> On Wed, Mar 08, 2023 at 12:02:04PM +0100, Krzysztof Kozlowski wrote:
>> On 08/03/2023 00:23, Brian Masney wrote:
>>> The cdsp.mbn firmware that's referenced in sa8540p-ride.dts is actually
>>> named cdsp0.mbn in the deliverables from Qualcomm. Let's go ahead and
>>> correct the name to match what's in Qualcomm's deliverable.
>>
>> I don't think vendor deliverables matter. linux-firmware is here more
>> important. The file will be cdsp.mbn in the firmware, won't it?
> 
> cdsp0.mbn and cdsp1.mbn for the sa8540p are not in linux-firmware and I
> far as I know there's no plan for someone to submit those since QC would
> need to approve that. I can ask though since the DTS for these two bits
> has been submitted upstream.

If they are never going to be submitted, vendor is allowed to rename
them all the time in their "deliverables". Are you going to rename the
file every time Qualcomm decides to rename them? There is no single
guarantee the names would be fixed, because vendor is allowed to do
absolutely anything.

Sorry, but any argument in upstream DTS that "someone downstream does
something" is deemed to fail in many cases.

Best regards,
Krzysztof