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]
Message-ID: <8f7bddf8-84de-27b5-26a3-d80b2e2f0097@linaro.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ