arm64: dts: qcom: sm8350-mtp: Use mdt files for firmware

As discussed in [1], it makes it easy for everyone to use mdt firmware file name instead of mbn ones, so changes this for SM8350

[1]: http://lore.kernel.org/r/CALAqxLXn6wFBAxRkThxWg5RvTuFEX80kHPt8BVja1CpAB-qzGA@mail.gmail.com

Signed-off-by Vinod Koul <[email protected]>

---
 arch/arm64/boot/dts/qcom/sm8350-mtp.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm64/boot/dts/qcom/sm8350-mtp.dts +0 -0

index 93740444dd1e..d859305f1f75 100644

Quoted 17 lines · Vinod Koul

As discussed in [1], it makes it easy for everyone to use mdt firmware file name instead of mbn ones, so changes this for SM8350

[1]: http://lore.kernel.org/r/CALAqxLXn6wFBAxRkThxWg5RvTuFEX80kHPt8BVja1CpAB-qzGA@mail.gmail.com

Signed-off-by Vinod Koul <[email protected]>

---
 arch/arm64/boot/dts/qcom/sm8350-mtp.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm64/boot/dts/qcom/sm8350-mtp.dts +0 -0

index 93740444dd1e..d859305f1f75 100644
@@ -40,7 +40,7 @@ vph_pwr: vph-pwr-regulator {
 

arch/arm64/boot/dts/qcom/sm8350-mtp.dts vph_pwr: vph-pwr-regulator { · line 44

Quoted 5 lines

arch/arm64/boot/dts/qcom/sm8350-mtp.dts +1 -1

 &adsp {
        status = "okay";
-       firmware-name = "qcom/sm8350/adsp.mbn";
+       irmware-name = "qcom/sm8350/adsp.mdt";
 };

Uhh, isn't this the opposite of [1]? My apologies for butting in, and I'd stay out of the discussion, except for my mail being linked as justification :)

In [1] the case was db845c was switched from older mdt files to using the upstream linux-firmware mbn files. This was a bit of a pain, as it broke on our userland with mdt files, and since we use both old and new kernels we had to have both filenames on the disk (via symlink) to keep it working everywhere.

My argument in [1] was for new boards, go with the new conventions, but we should avoid breaking those conventions casually on existing devices. That said, I know it's more complex, and I graciously defer to Bjorn and RobC on the decision.

But your patch above seems to be switching from mbn (what I understand to be the new convention) to mdt (what I thought was the old way). And from the git blame, it looks like it was introduced as mbn (new board, new convention - so all good, right?).

So is this really the right change? Or maybe just more exposition in the commit message is needed (rather than pointing to my mail, which seems to be arguing the opposite) to explain it?

Quoted 18 lines · John Stultz

Quoted 17 lines · Vinod Koul

As discussed in [1], it makes it easy for everyone to use mdt firmware file name instead of mbn ones, so changes this for SM8350

[1]: http://lore.kernel.org/r/CALAqxLXn6wFBAxRkThxWg5RvTuFEX80kHPt8BVja1CpAB-qzGA@mail.gmail.com

Signed-off-by Vinod Koul <[email protected]>

---
 arch/arm64/boot/dts/qcom/sm8350-mtp.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm64/boot/dts/qcom/sm8350-mtp.dts +0 -0

index 93740444dd1e..d859305f1f75 100644
@@ -40,7 +40,7 @@ vph_pwr: vph-pwr-regulator {
 

Quoted 9 lines

arch/arm64/boot/dts/qcom/sm8350-mtp.dts vph_pwr: vph-pwr-regulator { · line 44

Quoted 5 lines

arch/arm64/boot/dts/qcom/sm8350-mtp.dts +1 -1

 &adsp {
        status = "okay";
-       firmware-name = "qcom/sm8350/adsp.mbn";
+       irmware-name = "qcom/sm8350/adsp.mdt";
 };

Uhh, isn't this the opposite of [1]? My apologies for butting in, and I'd stay out of the discussion, except for my mail being linked as justification :)

I would rather think of your email as background material or trigger :)

Quoted 11 lines

In [1] the case was db845c was switched from older mdt files to using the upstream linux-firmware mbn files. This was a bit of a pain, as it broke on our userland with mdt files, and since we use both old and new kernels we had to have both filenames on the disk (via symlink) to keep it working everywhere.

My argument in [1] was for new boards, go with the new conventions, but we should avoid breaking those conventions casually on existing devices. That said, I know it's more complex, and I graciously defer to Bjorn and RobC on the decision.

Quoted 8 lines

But your patch above seems to be switching from mbn (what I understand to be the new convention) to mdt (what I thought was the old way). And from the git blame, it looks like it was introduced as mbn (new board, new convention - so all good, right?).

So is this really the right change? Or maybe just more exposition in the commit message is needed (rather than pointing to my mail, which seems to be arguing the opposite) to explain it?

We have had a discussion after the email thread and thought it is better approach to stick to mdt format as used downstream and not have confusion and issues resulting from upstream vs downstream

Since SM8350 is a new platform, so switching here onwards made sense, hence this patch

I should have added more details for this in changelog as well...