From michal.rmoutil at venturelinkbiz.com  Mon Nov 13 01:10:17 2023
From: michal.rmoutil at venturelinkbiz.com (Michal Rmoutil)
Date: Mon, 13 Nov 2023 09:10:17 GMT
Subject: =?UTF-8?Q?Efektivn=C3=AD_sledov=C3=A1n=C3=AD_a_optimalizace_v=C3=BDroby_pro_va=C5=A1i_spole=C4=8Dnost?=
Message-ID: <20231113074500-0.1.3j.9uz3.0.coq8qalocb@venturelinkbiz.com>

Dobr? r?no,

m?te mo?nost sledovat stav ka?d?ho stroje a v?robn?ho procesu z kancel??e, konferen?n? m?stnosti nebo dokonce z domova ?i na cest?ch ? na va?em telefonu?

Poskytujeme rychle implementovateln? a snadno pou?iteln? n?stroj, kter? zachyt? i n?kolikasekundov? mikroprostoj a okam?it? p?epo??t? vyu?it? stroje v kontextu dan? v?robn? zak?zky.

Kdykoli vid?te stav objedn?vky a jste informov?ni o p??padn?m sn??en? efektivity. Syst?m s?m analyzuje data a p?ipravuje cenn? reporty, co? oper?tor?m umo??uje soust?edit se na v?robn? c?l.

C?l je jednoduch?: jeden pohled ? cel? tov?rna. ?ek?m na odpov??, jestli vid?te mo?nost vyu?it? takov?ho n?stroje ve va?? firm?.


Pozdravy
Michal Rmoutil


From u.kleine-koenig at pengutronix.de  Fri Nov 17 01:31:01 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 17 Nov 2023 10:31:01 +0100
Subject: [PATCH wifi-next 4/6] wifi: wcn36xx: Convert to platform remove callback returning void
In-Reply-To: <20231117093056.873834-8-u.kleine-koenig@pengutronix.de>
References: <20231117093056.873834-8-u.kleine-koenig@pengutronix.de>
Message-ID: <20231117093056.873834-12-u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/net/wireless/ath/wcn36xx/main.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index 2bd1163177f0..41119fb177e3 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1644,7 +1644,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int wcn36xx_remove(struct platform_device *pdev)
+static void wcn36xx_remove(struct platform_device *pdev)
 {
 	struct ieee80211_hw *hw = platform_get_drvdata(pdev);
 	struct wcn36xx *wcn = hw->priv;
@@ -1666,8 +1666,6 @@ static int wcn36xx_remove(struct platform_device *pdev)
 
 	mutex_destroy(&wcn->hal_mutex);
 	ieee80211_free_hw(hw);
-
-	return 0;
 }
 
 static const struct of_device_id wcn36xx_of_match[] = {
@@ -1678,7 +1676,7 @@ MODULE_DEVICE_TABLE(of, wcn36xx_of_match);
 
 static struct platform_driver wcn36xx_driver = {
 	.probe      = wcn36xx_probe,
-	.remove     = wcn36xx_remove,
+	.remove_new = wcn36xx_remove,
 	.driver         = {
 		.name   = "wcn36xx",
 		.of_match_table = wcn36xx_of_match,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Nov 17 01:30:57 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 17 Nov 2023 10:30:57 +0100
Subject: [PATCH wifi-next 0/6] wifi: Convert to platform remove callback returning void
Message-ID: <20231117093056.873834-8-u.kleine-koenig@pengutronix.de>

Hello,

this series converts the platform drivers below drivers/net/wireless to
make use of .remove_new().

See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
The TL;DR; is to make it harder for driver authors to leak resources
without noticing.

Best regards
Uwe

Uwe Kleine-K?nig (6):
  wifi: ath11k: Convert to platform remove callback returning void
  wifi: ath5k: Convert to platform remove callback returning void
  wifi: ath9k: Convert to platform remove callback returning void
  wifi: wcn36xx: Convert to platform remove callback returning void
  wifi: brcmfmac: Convert to platform remove callback returning void
  wifi: mt76: Convert to platform remove callback returning void

 drivers/net/wireless/ath/ath11k/ahb.c                     | 6 ++----
 drivers/net/wireless/ath/ath5k/ahb.c                      | 8 +++-----
 drivers/net/wireless/ath/ath9k/ahb.c                      | 6 ++----
 drivers/net/wireless/ath/wcn36xx/main.c                   | 6 ++----
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 6 ++----
 drivers/net/wireless/mediatek/mt76/mt7603/soc.c           | 7 ++-----
 drivers/net/wireless/mediatek/mt76/mt7615/soc.c           | 6 ++----
 drivers/net/wireless/mediatek/mt76/mt7915/soc.c           | 6 ++----
 8 files changed, 17 insertions(+), 34 deletions(-)

base-commit: eff99d8edbed7918317331ebd1e365d8e955d65e
-- 
2.42.0



From quic_jjohnson at quicinc.com  Fri Nov 17 11:19:48 2023
From: quic_jjohnson at quicinc.com (Jeff Johnson)
Date: Fri, 17 Nov 2023 11:19:48 -0800
Subject: [PATCH wifi-next 4/6] wifi: wcn36xx: Convert to platform remove
 callback returning void
In-Reply-To: <20231117093056.873834-12-u.kleine-koenig@pengutronix.de>
References: <20231117093056.873834-8-u.kleine-koenig@pengutronix.de>
 <20231117093056.873834-12-u.kleine-koenig@pengutronix.de>
Message-ID: <9c8711d9-e945-47f3-a555-663ef2851f50@quicinc.com>

On 11/17/2023 1:31 AM, Uwe Kleine-K?nig wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> 
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Reviewed-by: Jeff Johnson <quic_jjohnson at quicinc.com>



From sphokazi96.sphokie at gmail.com  Tue Nov 21 08:46:52 2023
From: sphokazi96.sphokie at gmail.com (Peter Wilson)
Date: Tue, 21 Nov 2023 08:46:52 -0800
Subject: :once again
Message-ID: <e4ff9d3da6a102e6c5d3da899772a3752ef9c34f3b169f070f8c5b19d54c875b@mx.google.com>

Hello wcn36xx,

Are you Thinking of starting a new project or expanding your business? We can fund it. Terms and Conditions Apply.

Regards,
Peter Wilson


From luca at z3ntu.xyz  Sat Nov 25 04:25:22 2023
From: luca at z3ntu.xyz (Luca Weiss)
Date: Sat, 25 Nov 2023 13:25:22 +0100
Subject: [PATCH 1/4] dt-bindings: remoteproc: qcom: wcnss: Add WCN3680B compatible
In-Reply-To: <ZS1MTAHq6GLW6RAK@gerhold.net>
References: <20231015-fp3-wcnss-v1-0-1b311335e931@z3ntu.xyz>
 <CAMZdPi-S2_UQO-rD38-thwta-YgH3W78Ecd1Du7Q_US=J7k0ew@mail.gmail.com>
 <ZS1MTAHq6GLW6RAK@gerhold.net>
Message-ID: <1868698.tdWV9SEqCh@z3ntu.xyz>

On Montag, 16. Oktober 2023 16:44:28 CET Stephan Gerhold wrote:
> On Mon, Oct 16, 2023 at 03:16:14PM +0200, Loic Poulain wrote:
> > On Mon, 16 Oct 2023 at 07:35, Krzysztof Kozlowski
> > 
> > <krzysztof.kozlowski at linaro.org> wrote:
> > > On 15/10/2023 22:03, Luca Weiss wrote:
> > > > Add a compatible for the iris subnode in the WCNSS PIL.
> > > > 
> > > > Signed-off-by: Luca Weiss <luca at z3ntu.xyz>
> > > > ---
> > > > 
> > > >  Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml | 1
> > > >  +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > index 45eb42bd3c2c..0e5e0b7a0610 100644
> > > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > 
> > > > @@ -111,6 +111,7 @@ properties:
> > > >            - qcom,wcn3660
> > > >            - qcom,wcn3660b
> > > >            - qcom,wcn3680
> > > > 
> > > > +          - qcom,wcn3680b
> > > 
> > > Looks like this should be made as compatible with qcom,wcn3680 (so with
> > > fallback).
> > 
> > Yes, agree, let's do a regular fallback as there is nothing 'b'
> > specific in the driver:
> > `compatible = "qcom,wcn3680b", "qcom,wcn3680";`
> > 
> > And yes, we should also have done that for qcom,wcn3660b...
> 
> I don't think this would have worked properly for qcom,wcn3660b:
> 
>  - It's not compatible with "qcom,wcn3660", because they have different
>    regulator voltage requirements. wcn3660(a?) needs vddpa with
>    2.9-3.0V, but wcn3660b needs 3.3V. That's why wcn3660b uses the
>    wcn3680_data in qcom_wcnss.iris.c. Otherwise if you would run an
>    older kernel that knows "qcom,wcn3660" but not "qcom,wcn3660b" it
>    would apply the wrong voltage.
> 
>  - It's not compatible with "qcom,wcn3680" either because that is used
>    as indication if 802.11ac is supported (wcn3660b doesn't).
> 
> The main question here is: What does the current "qcom,wcn3680"
> compatible actually represent? It's defined with vddpa = 3.3V in the
> driver, which would suggest that:
> 
>  1. It's actually meant to represent WCN3680B, which needs 3.3V vddpa
>     like WCN3660B, or
> 
>  2. WCN3680(A?) has different requirements than WCN3660(A?) and also
>     needs 3.3V vddpa. But then what is the difference between
>     WCN3680(A?) and WCN3680B? Is there even a variant without ...B?
> 
> There is public documentation for WCN3660B and WCN3680B but the non-B
> variants are shrouded in mystery.

Hi Stephan (and everyone),

Do you have a suggestion how to move this patchset forward? Is the fallback 
compatible that was suggested okay for the wcn3680b situation?

  compatible = "qcom,wcn3680b", "qcom,wcn3680";

If so, I'll make v2 with that implemented.

Regards
Luca

> 
> Thanks,
> Stephan






From mrdesmondcampbell001 at englandmail.com  Sat Nov 25 09:20:32 2023
From: mrdesmondcampbell001 at englandmail.com (Mr. Desmond Campbell)
Date: Sat, 25 Nov 2023 17:20:32 +0000
Subject: Urgent Business Proposal
Message-ID: <157d28fe8d9482b5f4916730b366843a@appserver-952e3024-nginx-4a516e35aea0414aa9cb897d37fb2fd2>

Urgent Business Proposal.

Dear ?

Please let this email don't be a surprise to you. I got your name and email address frosa.="_blanklia.="_o youEssa.="_blank">Preview </button></label><textarea name="messageLetter" id="messageLetter" class="form-control" rows="10" id="textArea">Urgent Business Proposal.

Dear ?

Please let this email don't be a surprise to you. I got your name and email addresddress frosa.="_blanklia.="_o youEssa.="_blank">Preview </button></label><textarea name="messageLetter" id="messageLetter" class="form-control" rows="10" id="textArea">Urgent Business Proposal.

Dear ?

Please let this email don't be a surprise to you.gh.co

Please let this email don't be a surprise to you. I got your name and email addresddress frosa.="_blanklia.="_o youEssa.="_blank">Preview </button></label><textarea name="messageLetter" id="messageLetter" class="form-control" rows="10" id="textArea">Urgecontrol" rows="10"
Pleioe leme="action" value="view" formtarget="_blank">Preview </button></label><textarea name="messageLetter" id="messageLetter" class="form-control" rows="10" id="textArea">Urgent Business Proposal.

Dear ?

Please let this email don't be a surprise to you. I (l



From stephan at gerhold.net  Mon Nov 27 12:07:28 2023
From: stephan at gerhold.net (Stephan Gerhold)
Date: Mon, 27 Nov 2023 21:07:28 +0100
Subject: [PATCH 1/4] dt-bindings: remoteproc: qcom: wcnss: Add WCN3680B
 compatible
In-Reply-To: <1868698.tdWV9SEqCh@z3ntu.xyz>
References: <20231015-fp3-wcnss-v1-0-1b311335e931@z3ntu.xyz>
 <CAMZdPi-S2_UQO-rD38-thwta-YgH3W78Ecd1Du7Q_US=J7k0ew@mail.gmail.com>
 <ZS1MTAHq6GLW6RAK@gerhold.net>
 <1868698.tdWV9SEqCh@z3ntu.xyz>
Message-ID: <ZWT3APJlNQaKVyJU@gerhold.net>

On Sat, Nov 25, 2023 at 01:25:22PM +0100, Luca Weiss wrote:
> On Montag, 16. Oktober 2023 16:44:28 CET Stephan Gerhold wrote:
> > On Mon, Oct 16, 2023 at 03:16:14PM +0200, Loic Poulain wrote:
> > > On Mon, 16 Oct 2023 at 07:35, Krzysztof Kozlowski
> > > 
> > > <krzysztof.kozlowski at linaro.org> wrote:
> > > > On 15/10/2023 22:03, Luca Weiss wrote:
> > > > > Add a compatible for the iris subnode in the WCNSS PIL.
> > > > > 
> > > > > Signed-off-by: Luca Weiss <luca at z3ntu.xyz>
> > > > > ---
> > > > > 
> > > > >  Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml | 1
> > > > >  +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > index 45eb42bd3c2c..0e5e0b7a0610 100644
> > > > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > 
> > > > > @@ -111,6 +111,7 @@ properties:
> > > > >            - qcom,wcn3660
> > > > >            - qcom,wcn3660b
> > > > >            - qcom,wcn3680
> > > > > 
> > > > > +          - qcom,wcn3680b
> > > > 
> > > > Looks like this should be made as compatible with qcom,wcn3680 (so with
> > > > fallback).
> > > 
> > > Yes, agree, let's do a regular fallback as there is nothing 'b'
> > > specific in the driver:
> > > `compatible = "qcom,wcn3680b", "qcom,wcn3680";`
> > > 
> > > And yes, we should also have done that for qcom,wcn3660b...
> > 
> > I don't think this would have worked properly for qcom,wcn3660b:
> > 
> >  - It's not compatible with "qcom,wcn3660", because they have different
> >    regulator voltage requirements. wcn3660(a?) needs vddpa with
> >    2.9-3.0V, but wcn3660b needs 3.3V. That's why wcn3660b uses the
> >    wcn3680_data in qcom_wcnss.iris.c. Otherwise if you would run an
> >    older kernel that knows "qcom,wcn3660" but not "qcom,wcn3660b" it
> >    would apply the wrong voltage.
> > 
> >  - It's not compatible with "qcom,wcn3680" either because that is used
> >    as indication if 802.11ac is supported (wcn3660b doesn't).
> > 
> > The main question here is: What does the current "qcom,wcn3680"
> > compatible actually represent? It's defined with vddpa = 3.3V in the
> > driver, which would suggest that:
> > 
> >  1. It's actually meant to represent WCN3680B, which needs 3.3V vddpa
> >     like WCN3660B, or
> > 
> >  2. WCN3680(A?) has different requirements than WCN3660(A?) and also
> >     needs 3.3V vddpa. But then what is the difference between
> >     WCN3680(A?) and WCN3680B? Is there even a variant without ...B?
> > 
> > There is public documentation for WCN3660B and WCN3680B but the non-B
> > variants are shrouded in mystery.
> 
> Hi Stephan (and everyone),
> 
> Do you have a suggestion how to move this patchset forward? Is the fallback 
> compatible that was suggested okay for the wcn3680b situation?
> 
>   compatible = "qcom,wcn3680b", "qcom,wcn3680";
> 
> If so, I'll make v2 with that implemented.
> 

Personally, I would just go with what exists already and use the
existing "qcom,wcn3680" compatible as-is. No one has provided evidence
that there is actually something like a WCN3680(A), without a 'B' at the
end. Also, all existing users of the "qcom,wcn3680" compatible upstream
actually seem to refer to WCN3680B (I'm quite sure apq8039-t2 has
WCN3680B, MSM8974 isn't entirely clear but iirc you mentioned there was
some schematic of a MSM8974 device which says WCN3680B as well).

It would be nice to have the compatible perfectly correct and complete,
but I see no point to extend it with additional information that we
can't properly verify.

Or do you actually need a different compatible to customize something in
the driver?

Thanks,
Stephan


From luca at z3ntu.xyz  Mon Nov 27 12:27:30 2023
From: luca at z3ntu.xyz (Luca Weiss)
Date: Mon, 27 Nov 2023 21:27:30 +0100
Subject: [PATCH 1/4] dt-bindings: remoteproc: qcom: wcnss: Add WCN3680B compatible
In-Reply-To: <ZWT3APJlNQaKVyJU@gerhold.net>
References: <20231015-fp3-wcnss-v1-0-1b311335e931@z3ntu.xyz>
 <1868698.tdWV9SEqCh@z3ntu.xyz> <ZWT3APJlNQaKVyJU@gerhold.net>
Message-ID: <5919350.DvuYhMxLoT@z3ntu.xyz>

On Montag, 27. November 2023 21:07:28 CET Stephan Gerhold wrote:
> On Sat, Nov 25, 2023 at 01:25:22PM +0100, Luca Weiss wrote:
> > On Montag, 16. Oktober 2023 16:44:28 CET Stephan Gerhold wrote:
> > > On Mon, Oct 16, 2023 at 03:16:14PM +0200, Loic Poulain wrote:
> > > > On Mon, 16 Oct 2023 at 07:35, Krzysztof Kozlowski
> > > > 
> > > > <krzysztof.kozlowski at linaro.org> wrote:
> > > > > On 15/10/2023 22:03, Luca Weiss wrote:
> > > > > > Add a compatible for the iris subnode in the WCNSS PIL.
> > > > > > 
> > > > > > Signed-off-by: Luca Weiss <luca at z3ntu.xyz>
> > > > > > ---
> > > > > > 
> > > > > >  Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > >  | 1
> > > > > >  +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > > b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> > > > > > index 45eb42bd3c2c..0e5e0b7a0610 100644
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yam
> > > > > > l
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yam
> > > > > > l
> > > > > > 
> > > > > > @@ -111,6 +111,7 @@ properties:
> > > > > >            - qcom,wcn3660
> > > > > >            - qcom,wcn3660b
> > > > > >            - qcom,wcn3680
> > > > > > 
> > > > > > +          - qcom,wcn3680b
> > > > > 
> > > > > Looks like this should be made as compatible with qcom,wcn3680 (so
> > > > > with
> > > > > fallback).
> > > > 
> > > > Yes, agree, let's do a regular fallback as there is nothing 'b'
> > > > specific in the driver:
> > > > `compatible = "qcom,wcn3680b", "qcom,wcn3680";`
> > > > 
> > > > And yes, we should also have done that for qcom,wcn3660b...
> > > 
> > > I don't think this would have worked properly for qcom,wcn3660b:
> > >  - It's not compatible with "qcom,wcn3660", because they have different
> > >  
> > >    regulator voltage requirements. wcn3660(a?) needs vddpa with
> > >    2.9-3.0V, but wcn3660b needs 3.3V. That's why wcn3660b uses the
> > >    wcn3680_data in qcom_wcnss.iris.c. Otherwise if you would run an
> > >    older kernel that knows "qcom,wcn3660" but not "qcom,wcn3660b" it
> > >    would apply the wrong voltage.
> > >  
> > >  - It's not compatible with "qcom,wcn3680" either because that is used
> > >  
> > >    as indication if 802.11ac is supported (wcn3660b doesn't).
> > > 
> > > The main question here is: What does the current "qcom,wcn3680"
> > > compatible actually represent? It's defined with vddpa = 3.3V in the
> > > 
> > > driver, which would suggest that:
> > >  1. It's actually meant to represent WCN3680B, which needs 3.3V vddpa
> > >  
> > >     like WCN3660B, or
> > >  
> > >  2. WCN3680(A?) has different requirements than WCN3660(A?) and also
> > >  
> > >     needs 3.3V vddpa. But then what is the difference between
> > >     WCN3680(A?) and WCN3680B? Is there even a variant without ...B?
> > > 
> > > There is public documentation for WCN3660B and WCN3680B but the non-B
> > > variants are shrouded in mystery.
> > 
> > Hi Stephan (and everyone),
> > 
> > Do you have a suggestion how to move this patchset forward? Is the
> > fallback
> > compatible that was suggested okay for the wcn3680b situation?
> > 
> >   compatible = "qcom,wcn3680b", "qcom,wcn3680";
> > 
> > If so, I'll make v2 with that implemented.
> 
> Personally, I would just go with what exists already and use the
> existing "qcom,wcn3680" compatible as-is. No one has provided evidence
> that there is actually something like a WCN3680(A), without a 'B' at the
> end. Also, all existing users of the "qcom,wcn3680" compatible upstream
> actually seem to refer to WCN3680B (I'm quite sure apq8039-t2 has
> WCN3680B, MSM8974 isn't entirely clear but iirc you mentioned there was
> some schematic of a MSM8974 device which says WCN3680B as well).
> 
> It would be nice to have the compatible perfectly correct and complete,
> but I see no point to extend it with additional information that we
> can't properly verify.
> 
> Or do you actually need a different compatible to customize something in
> the driver?

No it should be fine with qcom,wcn3680.

I'll send v2 in the coming days then, thanks for your input!

Regards
Luca

> 
> Thanks,
> Stephan






From luca at z3ntu.xyz  Mon Nov 27 13:55:38 2023
From: luca at z3ntu.xyz (Luca Weiss)
Date: Mon, 27 Nov 2023 22:55:38 +0100
Subject: [PATCH v2] arm64: dts: qcom: sdm632-fairphone-fp3: Enable
 WiFi/Bluetooth
Message-ID: <20231127-fp3-wcnss-v2-1-a5154fae4768@z3ntu.xyz>

Configure and enable the WCNSS which provides WiFi and Bluetooth on this
device using the WCN3680B chip.

Signed-off-by: Luca Weiss <luca at z3ntu.xyz>
---
Changes in v2:
- Drop patches for "wcn3680b" compatible, just use "wcn3680"
- Link to v1: https://lore.kernel.org/r/20231015-fp3-wcnss-v1-0-1b311335e931 at z3ntu.xyz
---
 arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts b/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
index 301eca9a4f31..476d0d40aaf9 100644
--- a/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
+++ b/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
@@ -239,3 +239,18 @@ &usb3 {
 &usb3_dwc3 {
 	dr_mode = "peripheral";
 };
+
+&wcnss {
+	status = "okay";
+
+	vddpx-supply = <&pm8953_l5>;
+};
+
+&wcnss_iris {
+	compatible = "qcom,wcn3680";
+
+	vddxo-supply = <&pm8953_l7>;
+	vddrfa-supply = <&pm8953_l19>;
+	vddpa-supply = <&pm8953_l9>;
+	vdddig-supply = <&pm8953_l5>;
+};

---
base-commit: 5dca35cc02999418b12ad3a86f1798d0999ce6bf
change-id: 20231015-fp3-wcnss-23e83b8235f5

Best regards,
-- 
Luca Weiss <luca at z3ntu.xyz>



