RE: [PATCH v2 1/3] dt-bindings: ath10k: Add wifi-firmware subnode for wifi node

[pillair]

Hi Rob,
Comments inline.

> -----Original Message-----
> From: Rob Herring <robh@xxxxxxxxxx>
> Sent: Wednesday, April 1, 2020 3:11 AM
> To: Rakesh Pillai <pillair@xxxxxxxxxxxxxx>
> Cc: ath10k@xxxxxxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v2 1/3] dt-bindings: ath10k: Add wifi-firmware subnode
> for wifi node
> 
> On Wed, Mar 25, 2020 at 04:31:38PM +0530, Rakesh Pillai wrote:
> > Add a wifi-firmware subnode for the wifi node.
> > This wifi-firmware subnode is needed for the
> > targets which do not support TrustZone.
> >
> > Signed-off-by: Rakesh Pillai <pillair@xxxxxxxxxxxxxx>
> > ---
> >  .../devicetree/bindings/net/wireless/qcom,ath10k.txt       | 14
> ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git
> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> > index 71bf91f..65ee68e 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> > @@ -96,6 +96,17 @@ Optional properties:
> >  - qcom,coexist-gpio-pin : gpio pin number  information to support coex
> >  			  which will be used by wifi firmware.
> >
> > +* Subnodes
> > +The ath10k wifi node can contain one optional firmware subnode.
> > +Firmware subnode is needed when the platform does not have TustZone.
> > +The firmware subnode must have:
> > +
> > +- iommus:
> > +	Usage: required
> > +	Value type: <prop-encoded-array>
> > +	Definition: A list of phandle and IOMMU specifier pairs.
> > +
> > +
> >  Example (to supply PCI based wifi block details):
> >
> >  In this example, the node is defined as child node of the PCI
controller.
> > @@ -196,4 +207,7 @@ wifi@18000000 {
> >  		memory-region = <&wifi_msa_mem>;
> >  		iommus = <&apps_smmu 0x0040 0x1>;
> >  		qcom,msa-fixed-perm;
> > +		wifi-firmware {
> > +			iommus = <&apps_iommu 0xc22 0x1>;
> 
> Why can't you just add a 2nd entry to the existing 'iommus' property?
> 
> A driver doing of_dma_configure() is generally not the right thing to
> do.

The SIDs mentioned in the wifi-firmware node will be belonging to the
firmware and not any HLOS.
In other targets with TZ, the hypervisor takes care of configuring the SIDs
(for its master).
In this target (sc7180 IDP) we are not having TZ (no hypervisor), hence
these need to be configured by HLOS.
The wifi-firmware node is added in-order to differentiate the SID between
driver and firmware.

This is same as the approach followed by Venus video driver in the below
patch
https://patchwork.kernel.org/patch/11315765/ 

> 
> Rob