On Fri, 13 Sept 2024 at 18:37, Bjorn Andersson
<quic_bjorande@xxxxxxxxxxx> wrote:
>
> On Fri, Sep 13, 2024 at 07:12:58AM +0300, Dmitry Baryshkov wrote:
> > On Fri, 13 Sept 2024 at 05:48, Bjorn Andersson
> > <quic_bjorande@xxxxxxxxxxx> wrote:
> > >
> > > On Thu, Sep 12, 2024 at 12:24:57PM +0300, Dmitry Baryshkov wrote:
> > > > Hello,
> > > >
> > > > I'm planning to send the following pull request to linux-firmware, adding WiFi
> > > > DSP firmware for the RB3 Gen2 board. However before doing that I wanted to
> > > > check if it's fine with all affected maintainers.
> > > >
> > > > Qualcomm RB3 Gen2 board resets if it's used with the existing WCN6750 firmware,
> > > > most likely because of the differences in the TZ setup. This pull request adds
> > > > firmware specific to the qcm6490 / qcs6490 SoC family.
> > > >
> > >
> > > Given that this firmware runs on the SoC, isn't it device specific? Does
> > > it make sense to carry this under ath11k/, when it's expected to have
> > > the same form and distribution as the other remoteproc firmware?
> >
> > This is an interesting question. I think that having all WiFi-related
> > firmware under athNk makes sense. For example wlanmdsp.mbn files are
> > also stored under ath10k/WCN3990/ subdirs.
> > So do q6 and m3 firmware files under ath11k/IPQ*/.
> >
>
> I was under the impression that wlanmdsp.mbn (as being run in a
> protection domain) had lower security/signature requirements than the
> wpss.mbn.
>
> If wpss.mbn is not vendor-signed (in a real product...) then I have no
> concerns with keeping it under ath11k/
I think both are vendor-signed. On Pixel phones wlanmdsp.mbn is signed
with the Google certificates:
Certificate: C=US,STATEORPROVINCENAME=CA,L=Mountain View,O=Google\,
Inc.,OU=Android,CN=PixelRoot,EMAIL=android-cert@xxxxxxxxxx
Certificate: C=US,STATEORPROVINCENAME=CA,L=Mountain
View,OU=Android,O=Google Inc.,CN=Pixel2018CA
>
> > >
> > > >
> > > > @Kalle, I understand that you cannot and won't fully support this firmware set.
> > > > As a preparation to adding these files I moved existing files to the sc7280/
> > > > subdir and pil-squashed them. It is a generic preference to use a single MBN
> > > > file instead of MDT + Bnn files. The mdt_loader detects the format without
> > > > using the extension, handles the differences internally and doesn't require any
> > > > changes to the driver or to the DT. Could you please ack such a change?
> > > >
> > >
> > > I much prefer that we switch this to the single-file version, so I'm
> > > onboard with this.
> > >
> > > >
> > > > @Bjorn, @Konrad in the past we have pushed all WPSS / WiFi firmware to ath10k
> > > > and ath11k even if gets executed on the host. I should have caught this while
> > > > reviewing DT changes. This branch uses firmware name that isn't compatible
> > > > with the existing DT files. Would you insist on adding compatibility symlink
> > > > or we'd better fix the DT files?
> > > >
> > >
> > > I think we have a limited user base of sc7280-chrome-common, so we
> > > should be able to fix up the DeviceTree, and avoid the symlink.
> >
> > I think we should keep the ath11k/WCN6750/hw1.0/wpss.mdt symlink,
> > that's fine. I was talking about adding the qcom/qcm6490/wpss.mbn ->
> > ath11k/WCN6750/hw1.0/wpss.mbn and the same for qcs6490 (just for the
> > sake of existing DT files) or it's fine to fix the DT files instead
> > and omit the symlink.
> >
>
> Perhaps I'm mistaken, but does WiFi work on those boards today? I'm
> inclined to just have us fix up the DT and avoid sprinkling the symlinks
> all over the place.
>
>
> I guess this shows that I need to start holding back on future
> firmware-name entries until the linux-firmware structure is known.
Maybe just for the cases where we don't have established practice.
--
With best wishes
Dmitry
