* Re: [PATCH v9 01/14] dt-bindings: media: qcom,glymur-iris: Add glymur video codec
From: Vishnu Reddy @ 2026-07-17 3:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Dmitry Baryshkov, Mauro Carvalho Chehab,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio, linux-kernel, linux-media,
linux-arm-msm, iommu, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260716-soft-dexterous-adder-badb49@quoll>
On 7/16/2026 1:10 PM, Krzysztof Kozlowski wrote:
> On Wed, Jul 15, 2026 at 07:39:55PM +0530, Vishnu Reddy wrote:
>> Add device tree binding for the Qualcomm Glymur Iris video codec. Glymur
>> is a new generation of video IP that introduces a dual-core architecture.
>> The second core brings its own power domain, clocks, and reset lines,
>> requiring additional power domains and clocks in the power sequence.
>> The current maxItems constraints for clocks and power-domains in the
>> common venus schema were sized for platforms available at the time of
>> authoring. The glymur platform introduces a dual core architecture
>> that requires more clocks and power domains, exceeding these limits.
>> Raise maxItems for clocks, clock-names, power-domains and
>> power-domain-names to accommodate the glymur platform.
>> The glymur platform-specific schema have fixed constraints for these
>> properties, so the common schema only acts as an upper bound.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> You must drop the tag, you changed the binding significantly without any
> doubts.
Ack
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v7 04/18] media: iris: Filter UBWC raw formats based on hardware capabilities
From: Vishnu Reddy @ 2026-07-17 3:46 UTC (permalink / raw)
To: Dmitry Baryshkov, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260709-iris-ar50lt-v7-4-76af9dd4d1f6@oss.qualcomm.com>
On 7/9/2026 7:11 PM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> The raw formats supported by Iris were previously advertised
> unconditionally, assuming UBWC support on all platforms. However, some
> platforms do not support UBWC which results in incorrect format
> capability exposure.
>
> Use the UBWC configuration provided by the platform to dynamically
> filter raw formats at runtime. If UBWC is not supported, UBWC-based
> formats are omitted from the advertised capability list, while linear
> formats remain available.
>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vdec.c | 26 ++++++++++++++++++++++----
> drivers/media/platform/qcom/iris/iris_venc.c | 25 +++++++++++++++++++++----
> 2 files changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vdec.c b/drivers/media/platform/qcom/iris/iris_vdec.c
> index 4c8bc7aac135..9fee5f28097d 100644
> --- a/drivers/media/platform/qcom/iris/iris_vdec.c
> +++ b/drivers/media/platform/qcom/iris/iris_vdec.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights reserved.
> */
>
> +#include <linux/soc/qcom/ubwc.h>
> #include <media/v4l2-event.h>
> #include <media/v4l2-mem2mem.h>
>
> @@ -69,8 +70,14 @@ static const u32 iris_vdec_formats_cap[] = {
> V4L2_PIX_FMT_QC10C,
> };
>
> +static const u32 iris_vdec_formats_noubwc_cap[] = {
> + V4L2_PIX_FMT_NV12,
> + V4L2_PIX_FMT_P010,
> +};
> +
> static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
> {
> + const struct qcom_ubwc_cfg_data *ubwc = inst->core->ubwc_cfg;
> unsigned int size, i;
> const u32 *fmt;
>
> @@ -80,8 +87,13 @@ static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
> size = inst->core->iris_platform_data->inst_iris_fmts_size;
> break;
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - fmt = iris_vdec_formats_cap;
> - size = ARRAY_SIZE(iris_vdec_formats_cap);
> + if (ubwc->ubwc_enc_version) {
> + fmt = iris_vdec_formats_cap;
> + size = ARRAY_SIZE(iris_vdec_formats_cap);
> + } else {
> + fmt = iris_vdec_formats_noubwc_cap;
> + size = ARRAY_SIZE(iris_vdec_formats_noubwc_cap);
> + }
> break;
> default:
> return false;
> @@ -110,6 +122,7 @@ static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
>
> static u32 find_format_by_index(struct iris_inst *inst, u32 index, u32 type)
> {
> + const struct qcom_ubwc_cfg_data *ubwc = inst->core->ubwc_cfg;
> unsigned int size;
> const u32 *fmt;
>
> @@ -119,8 +132,13 @@ static u32 find_format_by_index(struct iris_inst *inst, u32 index, u32 type)
> size = inst->core->iris_platform_data->inst_iris_fmts_size;
> break;
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - fmt = iris_vdec_formats_cap;
> - size = ARRAY_SIZE(iris_vdec_formats_cap);
> + if (ubwc->ubwc_enc_version) {
> + fmt = iris_vdec_formats_cap;
> + size = ARRAY_SIZE(iris_vdec_formats_cap);
> + } else {
> + fmt = iris_vdec_formats_noubwc_cap;
> + size = ARRAY_SIZE(iris_vdec_formats_noubwc_cap);
> + }
> break;
> default:
> return 0;
> diff --git a/drivers/media/platform/qcom/iris/iris_venc.c b/drivers/media/platform/qcom/iris/iris_venc.c
> index 16c52ad07e2c..2f2c56bf9122 100644
> --- a/drivers/media/platform/qcom/iris/iris_venc.c
> +++ b/drivers/media/platform/qcom/iris/iris_venc.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2022-2025 Qualcomm Innovation Center, Inc. All rights reserved.
> */
>
> +#include <linux/soc/qcom/ubwc.h>
> #include <media/v4l2-event.h>
> #include <media/v4l2-mem2mem.h>
>
> @@ -89,15 +90,25 @@ static const u32 iris_venc_formats_out[] = {
> V4L2_PIX_FMT_QC08C,
> };
>
> +static const u32 iris_venc_formats_noubwc_out[] = {
> + V4L2_PIX_FMT_NV12,
> +};
> +
> static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
> {
> + const struct qcom_ubwc_cfg_data *ubwc = inst->core->ubwc_cfg;
> unsigned int size, i;
> const u32 *fmt;
>
> switch (type) {
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - fmt = iris_venc_formats_out;
> - size = ARRAY_SIZE(iris_venc_formats_out);
> + if (ubwc->ubwc_enc_version) {
> + fmt = iris_venc_formats_out;
> + size = ARRAY_SIZE(iris_venc_formats_out);
> + } else {
> + fmt = iris_venc_formats_noubwc_out;
> + size = ARRAY_SIZE(iris_venc_formats_noubwc_out);
> + }
> break;
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> fmt = iris_venc_formats_cap;
> @@ -117,13 +128,19 @@ static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
>
> static u32 find_format_by_index(struct iris_inst *inst, u32 index, u32 type)
> {
> + const struct qcom_ubwc_cfg_data *ubwc = inst->core->ubwc_cfg;
> unsigned int size;
> const u32 *fmt;
>
> switch (type) {
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - fmt = iris_venc_formats_out;
> - size = ARRAY_SIZE(iris_venc_formats_out);
> + if (ubwc->ubwc_enc_version) {
> + fmt = iris_venc_formats_out;
> + size = ARRAY_SIZE(iris_venc_formats_out);
> + } else {
> + fmt = iris_venc_formats_noubwc_out;
> + size = ARRAY_SIZE(iris_venc_formats_noubwc_out);
> + }
> break;
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> fmt = iris_venc_formats_cap;
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
^ permalink raw reply
* [PATCH net-next v2 2/2] net: phy: Add support for the Maxio MAE0621A
From: Liu Changjie @ 2026-07-17 3:44 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
In-Reply-To: <MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
Add exact PHY ID matching and optional 125 MHz CLKOUT configuration
for the Maxio MAE0621A Gigabit Ethernet PHY. Preserve the existing
hardware configuration when the firmware property is absent.
Signed-off-by: Liu Changjie <liucj1228@outlook.com>
---
drivers/net/phy/Kconfig | 8 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/maxio.c | 103 +++++++++++++++++++++++++++++++++++++++
3 files changed, 112 insertions(+)
create mode 100644 drivers/net/phy/maxio.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 099f25dce..32e1a035b 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -283,6 +283,14 @@ config MARVELL_88X2222_PHY
Support for the Marvell 88X2222 Dual-port Multi-speed Ethernet
Transceiver.
+config MAXIO_PHY
+ tristate "Maxio Ethernet PHYs"
+ help
+ Support for Maxio Ethernet PHYs. Currently this driver supports the
+ MAE0621A Gigabit Ethernet PHY. The driver optionally selects a 125 MHz
+ clock on the CLKOUT pin while preserving the hardware configuration on
+ boards which do not request it.
+
config MAXLINEAR_GPHY
tristate "Maxlinear Ethernet PHYs"
select POLYNOMIAL if HWMON
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index de660ae94..7fb3626f0 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_MARVELL_10G_PHY) += marvell10g.o
obj-$(CONFIG_MARVELL_PHY) += marvell.o
obj-$(CONFIG_MARVELL_88Q2XXX_PHY) += marvell-88q2xxx.o
obj-$(CONFIG_MARVELL_88X2222_PHY) += marvell-88x2222.o
+obj-$(CONFIG_MAXIO_PHY) += maxio.o
obj-$(CONFIG_MAXLINEAR_GPHY) += mxl-gpy.o
obj-$(CONFIG_MAXLINEAR_86110_PHY) += mxl-86110.o
obj-y += mediatek/
diff --git a/drivers/net/phy/maxio.c b/drivers/net/phy/maxio.c
new file mode 100644
index 000000000..d2cb23895
--- /dev/null
+++ b/drivers/net/phy/maxio.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Driver for Maxio Ethernet PHYs. */
+
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/property.h>
+
+#define MAXIO_MAE0621A_PHY_ID 0x7b744412
+
+#define MAXIO_PAGE_SELECT 0x1f
+#define MAXIO_MAE0621A_PHYCR2_PAGE 0xa43
+#define MAXIO_MAE0621A_PHYCR2 0x19
+#define MAXIO_MAE0621A_CLKOUT_125M BIT(11)
+#define MAXIO_MAE0621A_CLKOUT_ENABLE BIT(0)
+
+struct maxio_priv {
+ bool clk_out_125m;
+};
+
+static int maxio_read_page(struct phy_device *phydev)
+{
+ return __phy_read(phydev, MAXIO_PAGE_SELECT);
+}
+
+static int maxio_write_page(struct phy_device *phydev, int page)
+{
+ return __phy_write(phydev, MAXIO_PAGE_SELECT, page);
+}
+
+static int maxio_mae0621a_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct maxio_priv *priv;
+ u32 frequency;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ phydev->priv = priv;
+
+ ret = device_property_read_u32(dev, "maxio,clk-out-frequency-hz",
+ &frequency);
+ if (ret == -EINVAL)
+ return 0;
+ if (ret)
+ return ret;
+
+ if (frequency != 125000000) {
+ phydev_err(phydev, "invalid CLKOUT frequency %u\n", frequency);
+ return -EINVAL;
+ }
+
+ priv->clk_out_125m = true;
+
+ return 0;
+}
+
+static int maxio_mae0621a_config_init(struct phy_device *phydev)
+{
+ struct maxio_priv *priv = phydev->priv;
+ int ret;
+
+ if (!priv->clk_out_125m)
+ return 0;
+
+ ret = phy_modify_paged_changed(phydev, MAXIO_MAE0621A_PHYCR2_PAGE,
+ MAXIO_MAE0621A_PHYCR2,
+ MAXIO_MAE0621A_CLKOUT_ENABLE |
+ MAXIO_MAE0621A_CLKOUT_125M,
+ MAXIO_MAE0621A_CLKOUT_ENABLE |
+ MAXIO_MAE0621A_CLKOUT_125M);
+ if (ret <= 0)
+ return ret;
+
+ return genphy_soft_reset(phydev);
+}
+
+static struct phy_driver maxio_drivers[] = {
+ {
+ PHY_ID_MATCH_EXACT(MAXIO_MAE0621A_PHY_ID),
+ .name = "Maxio MAE0621A",
+ .probe = maxio_mae0621a_probe,
+ .config_init = maxio_mae0621a_config_init,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ .read_page = maxio_read_page,
+ .write_page = maxio_write_page,
+ },
+};
+module_phy_driver(maxio_drivers);
+
+static const struct mdio_device_id __maybe_unused maxio_tbl[] = {
+ { PHY_ID_MATCH_EXACT(MAXIO_MAE0621A_PHY_ID) },
+ { }
+};
+MODULE_DEVICE_TABLE(mdio, maxio_tbl);
+
+MODULE_AUTHOR("Liu Changjie <liucj1228@outlook.com>");
+MODULE_DESCRIPTION("Maxio Ethernet PHY driver");
+MODULE_LICENSE("GPL");
--
2.55.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] dt-bindings: net: Add Maxio MAE0621A PHY
From: Liu Changjie @ 2026-07-17 3:44 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
In-Reply-To: <MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
Document the MAE0621A PHY ID and its optional 125 MHz CLKOUT
setting. Boards which do not provide the property retain the hardware
strap or bootloader configuration.
Only the 125 MHz setting is exposed because it is the only setting
exercised on hardware.
Signed-off-by: Liu Changjie <liucj1228@outlook.com>
---
.../bindings/net/maxio,mae0621a.yaml | 38 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
diff --git a/Documentation/devicetree/bindings/net/maxio,mae0621a.yaml b/Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
new file mode 100644
index 000000000..f1ea54583
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/maxio,mae0621a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxio MAE0621A Ethernet PHY
+
+maintainers:
+ - Liu Changjie <liucj1228@outlook.com>
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ const: ethernet-phy-id7b74.4412
+
+ maxio,clk-out-frequency-hz:
+ description:
+ Selects a 125 MHz clock on the CLKOUT pin. If the property is absent,
+ the hardware strap or bootloader configuration is preserved.
+ const: 125000000
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@1 {
+ compatible = "ethernet-phy-id7b74.4412";
+ reg = <1>;
+ maxio,clk-out-frequency-hz = <125000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f36..eeaf0b7a1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1013,6 +1013,8 @@ patternProperties:
description: MaxBotix Inc.
"^maxim,.*":
description: Maxim Integrated Products
+ "^maxio,.*":
+ description: Maxio Technology (Hangzhou) Co., Ltd.
"^maxlinear,.*":
description: MaxLinear Inc.
"^maxtor,.*":
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: qcom,snps-dwc3: Add property indicating presence of eUSB2 phy
From: Peter Chen @ 2026-07-17 3:42 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Krishna Kurapati, Krzysztof Kozlowski, Dmitry Baryshkov,
Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, linux-arm-msm@vger.kernel.org,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <almJeSq1zfcC1mjj@vbox>
On 26-07-17 01:56:59, Thinh Nguyen wrote:
> On Thu, Jul 16, 2026, Peter Chen wrote:
> > On 26-07-17 00:06:37, Thinh Nguyen wrote:
> > > >
> > > > I have seen fewer platforms use "phy_type" at dts for arm64, dwc3
> > > > core uses it only for special cases and the code was added for
> > > > ten years ago. For the default situation, we may not need to
> > > > change DWC3_GUSB2PHYCFG_EUSB2OPMODE value for UTMI+, Thinh, is it
> > > > correct?
> > > >
> > >
> > > The GUSB2PHYCFG.eUSB2OPMODE is only relevant for host mode and mainly
> > > for electrical compliance. Usually by default, the CoreConsultant
> > > setting should have this set correctly. So not explicitly setting it
> > > should be functionally fine (IIRC).
> > >
> > > That said, this is separate from the GUSB2PHYCFG.PHYIF, which the core
> > > uses dwc->hsphy_mode to indicate whether the UTMI interface is 8-bit or
> > > 16-bit.
> > >
> >
> > Why only rockchip uses this "phy_type" property, why other SoC vendors
> > no this requirement for UTMI width setting?
> >
>
> Not just rockchip, some tegra and hikey also use it. Some old qcom dts
> files also have it for ulpi.
Tegra and old qcom platforms use chipidea, hikey uses dwc3.
>
> It is typically set when the coreConsultant default differs from what
> the platform needs, so the driver can override it with the correct
> setting.
>
> My point is that changing "phy_type" definition is more involved than it
> looks. I'm open to alternatives.
>
I know your concern that in case the eUSB2 PHY SoC wants to change UTMI
width, it can't do that. Are there controller register know it connects
eUSB2 PHY?
For the place to put "eusb2" for phy type, I still think enum
usb_phy_interface at: include/linux/usb/phy.h is the most suitable
place, would you have any alternatives?
Another solution is using generic PHY API phy_get_mode, set fixed "eusb2"
mode at eUSB2 PHY driver, but it depends on PHY driver doesn't have
different settings for device and host mode.
Other solution is compare the generic PHY compatible string at dwc3 qcom
glue layer, it depends on eUSB2 PHY compatible string always contains
"eusb2-phy"
I prefer the solution that extend enum usb_phy_interface for eUSB2 PHY,
it uses existed kernel structure and device tree binding.
--
Thanks,
Peter Chen
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC
From: Maulik Shah (mkshah) @ 2026-07-17 3:41 UTC (permalink / raw)
To: Bjorn Andersson, Krzysztof Kozlowski
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, linux-arm-msm, linux-kernel, devicetree,
Konrad Dybcio
In-Reply-To: <almDHnEcruBl-I3l@baldur>
On 7/17/2026 7:38 AM, Bjorn Andersson wrote:
> On Thu, Jul 16, 2026 at 09:59:44AM +0200, Krzysztof Kozlowski wrote:
>> On Wed, Jul 15, 2026 at 06:52:01PM +0530, Maulik Shah wrote:
>>> X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
>>> register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
>>> Workaround hardware register bug on X1E80100") is already fixed in
>>> X1P42100 silicon.
>>>
>>> X1E80100 compatible forces the software workaround. Use the X1P42100
>>> specific compatible string for the PDC node to remove the workaround.
>>>
>>> Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD")
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/purwa.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>
>> Why does the DT change appear in the middle of the patchset? Please read
>> submitting patches documents - both of them - and maintainer-soc
>> profile.
>>
>
> I thought I had figured it out, but I'm not sure anymore.
>
> The claim from the cover letter is that patch 1 and 2 are completely
> independent, but patch 3 depends on Bartosz's thank you letter [2] that
> arrived a week before this series was sent out.
>
> We're not merging the three changes through the same tree and there's no
> expressed dependency between patch 2 and 3 (only implicitly by the order
> in the series). But as Konrad points out, in-between patch 2 and 3 we
> would not enable the secondary GPIO in the PDC driver, so Purwa would
> have broken GPIOs for a while (not ok). I think merging them in the
> opposite order would be what we want (i.e. 1, 3, then 2)
purwa-iot-evk.dts where firmware sets pass through mode, so current order of the patch seems to be ok.
(patch 3 as such is no impact for iot evk)
x1p42100-crd.dts where firmware sets secondary mode, applying in 1, 2, and then 3 may leave crd boards
in broken GPIOs for a while after [2], so yes order 1, 3, and then 2 makes more sense.
patch 1/2 - fixes the purwa to operate on correct registers.
patch 3 - Allow crd boards to re-set the mode to pass through
>
>
> But this series implies that Purwa has been broken from the start - that
> the PDC driver has always operated on the wrong registers.
yes, purwa always operated on the wrong registers.
>
> Perhaps the impact of this was limited as there's not that many direct
> &pdc references in the DT, but the patch that Bartosz's thank-you email
> was sent for got merged as 77fbc756d9cb ("Revert "pinctrl: qcom:
> x1e80100: Bypass PDC wakeup parent for now""), and that would make a lot
> more use of the PDC.
>
> So while nothing in this series states it, it sounds like Purwa might be
> completely broken right now and this series aims to fix it?
>
>
> It's not clear to me why the driver change doesn't have a Fixes tag, it
> seems like the patch that introduced x1e_quirk was broken and should be
> marked as Fixes.
x1e_quirk in the driver via commit e9a48ea4d90b ("irqchip/qcom-pdc: Workaround hardware register bug on X1E80100")
says only about x1e/ hamoa specific bug, it seemed it never wanted to enable the quirk for x1p / purwa. the quirk
rather got anyway enabled for purwa due to both hamoa/purwa sharing the same compatible.
Patch 1/2 of the series aims to fix this (and patch-2 carries the fixes: tag).
Thanks,
Maulik
>
> [2] https://lore.kernel.org/linux-arm-msm/CAMRc=MeU0QuRozMscv02M59+a66S05Jm18CyvNE-qSYrY=S7hQ@mail.gmail.com/
>
> Regards,
> Bjorn
>
>> Best regards,
>> Krzysztof
>>
^ permalink raw reply
* [PATCH net-next v2 0/2] net: phy: Add Maxio MAE0621A support
From: Liu Changjie @ 2026-07-17 3:39 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
Add a binding and PHY driver for the Maxio MAE0621A Gigabit Ethernet
PHY. The driver matches the exact PHY ID and optionally selects a
125 MHz clock on CLKOUT. When the property is absent, the driver
preserves the hardware strap or bootloader setting.
This was tested on the LCKFB Taishan Pi 3M. With the PHY's default
CLKOUT configuration, the RK3576 GMAC negotiated a 1 Gbit/s link but
the data path did not work. A read-modify-write of page 0xa43,
register 0x19, setting bits 0 and 11 produced a readback value of
0x0823 and restored the data path without changing the RGMII delays.
The readback also confirmed that the unrelated set bits were
preserved.
Only the 125 MHz setting has been exercised on hardware and only that
value is exposed by this series. The 0 and 25 MHz choices from the
initial draft have been removed.
Public documentation for the MAE0621A register is not available. The
exact definitions of page 0xa43, register 0x19 bits 0 and 11, their
reset defaults, and whether a soft reset is required after changing
them still need confirmation from Maxio. The register programming in
this series is therefore supported by the hardware A/B result, not by
a public datasheet citation.
Hardware tests with the 125 MHz setting:
- all supported 10/100/1000 Mbit/s link modes
- 100 ICMP packets in each direction with no loss
- 936/934 Mbit/s host-to-board iperf3, no retransmits
- 943/941 Mbit/s board-to-host iperf3, no retransmits
- link unplug/replug and a normal reboot, followed by another 100 ICMP
packets in each direction with no loss
- no RX errors, missed packets, carrier errors or collisions
Static tests on net-next commit f6f3b36c15ed:
- dt_binding_check with dtschema 2026.6
- W=1 arm64 defconfig build of drivers/net/phy/maxio.o with GCC 10.3
- W=1 arm64 allmodconfig build of drivers/net/phy/maxio.o with GCC 10.3
- git diff --check and checkpatch.pl
Changes in v2:
- Extend hardware validation to all supported 10/100/1000 Mbit/s link
modes.
- Keep the binding limited to the tested 125 MHz setting. CLKOUT-disable
support can be added later after its register behavior is documented
and tested.
- No binding or driver code changes.
Link: https://lore.kernel.org/r/MN0PR19MB6091CD5A84D2DA5DACF434DAACF92@MN0PR19MB6091.namprd19.prod.outlook.com [v1]
Liu Changjie (2):
dt-bindings: net: Add Maxio MAE0621A PHY
net: phy: Add support for the Maxio MAE0621A
.../bindings/net/maxio,mae0621a.yaml | 38 +++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/net/phy/Kconfig | 8 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/maxio.c | 103 ++++++++++++++++++
5 files changed, 152 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
create mode 100644 drivers/net/phy/maxio.c
base-commit: f6f3b36c15ed44de1fbb44e645e4fae8c4a4453e
--
2.55.0
^ permalink raw reply
* Re: [PATCH v7 03/18] media: iris: drop IRIS_FMT_foo enumeration
From: Vishnu Reddy @ 2026-07-17 3:38 UTC (permalink / raw)
To: Dmitry Baryshkov, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260709-iris-ar50lt-v7-3-76af9dd4d1f6@oss.qualcomm.com>
On 7/9/2026 7:11 PM, Dmitry Baryshkov wrote:
> The IRIS_FMT_foo defines are only used for indexing values in the format
> enumeration arrays. However this kind of enumeration doesn't follow the
> V4L2 logic (which expects an array with consequtive indexing rather
> than a sparse array) and complicates adding support for platforms which
> support different sets of formats. Drop this enumeration and use flat
> lists of supported formats.
>
> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_instance.h | 14 --------------
> drivers/media/platform/qcom/iris/iris_platform_vpu2.c | 6 +++---
> drivers/media/platform/qcom/iris/iris_platform_vpu3x.c | 8 ++++----
> drivers/media/platform/qcom/iris/iris_vdec.c | 8 ++++----
> drivers/media/platform/qcom/iris/iris_venc.c | 8 ++++----
> 5 files changed, 15 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_instance.h b/drivers/media/platform/qcom/iris/iris_instance.h
> index a770331d1675..ffdbbd20901a 100644
> --- a/drivers/media/platform/qcom/iris/iris_instance.h
> +++ b/drivers/media/platform/qcom/iris/iris_instance.h
> @@ -17,20 +17,6 @@
>
> struct iris_hfi_session_ops;
>
> -enum iris_fmt_type_out {
> - IRIS_FMT_H264,
> - IRIS_FMT_HEVC,
> - IRIS_FMT_VP9,
> - IRIS_FMT_AV1,
> -};
> -
> -enum iris_fmt_type_cap {
> - IRIS_FMT_NV12,
> - IRIS_FMT_QC08C,
> - IRIS_FMT_TP10,
> - IRIS_FMT_QC10C,
> -};
> -
> /**
> * struct iris_inst - holds per video instance parameters
> *
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu2.c b/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> index 961dce2e6aa9..ba91672df1bb 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> @@ -35,9 +35,9 @@ static const struct iris_firmware_desc iris_vpu20_p4_gen1_desc = {
> };
>
> static const u32 iris_fmts_vpu2_dec[] = {
> - [IRIS_FMT_H264] = V4L2_PIX_FMT_H264,
> - [IRIS_FMT_HEVC] = V4L2_PIX_FMT_HEVC,
> - [IRIS_FMT_VP9] = V4L2_PIX_FMT_VP9,
> + V4L2_PIX_FMT_H264,
> + V4L2_PIX_FMT_HEVC,
> + V4L2_PIX_FMT_VP9,
> };
>
> static struct platform_inst_caps platform_inst_cap_vpu2 = {
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> index 74626b35d9cb..7098b652c117 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> @@ -49,10 +49,10 @@ static const struct iris_firmware_desc iris_vpu35_p4_gen2_desc = {
> };
>
> static const u32 iris_fmts_vpu3x_dec[] = {
> - [IRIS_FMT_H264] = V4L2_PIX_FMT_H264,
> - [IRIS_FMT_HEVC] = V4L2_PIX_FMT_HEVC,
> - [IRIS_FMT_VP9] = V4L2_PIX_FMT_VP9,
> - [IRIS_FMT_AV1] = V4L2_PIX_FMT_AV1,
> + V4L2_PIX_FMT_H264,
> + V4L2_PIX_FMT_HEVC,
> + V4L2_PIX_FMT_VP9,
> + V4L2_PIX_FMT_AV1,
> };
>
> static const struct icc_info iris_icc_info_vpu3x[] = {
> diff --git a/drivers/media/platform/qcom/iris/iris_vdec.c b/drivers/media/platform/qcom/iris/iris_vdec.c
> index 9e228b70420e..4c8bc7aac135 100644
> --- a/drivers/media/platform/qcom/iris/iris_vdec.c
> +++ b/drivers/media/platform/qcom/iris/iris_vdec.c
> @@ -63,10 +63,10 @@ int iris_vdec_inst_init(struct iris_inst *inst)
> }
>
> static const u32 iris_vdec_formats_cap[] = {
> - [IRIS_FMT_NV12] = V4L2_PIX_FMT_NV12,
> - [IRIS_FMT_QC08C] = V4L2_PIX_FMT_QC08C,
> - [IRIS_FMT_TP10] = V4L2_PIX_FMT_P010,
> - [IRIS_FMT_QC10C] = V4L2_PIX_FMT_QC10C,
> + V4L2_PIX_FMT_NV12,
> + V4L2_PIX_FMT_QC08C,
> + V4L2_PIX_FMT_P010,
> + V4L2_PIX_FMT_QC10C,
> };
>
> static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
> diff --git a/drivers/media/platform/qcom/iris/iris_venc.c b/drivers/media/platform/qcom/iris/iris_venc.c
> index a945992f63aa..16c52ad07e2c 100644
> --- a/drivers/media/platform/qcom/iris/iris_venc.c
> +++ b/drivers/media/platform/qcom/iris/iris_venc.c
> @@ -80,13 +80,13 @@ int iris_venc_inst_init(struct iris_inst *inst)
> }
>
> static const u32 iris_venc_formats_cap[] = {
> - [IRIS_FMT_H264] = V4L2_PIX_FMT_H264,
> - [IRIS_FMT_HEVC] = V4L2_PIX_FMT_HEVC,
> + V4L2_PIX_FMT_H264,
> + V4L2_PIX_FMT_HEVC,
> };
>
> static const u32 iris_venc_formats_out[] = {
> - [IRIS_FMT_NV12] = V4L2_PIX_FMT_NV12,
> - [IRIS_FMT_QC08C] = V4L2_PIX_FMT_QC08C,
> + V4L2_PIX_FMT_NV12,
> + V4L2_PIX_FMT_QC08C,
> };
>
> static bool check_format(struct iris_inst *inst, u32 pixfmt, u32 type)
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v9 0/2] media: iris: add support for purwa platform
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Wangao Wang
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Dmitry Baryshkov, Krzysztof Kozlowski
In-Reply-To: <20260713-enable_iris_on_purwa-v9-0-633d7b87f0c9@oss.qualcomm.com>
On Mon, 13 Jul 2026 18:17:25 +0800, Wangao Wang wrote:
> This series enables the Iris video codec on purwa, allowing purwa to
> use hardware‑accelerated video encoding and decoding.
>
> The Iris codec on purwa is nearly identical to the one on hamoa(X1E),
> except that it requires one additional clock and uses a different OPP
> table.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: purwa: Override Iris clocks and operating points
commit: 43899c55d79baef54652ec3310683da304706fd5
[2/2] arm64: dts: qcom: purwa-iot-som: enable video
commit: b66ca23dd964f78eb9ed0207ed0909fd9e8c27e1
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: konradybcio, Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
bod, mchehab, elder, andrew+netdev, davem, edumazet, kuba, pabeni,
jjohnson, mathieu.poirier, trilokkumar.soni, mukesh.ojha,
pavan.kondeti, jorge.ramirez, tonyh, vignesh.viswanathan,
srinivas.kandagatla, amirreza.zarrabi, jenswi, op-tee, apurupa,
skare, linux-kernel, Sumit Garg
In-Reply-To: <20260702115835.167602-1-sumit.garg@kernel.org>
On Thu, 02 Jul 2026 17:28:16 +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> [...]
Applied, thanks!
[11/14] net: ipa: Switch to generic PAS TZ APIs
commit: 85b88ceeeeb7bb93cd0af7ccaf2a4b010d5bc5c6
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: qcom: Document Hawi SoC and its reference boards
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mukesh Ojha
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260617151602.2018579-1-mukesh.ojha@oss.qualcomm.com>
On Wed, 17 Jun 2026 20:46:02 +0530, Mukesh Ojha wrote:
> Add Hawi SoC and its reference boards to the Qualcomm binding.
>
>
Applied, thanks!
[1/1] dt-bindings: arm: qcom: Document Hawi SoC and its reference boards
commit: ff24f055eb3e1f617e5790bf07c4c71aeef10b0d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: sram: Document qcom,shikra-imem compatible
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Komal Bajaj
Cc: devicetree, linux-kernel
In-Reply-To: <20260430-shikra-imem-binding-v1-1-c6976239f90f@oss.qualcomm.com>
On Thu, 30 Apr 2026 18:08:04 +0530, Komal Bajaj wrote:
> Add compatible for Shikra SoC IMEM.
>
>
Applied, thanks!
[1/1] dt-bindings: sram: Document qcom,shikra-imem compatible
commit: 26ead60b1a2722627759dc8c279ed336826bb5e1
Please make sure to Cc linux-arm-msm@vger.kernel.org, so changes like this
shows up in my inbox.
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] SM8450 QoL changes (dts)
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Esteban Urrutia
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
Dmitry Baryshkov
In-Reply-To: <20260711-sm8450-qol-dts-v2-0-5eb2e86468c5@proton.me>
On Sat, 11 Jul 2026 23:12:26 -0400, Esteban Urrutia wrote:
> These patches focus on correcting some details on the DTS for the SM8450
> SoC.
>
>
Applied, thanks!
[1/2] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
commit: 0ed8261e0ebdac5f1f08dcbfc209efe36937ed2d
[2/2] arm64: dts: qcom: sm8450: Add mode-switch property to qmpphy
commit: 8a2b4481b66c802af293e55eee07406971d5aa7b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] clk: qcom: gcc-glymur: Tie the CX power domain to controller
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Taniya Das, Konrad Dybcio, Maulik Shah,
Dmitry Baryshkov, Jyothi Kumar Seerapu, Konrad Dybcio,
Brian Masney, Abel Vesa
Cc: Krzysztof Kozlowski, Sibi Sankar, Pankaj Patil, Akhil P Oommen,
linux-arm-msm, linux-clk, devicetree, linux-kernel,
Jishnu Prakash, Raviteja Laggyshetty, Kamal Wadhwa, Qiang Yu,
Manaf Meethalavalappu Pallikunhi, Abel Vesa
In-Reply-To: <20260715-glymur-fix-gcc-cx-scaling-v3-0-72eb5adad156@oss.qualcomm.com>
On Wed, 15 Jul 2026 16:29:13 +0300, Abel Vesa wrote:
> The suggestion of having the CX power domain tied up to the GCC
> controller started here:
>
> https://lore.kernel.org/lkml/fe210f0b-692b-4c45-afc4-fc2bc5e57854@oss.qualcomm.com/
>
> and then, for Glymur, it has been brought up here as well:
>
> [...]
Applied, thanks!
[1/3] dt-bindings: clock: qcom: glymur-gcc: Add missing CX power domain
commit: d22a37e9fba7838cdcb8c55b913b1a37a7a4a198
[2/3] clk: qcom: gcc-glymur: Enable runtime PM
commit: 8d4f342369d0d77f32a0211692442d3b6d455872
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza-mtp: Enable touchscreen
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Abel Vesa
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260708-dts-qcom-eliza-mtp-enable-ts-v1-1-372020a7a86b@oss.qualcomm.com>
On Wed, 08 Jul 2026 13:18:26 +0300, Abel Vesa wrote:
> The Eliza MTP uses a Goodix GT9916 touchscreen controller connected
> over SPI.
>
> Describe the controller, its power supply, interrupt and reset GPIOs to
> enable touchscreen support.
>
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: eliza-mtp: Enable touchscreen
commit: f61fdd70f112ec5226f7adde3c29cf7aa55c6a42
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v4 9/9] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY
From: Qiang Yu @ 2026-07-17 3:02 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <f83556e7-dbb1-4926-a2a0-4690cdbad941@oss.qualcomm.com>
On Fri, Jul 10, 2026 at 03:25:37PM +0200, Konrad Dybcio wrote:
> On 7/10/26 3:11 PM, Qiang Yu wrote:
> > On Fri, Jul 10, 2026 at 10:44:20AM +0200, Konrad Dybcio wrote:
> >> On 7/10/26 4:19 AM, Qiang Yu wrote:
> >>> On Mon, Jun 29, 2026 at 11:20:07AM +0200, Konrad Dybcio wrote:
> >>>> On 6/29/26 7:05 AM, Qiang Yu wrote:
> >>>>> On Wed, Jun 17, 2026 at 01:19:49PM +0200, Konrad Dybcio wrote:
> >>>>>> On 5/19/26 7:47 AM, Qiang Yu wrote:
> >>>>>>> Glymur PCIe3 uses a single shared Gen5x8 QMP PHY block. Model PCIe3a and
> >>>>>>> PCIe3b as consumers of that shared PHY provider instead of separate PHY
> >>>>>>> nodes.
>
> [...]
>
> >>>>>>> + linux,pci-domain = <3>;
> >>>>>>> + num-lanes = <8>;
> >>>>>>
> >>>>>> Is it fine to keep num-lanes 8 here even for configurations with
> >>>>>> bifurcated PHY?
> >>>>>>
> >>>>>> I would assume so, given essentially this is a x8 host, whose 4
> >>>>>> lanes may simply be effectively NC
> >>>>>>
> >>>>> Actually, on existing platforms, the PCIe3a and PCIe3b controllers are
> >>>>> never enabled at the same time. When PCIe3a is exposed, it is always in an
> >>>>> x8 slot. But if we have a x4+x4 platform in future, we can simply override
> >>>>> num-lanes to 4 in the board.dts.
> >>>>
> >>>> My question is whether that will be necessary - if yes, sure, we
> >>>> can do it, but if not, we can conclude on this early and not have
> >>>> to fight over it in a couple months
> >>>>
> >>> I think we do need to override it in that case. If both PCIe3a and PCIe3b
> >>> are enabled in x4+x4 mode but PCIe3a keeps num-lanes = <8>, userspace
> >>> will see an 8-lane slot. If an x8-capable EP is connected to that slot,
> >>> both ends will advertise x8 support, but the link is up at x4. That looks
> >>> like a genuine bug from the user's point of view.
> >>
> >> Do we know what's advertised on x86 PCs with bifurcated lanes?
> >>
> > On QCB, it advertise x8. On CRD, PCIe3a is hidden.
>
> No no, I meant to ask whether we know what the userspace gets to see on
> e.g. an AMD system with a bifurcated slot. I would expect that LnkCap
> may report a different value, but not necessarily. I would assume we
> should probably mimic whatever that does, unless the spec takes a
> stance on what should be done.
>
I don't have any AMD/Intel hardware with a bifurcated slot at hand,
and I couldn't find an lspci example showing what LnkCap reports in
that case either, so I can't confirm what x86 does here.
But can you elaborate on what is the benefits to set it to 8 in x4+x4
mode?
- Qiang Yu
^ permalink raw reply
* Re: [PATCH 4/4] hwmon: (adt7470) Add thermal zone sensor support
From: Luiz Angelo Daros de Luca @ 2026-07-17 2:48 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-hwmon,
devicetree, linux-kernel
In-Reply-To: <091279bb-391e-4c0a-8ecc-a51f95be3f27@roeck-us.net>
> Detailed explanation why HWMON_C_REGISTER_TZ does not work or is
> insufficient goes here and into the driver code as comment.
No need to explain anything. I was just unaware of the existence of
HWMON_C_REGISTER_TZ.
You are absolutely right. I'll refactor the driver to use it and make
the code much cleaner. Thanks!
Regards,
Luiz
^ permalink raw reply
* Re: [PATCH v5 3/6] pwm: Add rockchip PWMv4 driver
From: Damon Ding @ 2026-07-17 2:38 UTC (permalink / raw)
To: Uwe Kleine-König, Nicolas Frattaroli
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Lee Jones, William Breathitt Gray, kernel, Jonas Karlman,
Alexey Charkov, linux-rockchip, linux-pwm, devicetree,
linux-arm-kernel, linux-kernel, linux-iio
In-Reply-To: <alDK7JahbqYpwQmZ@monoceros>
Hi Uwe,
On 7/10/2026 7:02 PM, Uwe Kleine-König wrote:
> Hello Nicolas,
>
> On Mon, Apr 20, 2026 at 03:52:40PM +0200, Nicolas Frattaroli wrote:
>> [...]
>> +/**
>> + * rockchip_pwm_v4_round_single - convert a PWM parameter to hardware
>> + * @rate: clock rate of the PWM clock, as per clk_get_rate
>> + * Assumed to be <= 1GHz for overflow considerations
>> + * @in_val: parameter in nanoseconds to convert
>> + *
>> + * Returns the rounded value, saturating at U32_MAX if too large
>> + */
>> +static u32 rockchip_pwm_v4_round_single(unsigned long rate, u64 in_val)
>
> very picky: if you name this function rockchip_pwm_v4_ns_to_ticks it
> becomes clearer what the purpose is.
>
>> +{
>> + u64 tmp;
>> +
>> + tmp = mul_u64_u64_div_u64(rate, in_val, NSEC_PER_SEC);
>> + if (tmp > U32_MAX)
>> + tmp = U32_MAX;
>> +
>> + return tmp;
>> +}
>> +
>> +/**
>> + * rockchip_pwm_v4_round_params - convert PWM parameters to hardware
>> + * @rate: PWM clock rate to do the calculations at
>> + * @wf: pointer to the generic &struct pwm_waveform input parameters
>> + * @wfhw: pointer to the hardware-specific &struct rockchip_pwm_v4_wf output
>> + * parameters that the results will be stored in
>> + *
>> + * Convert nanosecond-based duty/period/offset parameters to the PWM hardware's
>> + * native rounded representation in number of cycles at clock rate @rate. Should
>> + * any of the input parameters be out of range for the hardware, the
>> + * corresponding output parameter is the maximum permissible value for said
>> + * parameter with considerations to the others.
>> + */
>> +static void rockchip_pwm_v4_round_params(unsigned long rate,
>> + const struct pwm_waveform *wf,
>> + struct rockchip_pwm_v4_wf *wfhw)
>> +{
>> + wfhw->period = rockchip_pwm_v4_round_single(rate, wf->period_length_ns);
>> +
>> + wfhw->duty = rockchip_pwm_v4_round_single(rate, wf->duty_length_ns);
>> +
>> + /* As per TRM, PWM_OFFSET: "The value ranges from 0 to (period-duty)" */
>
> Have you tried what happens if you break this rule? That seems like a
> very arbitrary restriction that might just originate from the
> documentation author.
>
According to the IC design, any offset value larger than (period - duty)
will be clamped to (period - duty) by the hardware internally. Given
this hardware limitation, the validation check Nicolas introduced does
serve a practical purpose.
>> + wfhw->offset = rockchip_pwm_v4_round_single(rate, wf->duty_offset_ns);
>> + if (!wfhw->period) /* Don't underflow when pwm disabled */
>> + wfhw->offset = 0;
>> + else if (wfhw->offset > wfhw->period - wfhw->duty)
>> + wfhw->offset = wfhw->period - wfhw->duty;
>
> You don't enforce wfhw->period >= wfhw->duty, which however seems like a
> reasonable restriction. When knowing that you can drop the explicit
> check for !wfhw->period and just keep the else-if branch.
>
>> +}
>> [...]
>> +static int rockchip_pwm_v4_write_wf(struct pwm_chip *chip, struct pwm_device *pwm,
>> + const void *_wfhw)
>> +{
>> + struct rockchip_pwm_v4 *pc = to_rockchip_pwm_v4(chip);
>> + const struct rockchip_pwm_v4_wf *wfhw = _wfhw;
>> + bool was_enabled;
>> + int ret;
>> +
>> + ret = mfpwm_acquire(pc->pwmf);
>> + if (ret)
>> + return ret;
>> +
>> + was_enabled = rockchip_pwm_v4_is_enabled(mfpwm_reg_read(pc->pwmf->base,
>> + PWMV4_REG_ENABLE));
>> +
>> + /*
>> + * "But Nicolas", you ask with valid concerns, "why would you enable the
>> + * PWM before setting all the parameter registers?"
>> + *
>> + * Excellent question, Mr. Reader M. Strawman! The RK3576 TRM Part 1
>> + * Section 34.6.3 specifies that this is the intended order of writes.
>> + * Doing the PWM_EN and PWM_CLK_EN writes after the params but before
>> + * the CTRL_UPDATE_EN, or even after the CTRL_UPDATE_EN, results in
>> + * erratic behaviour where repeated turning on and off of the PWM may
>> + * not turn it off under all circumstances. This is also why we don't
>> + * use relaxed writes; it's not worth the footgun.
>
> I wonder if it's worth however to delay setting PWMV4_CTRL_UPDATE_EN
> until after the clkrate is handled to (maybe) prevent glitches?
I agree with your point. For the PWM enable sequence, we should enable
the PWM dclk before any register operations. Conversely, when disabling
PWM, it's better to carry out dclk disabling only after all register
accesses are fully completed.
>
>> + */
>> + if (wfhw->rate)
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_ENABLE,
>> + FIELD_PREP_WM16(PWMV4_EN_BOTH_MASK,
>> + PWMV4_EN_BOTH_MASK));
>> + else
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_ENABLE,
>> + FIELD_PREP_WM16(PWMV4_EN_BOTH_MASK, 0));
>> +
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_PERIOD, wfhw->period);
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_DUTY, wfhw->duty);
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_OFFSET, wfhw->offset);
>> +
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_CTRL, PWMV4_CTRL_CONT_FLAGS);
>> +
>> + /* Commit new configuration to hardware output. */
>> + mfpwm_reg_write(pc->pwmf->base, PWMV4_REG_ENABLE,
>> + PWMV4_CTRL_UPDATE_EN);
>> +
>> + if (wfhw->rate) {
>> + if (!was_enabled) {
>> + dev_dbg(&chip->dev, "Enabling PWM output\n");
>> + ret = clk_enable(pc->pwmf->core);
>> + if (ret)
>> + goto err_mfpwm_release;
>> + ret = clk_set_rate_exclusive(pc->pwmf->core, wfhw->rate);
>> + if (ret) {
>> + clk_disable(pc->pwmf->core);
>> + goto err_mfpwm_release;
>> + }
>> +
>> + /*
>> + * Output should be on now, acquire device to guarantee
>> + * exclusion with other device functions while it's on.
>> + *
>> + * It's highly unlikely that this fails, as mfpwm has
>> + * already been acquired before, and this is just a
>> + * usage counter increase. Not worth the added
>> + * complexity of clearing the PWMV4_REG_ENABLE again,
>> + * especially considering the CTRL_UPDATE_EN behaviour.
>> + */
>> + ret = mfpwm_acquire(pc->pwmf);
>> + if (ret) {
>> + clk_rate_exclusive_put(pc->pwmf->core);
>> + clk_disable(pc->pwmf->core);
>> + goto err_mfpwm_release;
>> + }
>> + }
>
> Can it happen that we have
>
> wfhw->rate && was_enabled && wfhw->rate != clk_get_rate()
>
> ?
>
>> + } else if (was_enabled) {
>> + dev_dbg(&chip->dev, "Disabling PWM output\n");
>> + clk_rate_exclusive_put(pc->pwmf->core);
>> + clk_disable(pc->pwmf->core);
>> + /* Output is off now, extra release to balance extra acquire */
>> + mfpwm_release(pc->pwmf);
>> + }
>> +
>> +err_mfpwm_release:
>> + mfpwm_release(pc->pwmf);
>> +
>> + return ret;
>> +}
>> [...]
>> +static int rockchip_pwm_v4_probe(struct platform_device *pdev)
>> +{
>> + struct rockchip_mfpwm_func *pwmf = dev_get_platdata(&pdev->dev);
>> + struct rockchip_pwm_v4 *pc;
>> + struct pwm_chip *chip;
>> + struct device *dev = &pdev->dev;
>> + int ret;
>> +
>> + /*
>> + * For referencing the PWM in the DT to work, we need the parent MFD
>> + * device's OF node.
>> + */
>> + dev->of_node_reused = true;
>> + device_set_node(dev, of_fwnode_handle(dev->parent->of_node));
>> +
>> + chip = devm_pwmchip_alloc(dev, 1, sizeof(*pc));
>> + if (IS_ERR(chip))
>> + return PTR_ERR(chip);
>> +
>> + pc = to_rockchip_pwm_v4(chip);
>> + pc->pwmf = pwmf;
>> +
>> + ret = mfpwm_acquire(pwmf);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "Couldn't acquire mfpwm in probe\n");
>> +
>> + if (!rockchip_pwm_v4_on_and_continuous(pc))
>> + mfpwm_release(pwmf);
>> + else {
>> + dev_dbg(dev, "PWM was already on at probe time\n");
>> + ret = clk_enable(pwmf->core);
>> + if (ret) {
>> + dev_err_probe(dev, ret, "Enabling pwm clock failed\n");
>> + goto err_mfpwm_release;
>> + }
>> + ret = clk_rate_exclusive_get(pc->pwmf->core);
>> + if (ret) {
>> + dev_err_probe(dev, ret, "Protecting pwm clock failed\n");
>> + goto err_clk_disable;
>> + }
>> + }
>> +
>> + platform_set_drvdata(pdev, chip);
>
> This is unused.
>
>> +
>> + chip->ops = &rockchip_pwm_v4_ops;
>> +
>> + ret = devm_pwmchip_add(dev, chip);
>> + if (ret) {
>> + dev_err_probe(dev, ret, "Failed to add PWM chip\n");
>> + if (rockchip_pwm_v4_on_and_continuous(pc))
>> + goto err_rate_put;
>> +
>> + return ret;
>> + }
>> +
>> + return 0;
>> +
>> +err_rate_put:
>> + clk_rate_exclusive_put(pwmf->core);
>> +err_clk_disable:
>> + clk_disable(pwmf->core);
>> +err_mfpwm_release:
>> + mfpwm_release(pwmf);
>> +
>> + return ret;
>> +}
>
> Best regards
> Uwe
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: hwmon: add binding for adi,adt7470
From: Luiz Angelo Daros de Luca @ 2026-07-17 2:33 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
de Luca
Cc: linux-hwmon, devicetree, linux-kernel
In-Reply-To: <20260716-adt7470_thermalzone-v1-1-cc55ef35edde@gmail.com>
> + "#cooling-cells":
> + const: 2
> + description: |
> + Cooling device exposing the 4 PWM channels.
Since "thermal/of: Support cooling device ID in cooling-spec", I could
be 2 or 3. I don't know if I should use enum [2, 3] or just go
directly to the new const: 3.
My test device has only the 0 channel in use and 2 is fine for now.
Sashiko also asked to require #pwm-cells, but it would mean to
implement a parser for that too. I don't know if it is worth it but I
can do it if needed.
Regards,
Luiz
^ permalink raw reply
* RE: [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568
From: Jiawen Wu @ 2026-07-17 2:22 UTC (permalink / raw)
To: 'Coia Prant', 'Andrew Lunn'
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, robh, krzk+dt,
heiko, netdev, linux-rockchip, devicetree, linux-arm-kernel,
linux-phy, 'Mengyuan Lou'
In-Reply-To: <CALj3r0jdkDEjpO+7NOTGs+wgukKvD=fzFn4ewpurxxPswCE5GA@mail.gmail.com>
On Wed, Jul 15, 2026 7:05 AM, Coia Prant wrote:
> Andrew Lunn <andrew@lunn.ch> 于2026年7月15日周三 06:44写道：
> >
> > On Wed, Jul 15, 2026 at 03:08:34AM +0800, Coia Prant wrote:
> > > Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> >
> > You do not appear to Cc: the Wangxun NIC people. It would be good to
> > have there comments on this change.
>
> I apologize; the output from get_maintainer.pl is very long. I’ve
> heard that having too many recipients can cause the PATCH to be
> rejected by the LKML mail server.
>
> I have added Wangxun maintainer (Jiawen Wu <jiawenwu@trustnetic.com>
> and Mengyuan Lou <mengyuanlou@net-swift.com>) to the CC list.
>
> > > Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > > Signed-off-by: Coia Prant <coiaprant@gmail.com>
> >
> > Please don't mix fixed and new code. Is this a real fix? Should it be
> > back ported to stable?
>
> I am not sure if this is a specific characteristic of Wangxun NICs, as
> I do not have any available for testing.
>
> The behavior of the Rockchip DW XPCS IP core matches what is described
> in the commit message (even though phylink brings the link to down
> based on the phydev link status).
>
> This appears to be a bug (at least on Rockchip platforms) or Wangxun
> NICs features.
>
> However, I cannot confirm whether Wangxun NICs behave the same way.
> Therefore, I have kept their code as is for now.
>
> Could a Wangxun NICs maintainer provide some feedback based on testing?
>
> If we can confirm that this is indeed a bug, I can submit a separate fix.
>
> I would greatly appreciate it.
>
> Thanks.
Hi Coia,
I have tested this patch and it works on Wangxun NICs, thanks.
The commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
is too long ago for me to recall exactly what that thought was.
The log shows:
"On this device, CL37_ANSGM_STS (bit[4:1] of VR_MII_AN_INTR_STS) indicates
the status received from remote link during the auto-negotiation, and
self-clear after the auto-negotiation is complete.
Meanwhile, CL37_ANCMPLT_INTR will be set to 1, to indicate CL37 AN is
complete. So add another way to get the state for CL37 SGMII."
I tried to reproduce this issue, but it didn't seem to exist.
In the current logic:
link up -> read status from CL37_ANSGM_STS -> CL37_ANCMPLT_INTR not clear
link down -> read status from BMCR -> CL37_ANCMPLT_INTR clear
It also works, although CL37_ANCMPLT_INTR is not cleared every time, and AN
restart is absent. But BMCR looks like it only wants to be return as 0, it is
weird.
So I think Wangxun NICs also can be applied to general code as well, for
getting state in C37 SGMII mode.
However, I am wondering whether CL37_ANCMPLT_INTR clear and ANRESTART are
necessary.
^ permalink raw reply
* Re: [PATCH v4 2/4] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: sashiko-bot @ 2026-07-17 2:20 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260716021932.20037-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing driver implementation for 'altr,socfpga-stmmac-agilex5-tsn' results in double RGMII delays and broken networking on gmac1.
--
--- Patch [2]: [PATCH v4 2/4] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board ---
commit ff8022a3fa72ba16d067ef0799f67eb51b957387
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
This commit adds the device tree for the Intel SoCFPGA Agilex5 SoCDK TSN
Config2 board variant, enabling gmac1 as a TSN port. The commit message
states that a board-specific compatible string is used so the driver can
detect the converter and strip the delay bits before configuring the PHY.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
[ ... ]
> +&gmac1 {
> + status = "okay";
> + compatible = "altr,socfpga-stmmac-agilex5-tsn",
> + "altr,socfpga-stmmac-agilex5",
> + "snps,dwxgmac-2.10";
> + phy-mode = "rgmii-id";
[Severity: Medium]
Is the driver support for "altr,socfpga-stmmac-agilex5-tsn" included in
another patch in this series, or already present in the tree?
If the driver implementation is missing, OF will fall back to
"altr,socfpga-stmmac-agilex5". Since the fallback lacks the board-specific
logic to strip the delay bits from the "rgmii-id" phy-mode before passing it
to the PHY driver, will this cause both the PHY driver and the FPGA soft IP
to independently add clock delays? This double-delaying of the RGMII clocks
could violate RGMII timing specifications and cause broken networking on
the gmac1 interface.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716021932.20037-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2
^ permalink raw reply
* [PATCH 2/2] dt-bindings: can: xilinx_can: Document phys property
From: Harini T @ 2026-07-17 2:14 UTC (permalink / raw)
To: mkl, mailhol, robh, krzk+dt, conor+dt, michal.simek,
appana.durga.kedareswara.rao
Cc: linux-can, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260717021415.2234865-1-harini.t@amd.com>
The Xilinx CAN and CANFD controllers can be connected to an external
CAN transceiver on the board. That connection is described with the
standard "phys" property on the controller node, pointing to a CAN
transceiver PHY node which models the transceiver and its control
lines (for example the standby/enable signals).
Describe the optional "phys" property (a single transceiver PHY) so
the on-board CAN transceiver can be described in the device tree.
Signed-off-by: Harini T <harini.t@amd.com>
---
Documentation/devicetree/bindings/net/can/xilinx,can.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
index e705c719f7b5..18015e60fd6d 100644
--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
@@ -53,6 +53,9 @@ properties:
$ref: /schemas/types.yaml#/definitions/flag
description: CAN TX_OL, TX_TL and RX FIFOs have ECC support(AXI CAN)
+ phys:
+ maxItems: 1
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] MAINTAINERS: Replace maintainer for Xilinx CAN driver
From: Harini T @ 2026-07-17 2:14 UTC (permalink / raw)
To: mkl, mailhol, robh, krzk+dt, conor+dt, michal.simek,
appana.durga.kedareswara.rao
Cc: linux-can, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260717021415.2234865-1-harini.t@amd.com>
Replace Appana Durga Kedareswara rao with Harini T as the maintainer
of the Xilinx CAN driver. Kedar is no longer maintaining it.
Signed-off-by: Harini T <harini.t@amd.com>
---
Documentation/devicetree/bindings/net/can/xilinx,can.yaml | 2 +-
MAINTAINERS | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
index 40835497050a..e705c719f7b5 100644
--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
@@ -8,7 +8,7 @@ title:
Xilinx CAN and CANFD controller
maintainers:
- - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
+ - Harini T <harini.t@amd.com>
properties:
compatible:
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2ffd9d37d5..db619dcaddbf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28874,7 +28874,7 @@ F: Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
F: drivers/net/ethernet/xilinx/xilinx_axienet*
XILINX CAN DRIVER
-M: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
+M: Harini T <harini.t@amd.com>
L: linux-can@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/can/xilinx,can.yaml
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] dt-bindings: can: xilinx_can: Document phys and update maintainer
From: Harini T @ 2026-07-17 2:14 UTC (permalink / raw)
To: mkl, mailhol, robh, krzk+dt, conor+dt, michal.simek,
appana.durga.kedareswara.rao
Cc: linux-can, devicetree, linux-arm-kernel, linux-kernel
The Xilinx CAN and CANFD controllers can be connected to an external
CAN transceiver on the board, described from the controller node via
the standard "phys" property. This binding-only series documents that
property and updates the Xilinx CAN driver maintainer.
Patch 1 replaces the maintainer of the Xilinx CAN driver in both the
MAINTAINERS entry and the binding's maintainers list.
Patch 2 documents the optional "phys" property (a single transceiver
PHY).
Harini T (2):
MAINTAINERS: Replace maintainer for Xilinx CAN driver
dt-bindings: can: xilinx_can: Document phys property
Documentation/devicetree/bindings/net/can/xilinx,can.yaml | 5 ++++-
MAINTAINERS | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC
From: Bjorn Andersson @ 2026-07-17 2:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Maulik Shah, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, linux-arm-msm, linux-kernel,
devicetree, Konrad Dybcio
In-Reply-To: <20260716-starling-of-heavenly-symmetry-09a73a@quoll>
On Thu, Jul 16, 2026 at 09:59:44AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Jul 15, 2026 at 06:52:01PM +0530, Maulik Shah wrote:
> > X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
> > register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
> > Workaround hardware register bug on X1E80100") is already fixed in
> > X1P42100 silicon.
> >
> > X1E80100 compatible forces the software workaround. Use the X1P42100
> > specific compatible string for the PDC node to remove the workaround.
> >
> > Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD")
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/purwa.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
>
> Why does the DT change appear in the middle of the patchset? Please read
> submitting patches documents - both of them - and maintainer-soc
> profile.
>
I thought I had figured it out, but I'm not sure anymore.
The claim from the cover letter is that patch 1 and 2 are completely
independent, but patch 3 depends on Bartosz's thank you letter [2] that
arrived a week before this series was sent out.
We're not merging the three changes through the same tree and there's no
expressed dependency between patch 2 and 3 (only implicitly by the order
in the series). But as Konrad points out, in-between patch 2 and 3 we
would not enable the secondary GPIO in the PDC driver, so Purwa would
have broken GPIOs for a while (not ok). I think merging them in the
opposite order would be what we want (i.e. 1, 3, then 2)
But this series implies that Purwa has been broken from the start - that
the PDC driver has always operated on the wrong registers.
Perhaps the impact of this was limited as there's not that many direct
&pdc references in the DT, but the patch that Bartosz's thank-you email
was sent for got merged as 77fbc756d9cb ("Revert "pinctrl: qcom:
x1e80100: Bypass PDC wakeup parent for now""), and that would make a lot
more use of the PDC.
So while nothing in this series states it, it sounds like Purwa might be
completely broken right now and this series aims to fix it?
It's not clear to me why the driver change doesn't have a Fixes tag, it
seems like the patch that introduced x1e_quirk was broken and should be
marked as Fixes.
[2] https://lore.kernel.org/linux-arm-msm/CAMRc=MeU0QuRozMscv02M59+a66S05Jm18CyvNE-qSYrY=S7hQ@mail.gmail.com/
Regards,
Bjorn
> Best regards,
> Krzysztof
>
^ 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