public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Alexey Charkov <alchark@gmail.com>,
	Jacobe Zang <jacobe.zang@wesion.com>,
	robh@kernel.org, krzk+dt@kernel.org, heiko@sntech.de,
	kvalo@kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, conor+dt@kernel.org
Cc: efectn@protonmail.com, dsimic@manjaro.org, jagan@edgeble.ai,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	arend@broadcom.com, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, megi@xff.cz, duoming@zju.edu.cn,
	bhelgaas@google.com, minipli@grsecurity.net,
	brcm80211@lists.linux.dev, brcm80211-dev-list.pdl@broadcom.com,
	nick@khadas.com
Subject: Re: [PATCH v6 4/5] wifi: brcmfmac: Add optional lpo clock enable support
Date: Wed, 31 Jul 2024 13:14:58 +0200	[thread overview]
Message-ID: <3ded8aea-ee11-43da-9dd7-1259cf931747@broadcom.com> (raw)
In-Reply-To: <0a78a0fb-0a5e-424f-a801-4a63b9ee1a49@gmail.com>

On 7/31/2024 12:16 PM, Alexey Charkov wrote:
> Hi Jacobe,
> 
> 
> On 31/07/2024 9:11 am, Jacobe Zang wrote:
>  > WiFi modules often require 32kHz clock to function. Add support to
>  > enable the clock to PCIe driver and move "brcm,bcm4329-fmac" check
>  > to the top of brcmf_of_probe
>  >
>  > Co-developed-by: Ondrej Jirman <megi@xff.cz>
>  > Signed-off-by: Ondrej Jirman <megi@xff.cz>
>  > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>
>  > ---
>  >  .../net/wireless/broadcom/brcm80211/brcmfmac/of.c    | 12 +++++++++++-
>  >  1 file changed, 11 insertions(+), 1 deletion(-)
>  >
>  > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
>  > index e406e11481a62..7e0a2ad5c7c8a 100644
>  > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
>  > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
>  > @@ -6,6 +6,7 @@
>  >  #include <linux/of.h>
>  >  #include <linux/of_irq.h>
>  >  #include <linux/of_net.h>
>  > +#include <linux/clk.h>
>  >
>  >  #include <defs.h>
>  >  #include "debug.h"
>  > @@ -70,12 +71,16 @@ void brcmf_of_probe(struct device *dev, enum 
> brcmf_bus_type bus_type,
>  >  {
>  >      struct brcmfmac_sdio_pd *sdio = &settings->bus.sdio;
>  >      struct device_node *root, *np = dev->of_node;
>  > +    struct clk *clk;
>  >      const char *prop;
>  >      int irq;
>  >      int err;
>  >      u32 irqf;
>  >      u32 val;
>  >
>  > +    if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
>  > +        return;
> 
> Did you test this? The DTS patch you sent as part of this series doesn't 
> list "brcm,bcm4329-fmac" in the compatible, so this will probably return 
> right here, skipping over the rest of your patch.
> 
> Please test before resending, both with and without the driver for the 
> Bluetooth part of the chip (since it also touches clocks).
> 
> You are also changing the behavior for other systems by putting this 
> check further up the probe path, which might break things for no reason. 
> Better put your clk-related addition below where this check was 
> originally, rather than reorder stuff you don't have to reorder.

That was upon my suggestion. That check was originally at the top of the 
function, but people added stuff before that. I agree that makes the 
compatible "brcm,brcm4329-fmac" required which is what the textual 
binding stated before the switch to YAML was made:

"""
Broadcom BCM43xx Fullmac wireless SDIO devices

This node provides properties for controlling the Broadcom wireless 
device. The
node is expected to be specified as a child node to the SDIO controller that
connects the device to the system.

Required properties:

  - compatible : Should be "brcm,bcm4329-fmac".
"""

Not sure whether this is still true for YAML version (poor YAML reading 
skills ;-) ), but it should as the switch from textual to YAML should 
not have changed the bindings specification.

>  > +
>  >      /* Apple ARM64 platforms have their own idea of board type, 
> passed in
>  >       * via the device tree. They also have an antenna SKU parameter
>  >       */
>  > @@ -113,8 +118,13 @@ void brcmf_of_probe(struct device *dev, enum 
> brcmf_bus_type bus_type,
>  >          of_node_put(root);
>  >      }
>  >
>  > -    if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
>  > +    clk = devm_clk_get_optional_enabled(dev, "lpo");
>  > +    if (!IS_ERR_OR_NULL(clk)) {
>  > +        brcmf_dbg(INFO, "enabling 32kHz clock\n");
>  > +        clk_set_rate(clk, 32768);
>  > +    } else {
>  >          return;
> 
> Why return here? If the clock is optional, a lot of systems will not 
> have it - that shouldn't prevent the driver from probing. And you are 
> still not handling the -EPROBE_DEFER case which was mentioned on your 
> previous submission.

Right. The else statement above could/should be:

} else if (clk && PTR_ERR(clk) == -EPROBE_DEFER) {
         return PTR_ERR(clk);
}

Regards,
Arend

  reply	other threads:[~2024-07-31 11:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31  6:11 [PATCH v6 0/5] Add AP6275P wireless support Jacobe Zang
2024-07-31  6:11 ` [PATCH v6 1/5] dt-bindings: net: wireless: brcm4329-fmac: add pci14e4,449d Jacobe Zang
2024-07-31  6:11 ` [PATCH v6 2/5] dt-bindings: net: wireless: brcm4329-fmac: add clock description for AP6275P Jacobe Zang
2024-07-31  6:11 ` [PATCH v6 3/5] arm64: dts: rockchip: Add AP6275P wireless support to Khadas Edge 2 Jacobe Zang
2024-07-31  6:41   ` Arend Van Spriel
2024-07-31  6:11 ` [PATCH v6 4/5] wifi: brcmfmac: Add optional lpo clock enable support Jacobe Zang
2024-07-31 10:16   ` Alexey Charkov
2024-07-31 11:14     ` Arend van Spriel [this message]
2024-07-31 12:01       ` Alexey Charkov
2024-07-31 12:32         ` Arend van Spriel
2024-07-31 12:56           ` Alexey Charkov
2024-08-01  3:52             ` Jacobe Zang
2024-08-01  7:57               ` Alexey Charkov
2024-07-31  6:11 ` [PATCH v6 5/5] wifi: brcmfmac: add flag for random seed during firmware download Jacobe Zang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ded8aea-ee11-43da-9dd7-1259cf931747@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=alchark@gmail.com \
    --cc=arend@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211@lists.linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dsimic@manjaro.org \
    --cc=duoming@zju.edu.cn \
    --cc=edumazet@google.com \
    --cc=efectn@protonmail.com \
    --cc=heiko@sntech.de \
    --cc=jacobe.zang@wesion.com \
    --cc=jagan@edgeble.ai \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=megi@xff.cz \
    --cc=minipli@grsecurity.net \
    --cc=netdev@vger.kernel.org \
    --cc=nick@khadas.com \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox