* Re: [Patch v2 1/2] dt-bindings: make sid and broadcast reg optional
From: Jon Hunter @ 2024-04-02 19:15 UTC (permalink / raw)
To: Sumit Gupta, krzysztof.kozlowski, robh, conor+dt, maz,
mark.rutland, treding
Cc: devicetree, linux-kernel, linux-tegra, amhetre, bbasu
In-Reply-To: <20240402132626.24693-2-sumitg@nvidia.com>
On 02/04/2024 14:26, Sumit Gupta wrote:
> MC SID and Broadbast channel register access is restricted for Guest VM.
> Make both the regions as optional for SoC's from Tegra186 onwards.
> Tegra MC driver will skip access to the restricted registers from Guest
> if the respective regions are not present in the memory-controller node
> of Guest DT.
>
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> ---
> .../memory-controllers/nvidia,tegra186-mc.yaml | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
> index 935d63d181d9..c52c259f7ec5 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
> @@ -146,17 +146,17 @@ allOf:
> then:
> properties:
> reg:
> - maxItems: 6
> + maxItems: 4
minItems?
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
From: Dmitry Baryshkov @ 2024-04-02 19:15 UTC (permalink / raw)
To: Jeff Johnson
Cc: Marc Gonzalez, Konrad Dybcio, Krzysztof Kozlowski, Kalle Valo,
ath10k, wireless, DT, MSM, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pierre-Hugues Husson, Arnaud Vrac, Bjorn Andersson,
Jami Kettunen, Jeffrey Hugo
In-Reply-To: <36890ee7-ab9e-448c-ae30-7a75ac28b496@quicinc.com>
On Tue, 2 Apr 2024 at 21:22, Jeff Johnson <quic_jjohnson@quicinc.com> wrote:
>
> On 4/2/2024 8:55 AM, Dmitry Baryshkov wrote:
> > I'd say, we should take a step back and actually verify how this was
> > handled in the vendor kernel.
>
> (error handling and other non-QMI code removed from the following for readability)
>
> In ath10k we unconditionally call the following in
> ath10k_qmi_event_server_arrive():
> ret = ath10k_qmi_host_cap_send_sync(qmi);
> ret = ath10k_qmi_msa_mem_info_send_sync_msg(qmi);
> ret = ath10k_qmi_setup_msa_permissions(qmi);
> ret = ath10k_qmi_msa_ready_send_sync_msg(qmi);
> ret = ath10k_qmi_cap_send_sync_msg(qmi);
>
> In vendor icnss2 there is conditional logic in icnss_driver_event_server_arrive():
Note, wcn3990 is icnss, not icnss2
> if (priv->device_id == WCN6750_DEVICE_ID ||
> priv->device_id == WCN6450_DEVICE_ID) {
> ret = wlfw_host_cap_send_sync(priv);
> }
>
> if (priv->device_id == ADRASTEA_DEVICE_ID) {
> ret = wlfw_msa_mem_info_send_sync_msg(priv);
> ret = wlfw_msa_ready_send_sync_msg(priv);
> }
The problem with applying this approach is that here the discriminator
is the WiFi device ID. WCN6750, WCN6450 and this ADRASTEA are
different WiFi/BT chips. However for msm8998 and e.g. sdm845 there is
no easy way to distinguish the WiFi chips. Both platforms use wcn3990
device.
>
> ret = wlfw_cap_send_sync_msg(priv);
>
> reference:
> https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r1-rel/icnss2/main.c?ref_type=heads#L890
>
> /jeff
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: marvell: turris-mox: drop unneeded flash address/size-cells
From: Andrew Lunn @ 2024-04-02 19:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Robert Marko, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240402183240.49193-2-krzk@kernel.org>
On Tue, Apr 02, 2024 at 08:32:39PM +0200, Krzysztof Kozlowski wrote:
> Flash node uses single "partition" node to describe partitions, so
> remove deprecated address/size-cells properties to also fix dtc W=1
> warnings:
>
> armada-3720-turris-mox.dts:218.10-255.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/spi@10600/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: marvell: eDPU: drop redundant address/size-cells
From: Andrew Lunn @ 2024-04-02 19:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Robert Marko, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240402183240.49193-1-krzk@kernel.org>
On Tue, Apr 02, 2024 at 08:32:38PM +0200, Krzysztof Kozlowski wrote:
> The ethernet-switch node does not have children with unit addresses, so
> address/size-cells are not really correct, as reported by dtc W=1
> warning:
>
> armada-3720-eDPU.dts:26.19-60.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/mdio@32004/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> This probably also fixes dtbs_check warning, but I could not find it, so
> not sure about that.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Gergo Koteles @ 2024-04-02 18:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ike Panhc, Hans de Goede, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <a19688d3-5402-41c0-b10a-131cefed5b91@linaro.org>
Hi Krzysztof,
On Tue, 2024-04-02 at 20:08 +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 16:36, Gergo Koteles wrote:
> > Hi Krzysztof,
> >
> > On Tue, 2024-04-02 at 15:55 +0200, Krzysztof Kozlowski wrote:
> > >
> > > Do we really need to define all these possible LED functions? Please
> > > link to DTS user for this.
> > >
> >
> > I think for userspace it's easier to support an LED with a specified
> > name than to use various sysfs attributes. LED devices are easy to find
> > because they available are in the /sys/class/leds/ directory.
> > So I think it's a good thing to define LED names somewhere.
>
> You did not add anything for user-space, but DT bindings. We do not keep
> here anything for user-space.
>
The LED_FUNCTION_KBD_BACKLIGHT confused me. Ok, this shouldn't be here,
I will remove it from v2.
Thanks,
Gergo
^ permalink raw reply
* [PATCH 3/3] arm64: dts: marvell: espressobin-ultra: fix Ethernet Switch unit address
From: Krzysztof Kozlowski @ 2024-04-02 18:32 UTC (permalink / raw)
To: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402183240.49193-1-krzk@kernel.org>
The Espressobin Ultra DTS includes Espressobin DTSI which defines
ethernet-switch@1 node. The Ultra DTS overrides "reg" to 3, but that
leaves still old unit address which conflicts with the new phy@1 node
(W=1 dtc warning):
armada-3720-espressobin.dtsi:148.29-203.4: Warning (unique_unit_address_if_enabled): /soc/internal-regs@d0000000/mdio@32004/ethernet-switch@1: duplicate unit-address (also used in node /soc/internal-regs@d0000000/mdio@32004/ethernet-phy@1)
Fix this by deleting ethernet-switch@1 node and merging original node
with code from Ultra DTS into new ethernet-switch@3.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware.
---
.../marvell/armada-3720-espressobin-ultra.dts | 104 +++++++++++-------
1 file changed, 67 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
index 870bb380a40a..b3cc2b7b5d19 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts
@@ -114,54 +114,84 @@ &usb3 {
};
&mdio {
+ /* Switch is @3, not @1 */
+ /delete-node/ ethernet-switch@1;
extphy: ethernet-phy@1 {
reg = <1>;
reset-gpios = <&gpionb 2 GPIO_ACTIVE_LOW>;
};
-};
-&switch0 {
- reg = <3>;
+ switch0: ethernet-switch@3 {
+ compatible = "marvell,mv88e6085";
+ reg = <3>;
- reset-gpios = <&gpiosb 23 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpiosb 23 GPIO_ACTIVE_LOW>;
+ dsa,member = <0 0>;
- ethernet-ports {
- switch0port1: ethernet-port@1 {
- reg = <1>;
- label = "lan0";
- phy-handle = <&switch0phy0>;
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0port0: ethernet-port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <ð0>;
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ switch0port1: ethernet-port@1 {
+ reg = <1>;
+ label = "lan0";
+ phy-handle = <&switch0phy0>;
+ };
+
+ switch0port2: ethernet-port@2 {
+ reg = <2>;
+ label = "lan1";
+ phy-handle = <&switch0phy1>;
+ };
+
+ switch0port3: ethernet-port@3 {
+ reg = <3>;
+ label = "lan2";
+ phy-handle = <&switch0phy2>;
+ };
+
+ switch0port4: ethernet-port@4 {
+ reg = <4>;
+ label = "lan3";
+ phy-handle = <&switch0phy3>;
+ };
+
+ switch0port5: ethernet-port@5 {
+ reg = <5>;
+ label = "wan";
+ phy-handle = <&extphy>;
+ phy-mode = "sgmii";
+ };
};
- switch0port2: ethernet-port@2 {
- reg = <2>;
- label = "lan1";
- phy-handle = <&switch0phy1>;
- };
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- switch0port3: ethernet-port@3 {
- reg = <3>;
- label = "lan2";
- phy-handle = <&switch0phy2>;
- };
-
- switch0port4: ethernet-port@4 {
- reg = <4>;
- label = "lan3";
- phy-handle = <&switch0phy3>;
- };
-
- switch0port5: ethernet-port@5 {
- reg = <5>;
- label = "wan";
- phy-handle = <&extphy>;
- phy-mode = "sgmii";
- };
- };
-
- mdio {
- switch0phy3: ethernet-phy@14 {
- reg = <0x14>;
+ switch0phy0: ethernet-phy@11 {
+ reg = <0x11>;
+ };
+ switch0phy1: ethernet-phy@12 {
+ reg = <0x12>;
+ };
+ switch0phy2: ethernet-phy@13 {
+ reg = <0x13>;
+ };
+ switch0phy3: ethernet-phy@14 {
+ reg = <0x14>;
+ };
};
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: marvell: turris-mox: drop unneeded flash address/size-cells
From: Krzysztof Kozlowski @ 2024-04-02 18:32 UTC (permalink / raw)
To: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240402183240.49193-1-krzk@kernel.org>
Flash node uses single "partition" node to describe partitions, so
remove deprecated address/size-cells properties to also fix dtc W=1
warnings:
armada-3720-turris-mox.dts:218.10-255.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/spi@10600/flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
index f1a9f2234359..54453b0a91f9 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -216,8 +216,6 @@ &spi0 {
assigned-clock-rates = <20000000>;
flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <20000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: marvell: eDPU: drop redundant address/size-cells
From: Krzysztof Kozlowski @ 2024-04-02 18:32 UTC (permalink / raw)
To: Robert Marko, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
The ethernet-switch node does not have children with unit addresses, so
address/size-cells are not really correct, as reported by dtc W=1
warning:
armada-3720-eDPU.dts:26.19-60.4: Warning (avoid_unnecessary_addr_size): /soc/internal-regs@d0000000/mdio@32004/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
This probably also fixes dtbs_check warning, but I could not find it, so
not sure about that.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts
index d6d37a1f6f38..91c2f8b4edfa 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts
@@ -25,8 +25,6 @@ &mdio {
/* Actual device is MV88E6361 */
switch: switch@0 {
compatible = "marvell,mv88e6190";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver support
From: kernel test robot @ 2024-04-02 18:26 UTC (permalink / raw)
To: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
frank.li, conor+dt
Cc: oe-kbuild-all, hongxing.zhu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel, kernel, imx
In-Reply-To: <1712036704-21064-4-git-send-email-hongxing.zhu@nxp.com>
Hi Richard,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v6.9-rc2]
[cannot apply to next-20240402]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Zhu/dt-bindings-phy-phy-imx8-pcie-Add-binding-for-i-MX8Q-HSIO-SerDes-PHY/20240402-140347
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/1712036704-21064-4-git-send-email-hongxing.zhu%40nxp.com
patch subject: [PATCH v2 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver support
config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20240403/202404030236.zuDJQOtw-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240403/202404030236.zuDJQOtw-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404030236.zuDJQOtw-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/phy/freescale/phy-fsl-imx8q-hsio.c:34: warning: "MODE_MASK" redefined
34 | #define MODE_MASK GENMASK(20, 17)
|
In file included from arch/arm/include/asm/ptrace.h:10,
from arch/arm/include/asm/irqflags.h:7,
from include/linux/irqflags.h:18,
from arch/arm/include/asm/bitops.h:28,
from include/linux/bitops.h:68,
from include/linux/kernel.h:23,
from include/linux/clk.h:13,
from drivers/phy/freescale/phy-fsl-imx8q-hsio.c:6:
arch/arm/include/uapi/asm/ptrace.h:67: note: this is the location of the previous definition
67 | #define MODE_MASK 0x0000001f
|
vim +/MODE_MASK +34 drivers/phy/freescale/phy-fsl-imx8q-hsio.c
27
28 /* i.MX8Q HSIO registers */
29 #define CTRL0 0x0
30 #define APB_RSTN_0 BIT(0)
31 #define APB_RSTN_1 BIT(1)
32 #define PIPE_RSTN_0_MASK GENMASK(25, 24)
33 #define PIPE_RSTN_1_MASK GENMASK(27, 26)
> 34 #define MODE_MASK GENMASK(20, 17)
35 #define MODE_PCIE 0x0
36 #define MODE_SATA 0x4
37 #define DEVICE_TYPE_MASK GENMASK(27, 24)
38 #define EPCS_TXDEEMP BIT(5)
39 #define EPCS_TXDEEMP_SEL BIT(6)
40 #define EPCS_PHYRESET_N BIT(7)
41 #define RESET_N BIT(12)
42
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
From: Conor Dooley @ 2024-04-02 18:25 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Andy Shevchenko, Vinod Koul, Krzysztof Kozlowski,
Conor Dooley, Viresh Kumar, Serge Semin, dmaengine, devicetree,
linux-kernel
In-Reply-To: <20240401204354.1691845-1-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
On Mon, Apr 01, 2024 at 03:43:53PM -0500, Rob Herring wrote:
> 'data-width' and 'data_width' properties are defined as arrays, but the
> schema is defined as a matrix. That works currently since everything gets
> decoded in to matrices, but that is internal to dtschema and could change.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
From: Alexey Minnekhanov @ 2024-04-02 18:25 UTC (permalink / raw)
To: Dmitry Baryshkov, Marc Gonzalez
Cc: Konrad Dybcio, Krzysztof Kozlowski, Kalle Valo, Jeff Johnson,
ath10k, wireless, DT, MSM, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pierre-Hugues Husson, Arnaud Vrac, Bjorn Andersson,
Jami Kettunen, Jeffrey Hugo
In-Reply-To: <CAA8EJppeREj-0g9oGCzzKx5ywhg1mgmJR1q8yvXKN7N45do1Xg@mail.gmail.com>
On 02.04.2024 18:55, Dmitry Baryshkov wrote:
> I'd say, we should take a step back and actually verify how this was
> handled in the vendor kernel.
AFAIK there is no such thing in vendor kernel driver for this, as
this startup procedure is likely handled entirely in userspace in
cnss_daemon.
By the way this workaround is needed also for Wi-Fi in sdm630/660,
so no not only msm8998 suffers from this.
> This sounds more like a firmware feature, not a hardware feature
> having this property in DT does not look right
I agree with these 2 points above. This can be handled more nicely
as firmware feature encoded in firmware-5.bin using ath10k-fwencoder
and not involve any new DT compatibles or properties.
--
Regards,
Alexey Minnekhanov
^ permalink raw reply
* Re: [PATCH] dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
From: Conor Dooley @ 2024-04-02 18:23 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20240401204959.1698106-1-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
On Mon, Apr 01, 2024 at 03:49:58PM -0500, Rob Herring wrote:
> 'pcie-phy' is missing any type. Add 'type: object' to indicate it's a
> node.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
From: Jeff Johnson @ 2024-04-02 18:22 UTC (permalink / raw)
To: Dmitry Baryshkov, Marc Gonzalez
Cc: Konrad Dybcio, Krzysztof Kozlowski, Kalle Valo, ath10k, wireless,
DT, MSM, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pierre-Hugues Husson, Arnaud Vrac, Bjorn Andersson, Jami Kettunen,
Jeffrey Hugo
In-Reply-To: <CAA8EJppeREj-0g9oGCzzKx5ywhg1mgmJR1q8yvXKN7N45do1Xg@mail.gmail.com>
On 4/2/2024 8:55 AM, Dmitry Baryshkov wrote:
> I'd say, we should take a step back and actually verify how this was
> handled in the vendor kernel.
(error handling and other non-QMI code removed from the following for readability)
In ath10k we unconditionally call the following in
ath10k_qmi_event_server_arrive():
ret = ath10k_qmi_host_cap_send_sync(qmi);
ret = ath10k_qmi_msa_mem_info_send_sync_msg(qmi);
ret = ath10k_qmi_setup_msa_permissions(qmi);
ret = ath10k_qmi_msa_ready_send_sync_msg(qmi);
ret = ath10k_qmi_cap_send_sync_msg(qmi);
In vendor icnss2 there is conditional logic in icnss_driver_event_server_arrive():
if (priv->device_id == WCN6750_DEVICE_ID ||
priv->device_id == WCN6450_DEVICE_ID) {
ret = wlfw_host_cap_send_sync(priv);
}
if (priv->device_id == ADRASTEA_DEVICE_ID) {
ret = wlfw_msa_mem_info_send_sync_msg(priv);
ret = wlfw_msa_ready_send_sync_msg(priv);
}
ret = wlfw_cap_send_sync_msg(priv);
reference:
https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r1-rel/icnss2/main.c?ref_type=heads#L890
/jeff
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: net: snps,dwmac: Align 'snps,priority' type definition
From: Conor Dooley @ 2024-04-02 18:20 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Krzysztof Kozlowski, Conor Dooley, Alexandre Torgue,
Giuseppe Cavallaro, Jose Abreu, netdev, devicetree, linux-kernel
In-Reply-To: <20240401204422.1692359-2-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
On Mon, Apr 01, 2024 at 03:44:22PM -0500, Rob Herring wrote:
> 'snps,priority' is also defined in dma/snps,dw-axi-dmac.yaml as a
> uint32-array. It's preferred to have a single type for a given property
> name, so update the type in snps,dwmac schema to match.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY binding
From: Conor Dooley @ 2024-04-02 18:16 UTC (permalink / raw)
To: Frank Li
Cc: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
kernel, imx
In-Reply-To: <ZgwU8edE3VFYngWR@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Tue, Apr 02, 2024 at 10:23:45AM -0400, Frank Li wrote:
> On Tue, Apr 02, 2024 at 01:45:03PM +0800, Richard Zhu wrote:
> > Add i.MX8QM and i.MX8QXP HSIO SerDes PHY binding.
> > - Use the controller ID to specify which controller is binded to the
> > PHY.
> > - Introduce one HSIO configuration, mandatory required to set
> > "PCIE_AB_SELECT" and "PHY_X1_EPCS_SEL" during the initialization.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
>
> You missed all conor's comments.
> Please double check v1's comments.
> > + fsl,refclk-pad-mode:
> > + description: |
> > + Specifies the mode of the refclk pad used. It can be UNUSED(PHY
> > + refclock is derived from SoC internal source), INPUT(PHY refclock
> > + is provided externally via the refclk pad) or OUTPUT(PHY refclock
> > + is derived from SoC internal source and provided on the refclk pad).
> > + Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
> > + to be used.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [ 0, 1, 2 ]
>
> I remember needn't enum because there are header file.
Yah, specifically my comments about this property were missed and were
probably the most meaningful comments I left.
Thanks for the reminder Frank.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: imu: add icm42688 inside inv_icm42600
From: Conor Dooley @ 2024-04-02 18:13 UTC (permalink / raw)
To: inv.git-commit
Cc: jic23, robh, krzysztof.kozlowski+dt, conor+dt, lars, linux-iio,
devicetree, Jean-Baptiste Maneyrol
In-Reply-To: <20240402090046.764572-2-inv.git-commit@tdk.com>
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
On Tue, Apr 02, 2024 at 09:00:45AM +0000, inv.git-commit@tdk.com wrote:
Acked-by: Conor Dooley <conor.dooley@microchip.com>
> TDK-Micronas GmbH
> Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 6108. VAT ID / USt-IdNr.: DE 812878184
> Management / Gesch?ftsf?hrung: Sam Maddalena
>
> This e-mail and any files transmitted with it are confidential information of TDK-Micronas and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender by return e-mail and delete all copies of this e-mail message along with all attachments. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Well, I didn't get it in error since I am an explicit CC, but you sent
this to a mailing list...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 17/18] dt-bindings: pci: rockchip,rk3399-pcie-ep: Add ep-gpios property
From: Krzysztof Kozlowski @ 2024-04-02 18:10 UTC (permalink / raw)
To: Damien Le Moal, Manivannan Sadhasivam, Lorenzo Pieralisi,
Kishon Vijay Abraham I, Shawn Lin, Krzysztof Wilczyński,
Bjorn Helgaas, Heiko Stuebner, linux-pci, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
Cc: linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <be2a0fa0-9d5d-45c3-810a-56d6924c8891@kernel.org>
On 02/04/2024 09:55, Damien Le Moal wrote:
> On 4/2/24 16:38, Damien Le Moal wrote:
>> On 4/2/24 16:33, Krzysztof Kozlowski wrote:
>>> On 02/04/2024 01:36, Damien Le Moal wrote:
>>>> On 4/1/24 18:57, Krzysztof Kozlowski wrote:
>>>>> On 01/04/2024 01:06, Damien Le Moal wrote:
>>>>>> On 3/30/24 18:16, Krzysztof Kozlowski wrote:
>>>>>>> On 30/03/2024 05:19, Damien Le Moal wrote:
>>>>>>>> From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
>>>>>>>>
>>>>>>>> Describe the `ep-gpios` property which is used to map the PERST# input
>>>>>>>> signal for endpoint mode.
>>>>>>>>
>>>>>>>> Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
>>>>>>>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml | 3 +++
>>>>>>>> 1 file changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
>>>>>>>> index 6b62f6f58efe..9331d44d6963 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
>>>>>>>> @@ -30,6 +30,9 @@ properties:
>>>>>>>> maximum: 32
>>>>>>>> default: 32
>>>>>>>>
>>>>>>>> + ep-gpios:
>>>>>>>> + description: Input GPIO configured for the PERST# signal.
>>>>>>>
>>>>>>> Missing maxItems. But more important: why existing property perst-gpios,
>>>>>>> which you already have there in common schema, is not correct for this case?
>>>>>>
>>>>>> I am confused... Where do you find perst-gpios defined for the rk3399 ?
>>>>>> Under Documentation/devicetree/bindings/pci/, the only schema I see using
>>>>>> perst-gpios property are for the qcom (Qualcomm) controllers.
>>>>>
>>>>> You are right, it's so far only in Qualcomm.
>>>>>
>>>>>> The RC bindings for the rockchip rk3399 PCIe controller
>>>>>> (pci/rockchip,rk3399-pcie.yaml) already define the ep-gpios property. So if
>>>>>
>>>>> Any reason why this cannot be named like GPIO? Is there already a user
>>>>> of this in Linux kernel? Commit msg says nothing about this, so that's
>>>>> why I would expect name matching the signal.
>>>>
>>>> The RC-mode PCIe controller node of the rk3399 DTS already defines the ep-gpios
>>>> property for RC side PERST# signal handling. So we simply reused the exact same
>>>> name to be consistent between RC and EP. I personnally have no preferences. If
>>>> there is an effort to rename such signal with some preferred pattern, I will
>>>> follow. For the EP node, there was no PERST signal handling in the driver and
>>>> no property defined for it, so any name is fine. "perst-gpios" would indeed be
>>>> a better name, but again, given that the RC controller node has ep-gpios, we
>>>> reused that. What is your recommendation here ?
>>>
>>> Actually I don't know, perst and ep would work for me. If you do not
>>> have code for this in the driver yet (nothing is shared between ep and
>>> host), then maybe let's go with perst to match the actual name.
>>
>> That works for me. The other simple solution would be to move the RC node
>> ep-gpios description to the common schema pci/rockchip,rk3399-pcie-common.yaml,
>> maybe ? Otherwise, perst-gpios like the Qualcomm schemas would be nice too.
>
> Thinking more about this, I think moving the ep-gpios description to the common
> schema is the right thing to do given that the driver uses common code between
> RC and EP to get that property. But if that is not acceptable, I can rename it
> and get that property in the controller EP mode initialization code. That will
> be add a little more code in the driver.
I forgot that it is actually the same hardware, so if host has
"ep-gpios" already then EP mode should have the same property. Common
schema is good idea.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: Add Himax HX83102J touchscreen
From: Conor Dooley @ 2024-04-02 18:09 UTC (permalink / raw)
To: Allen_Lin
Cc: dmitry.torokhov, robh, krzysztof.kozlowski+dt, jikos,
benjamin.tissoires, linux-input, devicetree, linux-kernel
In-Reply-To: <TY0PR06MB5611C37640AA40B2B7716ABE9E3E2@TY0PR06MB5611.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4523 bytes --]
On Tue, Apr 02, 2024 at 06:49:27PM +0800, Allen_Lin wrote:
> Add the HX83102j touchscreen device tree bindings documents.
> HX83102j is a Himax TDDI touchscreen controller.
> It's power sequence should be bound with a lcm driver, thus it
> needs to be a panel follower. Others are the same as normal SPI
> touchscreen controller.
>
> Signed-off-by: Allen_Lin <allencl_lin@hotmail.com>
> ---
> .../input/touchscreen/himax,hx83102j.yaml | 100 ++++++++++++++++++
> MAINTAINERS | 6 ++
> 2 files changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
> new file mode 100644
> index 000000000000..fe79129f704a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/himax,hx83102j.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Himax hx83102j touchscreen
> +
> +maintainers:
> + - Allen Lin <allencl_lin@hotmail.com>
> +
> +description:
> + This Himax hx83102j touchscreen uses the spi protocol.
> +
> +allOf:
> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + const: himax,hx83102j
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> + vccd-supply:
> + description: A phandle for the regualtor supplying IO power.
nit: regulator
> +
> + vsn-supply:
> + description: Negative supply regulator.
> +
> + vsp-supply:
> + description: Positive supply regulator.
Cool, thanks for adding these.
> +
> + ddreset-gpios:
> + description: A phandle of gpio for display reset controlled by the LCD driver.
> + This is the master reset, if this reset is triggered, the TP reset will
> + also be triggered.
> +
> + spi-cpha: true
> +
> + spi-cpol: true
> +
> + spi-max-frequency: true
> +
> + panel: true
> +
> + himax,firmware-name:
firmware-name is a standard property, you don't need to vendor prefix it.
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + Specify the file name for firmware loading.
> +
> + himax,pid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + PID for HID device, used to validate firmware.
Why do you need this _and_ firmware-name? You should be able to trust
the firmware that the dt has told you to use, no?
Cheers,
Conor.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - reset-gpios
> + - panel
> + - vccd-supply
> + - vsn-supply
> + - vsp-supply
> + - ddreset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ap_ts: touchscreen@0 {
> + compatible = "himax,hx83102j";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&touch_int0 &touch_reset>;
> + reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
> + spi-cpha;
> + spi-cpol;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + panel = <&panel>;
> + vccd-supply = <®ulator>;
> + vsn-supply = <®ulator>;
> + vsp-supply = <®ulator>;
> + ddreset-gpios = <&gpio1>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43b39956694a..aa51c60fd66d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9669,6 +9669,12 @@ L: linux-kernel@vger.kernel.org
> S: Maintained
> F: drivers/misc/hisi_hikey_usb.c
>
> +HIMAX HID HX83102J TOUCHSCREEN
> +M: Allen Lin <allencl_lin@hotmail.com>
> +L: linux-input@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
> +
> HIMAX HX83112B TOUCHSCREEN SUPPORT
> M: Job Noorman <job@noorman.info>
> L: linux-input@vger.kernel.org
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Krzysztof Kozlowski @ 2024-04-02 18:08 UTC (permalink / raw)
To: Gergo Koteles, Ike Panhc, Hans de Goede, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <5864594aa47ecfeb23d5d05a3afc02393f84b44e.camel@irl.hu>
On 02/04/2024 16:36, Gergo Koteles wrote:
> Hi Krzysztof,
>
> On Tue, 2024-04-02 at 15:55 +0200, Krzysztof Kozlowski wrote:
>>
>> Do we really need to define all these possible LED functions? Please
>> link to DTS user for this.
>>
>
> I think for userspace it's easier to support an LED with a specified
> name than to use various sysfs attributes. LED devices are easy to find
> because they available are in the /sys/class/leds/ directory.
> So I think it's a good thing to define LED names somewhere.
You did not add anything for user-space, but DT bindings. We do not keep
here anything for user-space.
>
> J Luke missed this LED from /sys/class/leds/, that's where the idea
> came from. The scrollock, numlock, capslock and kbd_backlight LEDs are
> already exported.
>
> https://github.com/tomsom/yoga-linux/issues/58#issuecomment-2029926094
I see there sysfs, so what does it have to do with bindings?
Again, please link to in-tree or in-review DTS.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: watchdog: Convert Aspeed binding to DT schema
From: Rob Herring @ 2024-04-02 18:07 UTC (permalink / raw)
To: Andrew Jeffery
Cc: wim, linux, krzysztof.kozlowski+dt, conor+dt, joel, zev,
linux-watchdog, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240402120118.282035-1-andrew@codeconstruct.com.au>
On Tue, Apr 02, 2024 at 10:31:18PM +1030, Andrew Jeffery wrote:
> Squash warnings such as:
>
> ```
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-galaxy100.dtb: /ahb/apb@1e600000/watchdog@1e785000: failed to match any schema with compatible: ['aspeed,ast2400-wdt']
> ```
>
> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> ---
> .../bindings/watchdog/aspeed,ast2400-wdt.yaml | 130 ++++++++++++++++++
> .../bindings/watchdog/aspeed-wdt.txt | 73 ----------
> 2 files changed, 130 insertions(+), 73 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> delete mode 100644 Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> new file mode 100644
> index 000000000000..10fcb50c4051
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/aspeed,ast2400-wdt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed watchdog timer controllers
> +
> +maintainers:
> + - Andrew Jeffery <andrew@codeconstruct.com.au>
> +
> +properties:
> + compatible:
> + enum:
> + - aspeed,ast2400-wdt
> + - aspeed,ast2500-wdt
> + - aspeed,ast2600-wdt
> +
> + reg:
> + maxItems: 1
> +
> + clocks: true
# and order/function if more than 1 must be defined.
Please note it was missing from the original binding in the commit
message.
> +
> + aspeed,reset-type:
> + enum:
> + - cpu
> + - soc
> + - system
> + - none
> + description: |
> + Reset behaviour - The watchdog can be programmed to generate one of three
> + different types of reset when a timeout occcurs.
> +
> + Specifying 'cpu' will only reset the processor on a timeout event.
> +
> + Specifying 'soc' will reset a configurable subset of the SoC's controllers
> + on a timeout event. Controllers critical to the SoC's operation may remain untouched.
> +
> + Specifying 'system' will reset all controllers on a timeout event, as if EXTRST had been asserted.
> + Specifying "none" will cause the timeout event to have no reset effect.
> + Another watchdog engine on the chip must be used for chip reset operations.
> +
> + The default reset type is "system"
Express as schema:
default: system
> +
> + aspeed,alt-boot:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
Don't need '|' if no formatting to preserve.
> + Direct the watchdog to configure the SoC to boot from the alternative boot
> + region if a timeout occurs.
> +
> + aspeed,external-signal:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + Assert the timeout event on an external signal pin associated with the
> + watchdog controller instance. The pin must be muxed appropriately.
> +
> + aspeed,ext-pulse-duration:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + The duration, in microseconds, of the pulse emitted on the external signal pin
Wrap at <80. Period at end needed.
> +
> + aspeed,ext-push-pull:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + If aspeed,external-signal is specified in the node, set the external
> + signal pin's drive type to push-pull. If aspeed,ext-push-pull is not
> + specified then the pin is configured as open-drain.
> +
> + aspeed,ext-active-high:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + If both aspeed,external-signal and aspeed,ext-push-pull are specified in
> + the node, set the pulse polarity to active-high. If aspeed,ext-active-high
> + is not specified then the pin is configured as active-low.
> +
> + aspeed,reset-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 2
> + description: |
> + A bitmaks indicating which peripherals will be reset if the watchdog
> + timer expires. On AST2500 SoCs this should be a single word defined using
> + the AST2500_WDT_RESET_* macros; on AST2600 SoCs this should be a two-word
> + array with the first word defined using the AST2600_WDT_RESET1_* macros,
> + and the second word defined using the AST2600_WDT_RESET2_* macros.
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + anyOf:
> + - required:
> + - aspeed,ext-push-pull
> + - required:
> + - aspeed,ext-active-high
> + - required:
> + - aspeed,reset-mask
> + then:
> + properties:
> + compatible:
> + enum:
> + - aspeed,ast2500-wdt
> + - aspeed,ast2600-wdt
> + - if:
> + required:
> + - aspeed,ext-active-high
> + then:
> + required:
> + - aspeed,ext-push-pull
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + wdt1: watchdog@1e785000 {
Drop unused labels.
> + compatible = "aspeed,ast2400-wdt";
> + reg = <0x1e785000 0x1c>;
> + aspeed,reset-type = "system";
> + aspeed,external-signal;
> + };
> + - |
> + #include <dt-bindings/watchdog/aspeed-wdt.h>
> + wdt2: watchdog@1e785040 {
> + compatible = "aspeed,ast2600-wdt";
> + reg = <0x1e785040 0x40>;
> + aspeed,reset-mask = <AST2600_WDT_RESET1_DEFAULT
> + (AST2600_WDT_RESET2_DEFAULT & ~AST2600_WDT_RESET2_LPC)>;
> + };
> diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> deleted file mode 100644
> index 3208adb3e52e..000000000000
> --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> +++ /dev/null
> @@ -1,73 +0,0 @@
> -Aspeed Watchdog Timer
> -
> -Required properties:
> - - compatible: must be one of:
> - - "aspeed,ast2400-wdt"
> - - "aspeed,ast2500-wdt"
> - - "aspeed,ast2600-wdt"
> -
> - - reg: physical base address of the controller and length of memory mapped
> - region
> -
> -Optional properties:
> -
> - - aspeed,reset-type = "cpu|soc|system|none"
> -
> - Reset behavior - Whenever a timeout occurs the watchdog can be programmed
> - to generate one of three different, mutually exclusive, types of resets.
> -
> - Type "none" can be specified to indicate that no resets are to be done.
> - This is useful in situations where another watchdog engine on chip is
> - to perform the reset.
> -
> - If 'aspeed,reset-type=' is not specified the default is to enable system
> - reset.
> -
> - Reset types:
> -
> - - cpu: Reset CPU on watchdog timeout
> -
> - - soc: Reset 'System on Chip' on watchdog timeout
> -
> - - system: Reset system on watchdog timeout
> -
> - - none: No reset is performed on timeout. Assumes another watchdog
> - engine is responsible for this.
> -
> - - aspeed,alt-boot: If property is present then boot from alternate block.
> - - aspeed,external-signal: If property is present then signal is sent to
> - external reset counter (only WDT1 and WDT2). If not
> - specified no external signal is sent.
> - - aspeed,ext-pulse-duration: External signal pulse duration in microseconds
> -
> -Optional properties for AST2500-compatible watchdogs:
> - - aspeed,ext-push-pull: If aspeed,external-signal is present, set the pin's
> - drive type to push-pull. The default is open-drain.
> - - aspeed,ext-active-high: If aspeed,external-signal is present and and the pin
> - is configured as push-pull, then set the pulse
> - polarity to active-high. The default is active-low.
> -
> -Optional properties for AST2500- and AST2600-compatible watchdogs:
> - - aspeed,reset-mask: A bitmask indicating which peripherals will be reset if
> - the watchdog timer expires. On AST2500 this should be a
> - single word defined using the AST2500_WDT_RESET_* macros;
> - on AST2600 this should be a two-word array with the first
> - word defined using the AST2600_WDT_RESET1_* macros and the
> - second word defined using the AST2600_WDT_RESET2_* macros.
> -
> -Examples:
> -
> - wdt1: watchdog@1e785000 {
> - compatible = "aspeed,ast2400-wdt";
> - reg = <0x1e785000 0x1c>;
> - aspeed,reset-type = "system";
> - aspeed,external-signal;
> - };
> -
> - #include <dt-bindings/watchdog/aspeed-wdt.h>
> - wdt2: watchdog@1e785040 {
> - compatible = "aspeed,ast2600-wdt";
> - reg = <0x1e785040 0x40>;
> - aspeed,reset-mask = <AST2600_WDT_RESET1_DEFAULT
> - (AST2600_WDT_RESET2_DEFAULT & ~AST2600_WDT_RESET2_LPC)>;
> - };
> --
> 2.39.2
>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium,pn-swap' property
From: Conor Dooley @ 2024-04-02 18:06 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <20240402105925.905144-2-alex@shruggie.ro>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote:
> On some HW designs, it's easier for the layout if the P/N pins are swapped.
> The driver currently has a DT property to do that.
"currently", because 1/2 adds it. bindings patches should precede the
driver patches in the series, so please swap the patches and remove this
portion of the description.
>
> This change documents the 'lontium,pn-swap' property.
>
> Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> ---
> .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> index 2cef252157985..3a804926b288a 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> @@ -24,6 +24,12 @@ properties:
> maxItems: 1
> description: GPIO connected to active high RESET pin.
>
> + lontium,pn-swap:
> + description: Swap the polarities of the P/N pins in software.
> + On some HW designs, the layout is simplified if the P/N pins
> + are inverted.
Please explain what configuration of a board would cause these to be
swapped, rather than why someone might want to configure the board this
way. I've got no idea what this hardware is actually doing, so this is
being pulled out of a hat, but I'd expect something like "Some boards
swap the polarity of the P/N pins, use this property to indicate this to
software".
> + type: boolean
The type here should be flag.
Cheers,
Conor.
> +
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> --
> 2.44.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-02 18:06 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <30065bdc-ccef-4610-b1c1-7661f801b8e9@ti.com>
On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>> registers within the System Controller device-tree node. The default MAC
>>> Address for the interface corresponding to the first MAC port will be set
>>> to the value programmed in the eFuse.
>>>
>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>> ---
>>>
>>> This patch is based on linux-next tagged next-20240402.
>>
>> Where is the DTS using it?
>
> The current implementation in the device-tree for older TI K3 SoCs is as
> follows:
>
> cpsw_port1: port@1 {
> reg = <1>;
> ti,mac-only;
> label = "port1";
> phys = <&phy_gmii_sel 1>;
> mac-address = [00 00 00 00 00 00];
> ti,syscon-efuse = <&wkup_conf 0x200>;
> };
>
> The "ti,syscon-efuse" property passes the reference to the System
> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> within the CTRL_MMR space.
Please reference upstream DTS or lore link to patch under review.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: leds: leds-qcom-lpg: Add support for PMI8950 PWM
From: Conor Dooley @ 2024-04-02 17:54 UTC (permalink / raw)
To: Gianluca Boiano
Cc: Pavel Machek, Lee Jones, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-leds,
linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20240402-pmi8950-pwm-support-v1-3-1a66899eeeb3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 236 bytes --]
On Tue, Apr 02, 2024 at 02:35:44PM +0200, Gianluca Boiano wrote:
> Update leds-qcom-lpg binding to support PMI8950 PWM.
>
> Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: renesas,cmt: Add R-Car V4M support
From: Conor Dooley @ 2024-04-02 17:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Laurent Pinchart, devicetree, linux-renesas-soc,
linux-kernel
In-Reply-To: <3e8a7a93261d8ad264dec2fa2784fe1bbfc4a23c.1712068536.git.geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On Tue, Apr 02, 2024 at 04:36:05PM +0200, Geert Uytterhoeven wrote:
> Document support for the Compare Match Timer Type0 (CMT0) and Type1
> (CMT1) in the Renesas R-Car V4M (R8A779H0) SoC.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: renesas,tmu: Add R-Car V4M support
From: Conor Dooley @ 2024-04-02 17:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Laurent Pinchart, devicetree, linux-renesas-soc,
linux-kernel
In-Reply-To: <8a39386b1a33db6e83e852b3b365bc1adeb25242.1712068574.git.geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 280 bytes --]
On Tue, Apr 02, 2024 at 04:37:02PM +0200, Geert Uytterhoeven wrote:
> Document support for the Timer Unit (TMU) in the Renesas R-Car V4M
> (R8A779H0) SoC.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox