All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Jacobe Zang <jacobe.zang@wesion.com>,
	"arend.vanspriel@broadcom.com" <arend.vanspriel@broadcom.com>
Cc: "kvalo@kernel.org" <kvalo@kernel.org>,
	"duoming@zju.edu.cn" <duoming@zju.edu.cn>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"minipli@grsecurity.net" <minipli@grsecurity.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"brcm80211@lists.linux.dev" <brcm80211@lists.linux.dev>,
	"brcm80211-dev-list.pdl@broadcom.com"
	<brcm80211-dev-list.pdl@broadcom.com>,
	"megi@xff.cz" <megi@xff.cz>, "robh@kernel.org" <robh@kernel.org>,
	"efectn@protonmail.com" <efectn@protonmail.com>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"heiko@sntech.de" <heiko@sntech.de>, Nick Xie <nick@khadas.com>,
	"jagan@edgeble.ai" <jagan@edgeble.ai>,
	"dsimic@manjaro.org" <dsimic@manjaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-rockchip@lists.infradead.org"
	<linux-rockchip@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] arm64: dts: rockchip: Add AP6275P wireless support to Khadas Edge 2
Date: Mon, 1 Jul 2024 10:41:30 +0200	[thread overview]
Message-ID: <3fe026a2-a8d6-4688-863f-1237e71945ea@kernel.org> (raw)
In-Reply-To: <TYZPR03MB7001D4DE507C919802B2F7F380D52@TYZPR03MB7001.apcprd03.prod.outlook.com>

On 25/06/2024 10:04, Jacobe Zang wrote:
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
>>> index 3b6286461a746..f674deb6f7da8 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
>>> @@ -356,6 +356,22 @@ &pcie2x1l2 {
>>>         reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>>>         vpcie3v3-supply = <&vcc3v3_pcie_wl>;
>>>         status = "okay";
>>> +
>>> +     pcie@0,0 {
>>> +             reg = <0x400000 0 0 0 0>;
>>> +             #address-cells = <3>;
>>> +             #size-cells = <2>;
>>> +             ranges;
>>> +             device_type = "pci";
>>> +             bus-range = <0x40 0x4f>;
>>
>> Isn't bus-range a property of PCI host bridge, so the parent? This is a
>> PCI device, right?
>>
>>> +
>>> +             wifi: wifi@0,0 {
>>
>> Binding does not say anything about this. Rockchip PCI controller is the
>> PCI host bridge, isn't it? Then the pci@0,0 is the child, so what is this?
> 
> The host bridge is the parent of pcie@0,0. And pcie@0,0 is Bridge1, so the

Do you want to say Rockchip PCI is PCI-PCI bridge? Bindings do not allow it.

> wifi@0,0 as a device under the Bridge1.
> 
>>
>>> +                     reg = <0x410000 0 0 0 0>;
>>> +                     clocks = <&hym8563>;
>>> +                     clock-names = "32k";
>>
>> 1. Bindings are before the users.
>> 2. Where is the compatible? Are you sure this validates?
> 
> Before, the compatible is "pci14e4,449d", but when I checkpatch the warning
> said that "pci14e4" was not documented, so I remove the compatible which 
> doesn't affect the Wi-Fi function. I have tried to add "pci14e4" to 
> vendor-prefixes.yaml but was refused. So whether should I add the compatible 
> with warning? 

I talk about dtbs_check, not checkpatch. That checkpatch warning does
not matter, obviously.

Best regards,
Krzysztof


WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Jacobe Zang <jacobe.zang@wesion.com>,
	"arend.vanspriel@broadcom.com" <arend.vanspriel@broadcom.com>
Cc: "kvalo@kernel.org" <kvalo@kernel.org>,
	"duoming@zju.edu.cn" <duoming@zju.edu.cn>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"minipli@grsecurity.net" <minipli@grsecurity.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"brcm80211@lists.linux.dev" <brcm80211@lists.linux.dev>,
	"brcm80211-dev-list.pdl@broadcom.com"
	<brcm80211-dev-list.pdl@broadcom.com>,
	"megi@xff.cz" <megi@xff.cz>, "robh@kernel.org" <robh@kernel.org>,
	"efectn@protonmail.com" <efectn@protonmail.com>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"heiko@sntech.de" <heiko@sntech.de>, Nick Xie <nick@khadas.com>,
	"jagan@edgeble.ai" <jagan@edgeble.ai>,
	"dsimic@manjaro.org" <dsimic@manjaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-rockchip@lists.infradead.org"
	<linux-rockchip@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] arm64: dts: rockchip: Add AP6275P wireless support to Khadas Edge 2
Date: Mon, 1 Jul 2024 10:41:30 +0200	[thread overview]
Message-ID: <3fe026a2-a8d6-4688-863f-1237e71945ea@kernel.org> (raw)
In-Reply-To: <TYZPR03MB7001D4DE507C919802B2F7F380D52@TYZPR03MB7001.apcprd03.prod.outlook.com>

On 25/06/2024 10:04, Jacobe Zang wrote:
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
>>> index 3b6286461a746..f674deb6f7da8 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
>>> @@ -356,6 +356,22 @@ &pcie2x1l2 {
>>>         reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>>>         vpcie3v3-supply = <&vcc3v3_pcie_wl>;
>>>         status = "okay";
>>> +
>>> +     pcie@0,0 {
>>> +             reg = <0x400000 0 0 0 0>;
>>> +             #address-cells = <3>;
>>> +             #size-cells = <2>;
>>> +             ranges;
>>> +             device_type = "pci";
>>> +             bus-range = <0x40 0x4f>;
>>
>> Isn't bus-range a property of PCI host bridge, so the parent? This is a
>> PCI device, right?
>>
>>> +
>>> +             wifi: wifi@0,0 {
>>
>> Binding does not say anything about this. Rockchip PCI controller is the
>> PCI host bridge, isn't it? Then the pci@0,0 is the child, so what is this?
> 
> The host bridge is the parent of pcie@0,0. And pcie@0,0 is Bridge1, so the

Do you want to say Rockchip PCI is PCI-PCI bridge? Bindings do not allow it.

> wifi@0,0 as a device under the Bridge1.
> 
>>
>>> +                     reg = <0x410000 0 0 0 0>;
>>> +                     clocks = <&hym8563>;
>>> +                     clock-names = "32k";
>>
>> 1. Bindings are before the users.
>> 2. Where is the compatible? Are you sure this validates?
> 
> Before, the compatible is "pci14e4,449d", but when I checkpatch the warning
> said that "pci14e4" was not documented, so I remove the compatible which 
> doesn't affect the Wi-Fi function. I have tried to add "pci14e4" to 
> vendor-prefixes.yaml but was refused. So whether should I add the compatible 
> with warning? 

I talk about dtbs_check, not checkpatch. That checkpatch warning does
not matter, obviously.

Best regards,
Krzysztof


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2024-07-01  8:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-24  8:19 [PATCH v2 0/5] Add AP6275P wireless support Jacobe Zang
2024-06-24  8:19 ` Jacobe Zang
2024-06-24  8:19 ` [PATCH v2 1/5] arm64: dts: rockchip: Add AP6275P wireless support to Khadas Edge 2 Jacobe Zang
2024-06-24  8:19   ` Jacobe Zang
2024-06-24 11:52   ` Krzysztof Kozlowski
2024-06-24 11:52     ` Krzysztof Kozlowski
2024-06-25  8:04     ` Jacobe Zang
2024-06-25  8:04       ` Jacobe Zang
2024-07-01  8:41       ` Krzysztof Kozlowski [this message]
2024-07-01  8:41         ` Krzysztof Kozlowski
2024-06-24  8:19 ` [PATCH v2 2/5] net: wireless: brcmfmac: Add optional 32k clock enable support Jacobe Zang
2024-06-24  8:19   ` Jacobe Zang
2024-06-24 12:31   ` Kalle Valo
2024-06-24 12:31     ` Kalle Valo
2024-06-24  8:19 ` [PATCH v2 3/5] net: wireless: brcmfmac: Add support for AP6275P Jacobe Zang
2024-06-24  8:19   ` Jacobe Zang
2024-06-24  8:19 ` [PATCH v2 4/5] dt-bindings: net: wireless: brcm4329-fmac: add clock description Jacobe Zang
2024-06-24  8:19   ` Jacobe Zang
2024-06-24  8:59   ` Arend van Spriel
2024-06-24  8:59     ` Arend van Spriel
2024-06-24  9:04     ` Jacobe Zang
2024-06-24  9:04       ` Jacobe Zang
2024-06-24 11:45   ` Krzysztof Kozlowski
2024-06-24 11:45     ` Krzysztof Kozlowski
2024-06-24  8:19 ` [PATCH v2 5/5] dt-bindings: net: wireless: brcm4329-fmac: add pci14e4,449d Jacobe Zang
2024-06-24  8:19   ` Jacobe Zang
2024-06-25 18:23   ` Arend Van Spriel
2024-06-25 18:23     ` Arend Van Spriel
2024-06-26  6:28     ` Kalle Valo
2024-06-26  6:28       ` Kalle Valo

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=3fe026a2-a8d6-4688-863f-1237e71945ea@kernel.org \
    --to=krzk@kernel.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211@lists.linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dsimic@manjaro.org \
    --cc=duoming@zju.edu.cn \
    --cc=efectn@protonmail.com \
    --cc=heiko@sntech.de \
    --cc=jacobe.zang@wesion.com \
    --cc=jagan@edgeble.ai \
    --cc=krzk+dt@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=nick@khadas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.