* [PATCH v2] phy: Add USB3 PHY support to Google Tensor SoC USB PHY driver
From: RD Babiera @ 2026-06-22 17:52 UTC (permalink / raw)
To: vkoul, peter.griffin, andre.draszik, tudor.ambarus, p.zabel,
neil.armstrong
Cc: badhri, linux-arm-kernel, linux-samsung-soc, linux-phy,
linux-kernel, RD Babiera
Add USB3 PHY support for the Google Tensor G5 USB PHY driver.
This patch adds functionality for the usb3_tca register, usb3 clock,
and usb3 reset as defined in google,lga-usb-phy.yaml. Kconfig now lists
USB SuperSpeed support.
Refactor the probe sequence to initialize the USB2 and USB3 PHYs, and then
initialize clocks and resets for both PHYs afterwards.
Refactor set_vbus_valid to reduce duplicated code.
Implement USB3 phy_ops for phy_init, phy_exit, and phy_power_on.
combo_phy_state enum is added to track PHY bringup state across
PHY API calls.
Signed-off-by: RD Babiera <rdbabiera@google.com>
---
Changes since v1:
* Removed mix of goto-based and scope-based cleanup from usb3 phy_init
* Removed unused usb3_core resource from probe
* Added combo_phy_state enum to interally track ComboPHY bringup state
to allow google_usb_set_orientation() to change TCA orientation.
* Modify Kconfig documentation to reflect SuperSpeed support
---
drivers/phy/Kconfig | 2 +-
drivers/phy/phy-google-usb.c | 379 +++++++++++++++++++++++++++++++----
2 files changed, 346 insertions(+), 35 deletions(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b7d..d2d401129af7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -100,7 +100,7 @@ config PHY_GOOGLE_USB
the G5 generation (Laguna). This driver provides the PHY interfaces
to interact with the SNPS eUSB2 and USB 3.2/DisplayPort Combo PHY,
both of which are integrated with the DWC3 USB DRD controller.
- This driver currently supports USB high-speed.
+ This driver currently supports USB high-speed and SuperSpeed.
config USB_LGM_PHY
tristate "INTEL Lightning Mountain USB PHY Driver"
diff --git a/drivers/phy/phy-google-usb.c b/drivers/phy/phy-google-usb.c
index ab20bc20f19e..c6f4d8283e7c 100644
--- a/drivers/phy/phy-google-usb.c
+++ b/drivers/phy/phy-google-usb.c
@@ -20,6 +20,7 @@
#include <linux/reset.h>
#include <linux/usb/typec_mux.h>
+/* USB_CFG_CSR */
#define USBCS_USB2PHY_CFG19_OFFSET 0x0
#define USBCS_USB2PHY_CFG19_PHY_CFG_PLL_FB_DIV GENMASK(19, 8)
@@ -28,11 +29,41 @@
#define USBCS_USB2PHY_CFG21_REF_FREQ_SEL GENMASK(15, 13)
#define USBCS_USB2PHY_CFG21_PHY_TX_DIG_BYPASS_SEL BIT(19)
+/* USBDP_TOP */
#define USBCS_PHY_CFG1_OFFSET 0x28
+#define USBCS_PHY_CFG1_PHY0_MPLLA_SSC_EN BIT(1)
+#define USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE GENMASK(11, 10)
+#define SRAM_BYPASS_MODE_BYPASS_FIRMWARE BIT(0)
+#define SRAM_BYPASS_MODE_BYPASS_CONTEXT BIT(1)
#define USBCS_PHY_CFG1_SYS_VBUSVALID BIT(17)
+#define USBDP_TOP_CFG_REG_OFFSET 0x44
+#define USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N BIT(0)
+
+#define PHY_POWER_CONFIG_REG1_OFFSET 0x48
+#define PHY_POWER_CONFIG_REG1_PG_MODE_EN BIT(1)
+#define PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG GENMASK(31, 14)
+#define UPCS_PIPE_CONFIG_ISO_CPM BIT(5)
+#define UPCS_PIPE_CONFIG_PG_MODE_STATIC BIT(6)
+#define UPCS_PIPE_CONFIG_LANE_RESET_NO_PG_EXIT BIT(9)
+
+/* USB3_TCA */
+#define TCA_INTR_STS_OFFSET 0x8
+#define TCA_INTR_STS_XA_ACT_EVT BIT(0)
+#define TCA_TCPC_OFFSET 0x14
+#define TCA_TCPC_MUX_CONTROL GENMASK(2, 0)
+#define TCA_TCPC_MUX_CONTROL_USB_ONLY 0x1
+#define TCA_TCPC_CONNECTOR_ORIENTATION BIT(3)
+#define TCA_TCPC_VALID BIT(4)
+#define TCA_PSTATE_0_OFFSET 0x50
+#define TCA_PSTATE_0_UPCS_LANE0_PHYSTATUS BIT(8)
+
+#define GPHY_TCA_DELAY_US 10
+#define GPHY_TCA_TIMEOUT_US 2500000
+
enum google_usb_phy_id {
GOOGLE_USB2_PHY,
+ GOOGLE_USB3_PHY,
GOOGLE_USB_PHY_NUM,
};
@@ -46,34 +77,152 @@ struct google_usb_phy_instance {
struct reset_control_bulk_data *rsts;
};
+struct google_usb_phy_config {
+ const char * const *clk_names;
+ unsigned int num_clks;
+ const char * const *rst_names;
+ unsigned int num_rsts;
+};
+
+static const char * const u2phy_clk_names[] = {
+ "usb2",
+ "usb2_apb",
+};
+static const char * const u3phy_clk_names[] = {
+ "usb3"
+};
+static const char * const u2phy_rst_names[] = {
+ "usb2",
+ "usb2_apb",
+};
+static const char * const u3phy_rst_names[] = {
+ "usb3"
+};
+
+static const struct google_usb_phy_config phy_configs[GOOGLE_USB_PHY_NUM] = {
+ [GOOGLE_USB2_PHY] = {
+ .clk_names = u2phy_clk_names,
+ .num_clks = ARRAY_SIZE(u2phy_clk_names),
+ .rst_names = u2phy_rst_names,
+ .num_rsts = ARRAY_SIZE(u2phy_rst_names),
+ },
+ [GOOGLE_USB3_PHY] = {
+ .clk_names = u3phy_clk_names,
+ .num_clks = ARRAY_SIZE(u3phy_clk_names),
+ .rst_names = u3phy_rst_names,
+ .num_rsts = ARRAY_SIZE(u3phy_rst_names),
+ },
+};
+
+/*
+ * combo_phy_state
+ * COMBO_PHY_IDLE: The ComboPHY has been torn down and USB3 has not completed
+ * bringup
+ * COMBO_PHY_INIT_DONE: The ComboPHY bringup sequence is complete.
+ * COMBO_PHY_TCA_READY: The PoR => NC transition is complete, and the TCA can be
+ * moved into USB.
+ */
+enum combo_phy_state {
+ COMBO_PHY_IDLE,
+ COMBO_PHY_INIT_DONE,
+ COMBO_PHY_TCA_READY,
+};
+
struct google_usb_phy {
struct device *dev;
struct regmap *usb_cfg_regmap;
unsigned int usb2_cfg_offset;
void __iomem *usbdp_top_base;
+ void __iomem *usb3_tca_base;
struct google_usb_phy_instance *insts;
/*
* Protect phy registers from concurrent access, specifically via
- * google_usb_set_orientation callback.
+ * google_usb_set_orientation callback. phy_mutex also protects
+ * concurrent access to phy_state.
*/
struct mutex phy_mutex;
struct typec_switch_dev *sw;
enum typec_orientation orientation;
+ enum combo_phy_state phy_state;
};
static void set_vbus_valid(struct google_usb_phy *gphy)
{
u32 reg;
- if (gphy->orientation == TYPEC_ORIENTATION_NONE) {
- reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ if (gphy->orientation == TYPEC_ORIENTATION_NONE)
reg &= ~USBCS_PHY_CFG1_SYS_VBUSVALID;
- writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
- } else {
- reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ else
reg |= USBCS_PHY_CFG1_SYS_VBUSVALID;
- writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
- }
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+}
+
+static void set_sram_bypass(struct google_usb_phy *gphy, u32 bypass)
+{
+ u32 reg;
+
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg &= ~USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE;
+ reg |= FIELD_PREP(USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE, bypass);
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+}
+
+static void set_pmgt_ref_clk_req_n(struct google_usb_phy *gphy, bool resume)
+{
+ u32 reg;
+
+ reg = readl(gphy->usbdp_top_base + USBDP_TOP_CFG_REG_OFFSET);
+ if (resume)
+ reg |= USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N;
+ else
+ reg &= ~USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N;
+ writel(reg, gphy->usbdp_top_base + USBDP_TOP_CFG_REG_OFFSET);
+}
+
+static int wait_tca_xa_ack(struct google_usb_phy *gphy)
+{
+ int ret;
+ u32 reg;
+
+ ret = readl_poll_timeout(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET,
+ reg, !!(reg & TCA_INTR_STS_XA_ACT_EVT),
+ GPHY_TCA_DELAY_US, GPHY_TCA_TIMEOUT_US);
+ if (ret)
+ dev_err(gphy->dev, "tca xa_ack timeout, ret=%d", ret);
+
+ return ret;
+}
+
+static int program_tca_locked(struct google_usb_phy *gphy)
+ __must_hold(&gphy->phy_mutex)
+{
+ int ret;
+ u32 reg;
+
+ reg = readl(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+ writel(reg, gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+
+ reg = readl(gphy->usb3_tca_base + TCA_TCPC_OFFSET);
+ reg &= ~TCA_TCPC_MUX_CONTROL;
+ reg |= FIELD_PREP(TCA_TCPC_MUX_CONTROL, TCA_TCPC_MUX_CONTROL_USB_ONLY);
+ if (gphy->orientation == TYPEC_ORIENTATION_REVERSE)
+ reg |= TCA_TCPC_CONNECTOR_ORIENTATION;
+ else
+ reg &= ~TCA_TCPC_CONNECTOR_ORIENTATION;
+ reg |= TCA_TCPC_VALID;
+ writel(reg, gphy->usb3_tca_base + TCA_TCPC_OFFSET);
+
+ ret = wait_tca_xa_ack(gphy);
+ dev_dbg(gphy->dev, "TCA switch %s, mux %lu, orientation %s",
+ ret ? "failed" : "success",
+ FIELD_GET(TCA_TCPC_MUX_CONTROL, reg),
+ FIELD_GET(TCA_TCPC_CONNECTOR_ORIENTATION, reg) ? "reverse" : "normal");
+
+ reg = readl(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+ writel(reg, gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+
+ return ret;
}
static int google_usb_set_orientation(struct typec_switch_dev *sw,
@@ -92,6 +241,9 @@ static int google_usb_set_orientation(struct typec_switch_dev *sw,
set_vbus_valid(gphy);
+ if (gphy->phy_state == COMBO_PHY_TCA_READY && orientation != TYPEC_ORIENTATION_NONE)
+ return program_tca_locked(gphy);
+
return 0;
}
@@ -161,6 +313,118 @@ static const struct phy_ops google_usb2_phy_ops = {
.exit = google_usb2_phy_exit,
};
+static int google_usb3_phy_init(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+ int ret = 0;
+ u32 reg;
+
+ dev_dbg(gphy->dev, "initializing usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ if (gphy->phy_state != COMBO_PHY_IDLE) {
+ dev_warn(gphy->dev, "usb3 phy init called when combo phy state is not idle");
+ return 0;
+ }
+
+ reg = readl(gphy->usbdp_top_base + PHY_POWER_CONFIG_REG1_OFFSET);
+ reg |= PHY_POWER_CONFIG_REG1_PG_MODE_EN;
+ reg &= ~PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG;
+ reg |= FIELD_PREP(PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG,
+ (UPCS_PIPE_CONFIG_ISO_CPM |
+ UPCS_PIPE_CONFIG_PG_MODE_STATIC |
+ UPCS_PIPE_CONFIG_LANE_RESET_NO_PG_EXIT));
+ writel(reg, gphy->usbdp_top_base + PHY_POWER_CONFIG_REG1_OFFSET);
+
+ set_vbus_valid(gphy);
+
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg |= USBCS_PHY_CFG1_PHY0_MPLLA_SSC_EN;
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+
+ set_sram_bypass(gphy, SRAM_BYPASS_MODE_BYPASS_FIRMWARE |
+ SRAM_BYPASS_MODE_BYPASS_CONTEXT);
+ set_pmgt_ref_clk_req_n(gphy, true);
+
+ ret = clk_bulk_prepare_enable(inst->num_clks, inst->clks);
+ if (ret)
+ return ret;
+
+ ret = reset_control_bulk_deassert(inst->num_rsts, inst->rsts);
+ if (ret) {
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+ return ret;
+ }
+
+ ret = readl_poll_timeout(gphy->usb3_tca_base + TCA_PSTATE_0_OFFSET,
+ reg, !(reg & TCA_PSTATE_0_UPCS_LANE0_PHYSTATUS),
+ GPHY_TCA_DELAY_US, GPHY_TCA_TIMEOUT_US);
+ if (ret) {
+ dev_err(gphy->dev, "wait for lane0 phystatus timed out");
+ reset_control_bulk_assert(inst->num_rsts, inst->rsts);
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+ return ret;
+ }
+
+ gphy->phy_state = COMBO_PHY_INIT_DONE;
+
+ return 0;
+}
+
+static int google_usb3_phy_exit(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+
+ dev_dbg(gphy->dev, "exiting usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ set_pmgt_ref_clk_req_n(gphy, false);
+ reset_control_bulk_assert(inst->num_rsts, inst->rsts);
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+
+ gphy->phy_state = COMBO_PHY_IDLE;
+
+ return 0;
+}
+
+static int google_usb3_phy_power_on(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+ int ret;
+
+ dev_dbg(gphy->dev, "power on usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ if (gphy->phy_state == COMBO_PHY_TCA_READY) {
+ dev_warn(gphy->dev, "usb3 phy already powered on");
+ return 0;
+ }
+
+ ret = wait_tca_xa_ack(gphy);
+ if (ret) {
+ dev_err(gphy->dev, "PoR->NC transition timeout");
+ return ret;
+ }
+
+ gphy->phy_state = COMBO_PHY_TCA_READY;
+
+ ret = program_tca_locked(gphy);
+
+ return ret;
+}
+
+static const struct phy_ops google_usb3_phy_ops = {
+ .init = google_usb3_phy_init,
+ .exit = google_usb3_phy_exit,
+ .power_on = google_usb3_phy_power_on,
+};
+
static struct phy *google_usb_phy_xlate(struct device *dev,
const struct of_phandle_args *args)
{
@@ -173,14 +437,61 @@ static struct phy *google_usb_phy_xlate(struct device *dev,
return gphy->insts[args->args[0]].phy;
}
+static int google_usb_phy_parse_clocks(struct google_usb_phy *gphy)
+{
+ struct device *dev = gphy->dev;
+ int id, i, ret;
+
+ for (id = 0; id < GOOGLE_USB_PHY_NUM; id++) {
+ const struct google_usb_phy_config *cfg = &phy_configs[id];
+ struct google_usb_phy_instance *inst = &gphy->insts[id];
+
+ inst->num_clks = cfg->num_clks;
+ inst->clks = devm_kcalloc(dev, inst->num_clks, sizeof(*inst->clks), GFP_KERNEL);
+ if (!inst->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < inst->num_clks; i++)
+ inst->clks[i].id = cfg->clk_names[i];
+
+ ret = devm_clk_bulk_get(dev, inst->num_clks, inst->clks);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get phy%d clks\n", id);
+ }
+
+ return 0;
+}
+
+static int google_usb_phy_parse_resets(struct google_usb_phy *gphy)
+{
+ struct device *dev = gphy->dev;
+ int id, i, ret;
+
+ for (id = 0; id < GOOGLE_USB_PHY_NUM; id++) {
+ const struct google_usb_phy_config *cfg = &phy_configs[id];
+ struct google_usb_phy_instance *inst = &gphy->insts[id];
+
+ inst->num_rsts = cfg->num_rsts;
+ inst->rsts = devm_kcalloc(dev, inst->num_rsts, sizeof(*inst->rsts), GFP_KERNEL);
+ if (!inst->rsts)
+ return -ENOMEM;
+
+ for (i = 0; i < inst->num_rsts; i++)
+ inst->rsts[i].id = cfg->rst_names[i];
+ ret = devm_reset_control_bulk_get_exclusive(dev, inst->num_rsts, inst->rsts);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get phy%d resets\n", id);
+ }
+
+ return 0;
+}
+
static int google_usb_phy_probe(struct platform_device *pdev)
{
struct typec_switch_desc sw_desc = { };
- struct google_usb_phy_instance *inst;
struct phy_provider *phy_provider;
struct device *dev = &pdev->dev;
struct google_usb_phy *gphy;
- struct phy *phy;
u32 args[1];
int ret;
@@ -212,39 +523,39 @@ static int google_usb_phy_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(gphy->usbdp_top_base),
"invalid usbdp top\n");
+ gphy->usb3_tca_base = devm_platform_ioremap_resource_byname(pdev,
+ "usb3_tca");
+ if (IS_ERR(gphy->usb3_tca_base))
+ return dev_err_probe(dev, PTR_ERR(gphy->usb3_tca_base),
+ "invalid usb3 tca\n");
+
gphy->insts = devm_kcalloc(dev, GOOGLE_USB_PHY_NUM, sizeof(*gphy->insts), GFP_KERNEL);
if (!gphy->insts)
return -ENOMEM;
- inst = &gphy->insts[GOOGLE_USB2_PHY];
- inst->parent = gphy;
- inst->index = GOOGLE_USB2_PHY;
- phy = devm_phy_create(dev, NULL, &google_usb2_phy_ops);
- if (IS_ERR(phy))
- return dev_err_probe(dev, PTR_ERR(phy),
+ gphy->insts[GOOGLE_USB2_PHY].phy = devm_phy_create(dev, NULL, &google_usb2_phy_ops);
+ gphy->insts[GOOGLE_USB2_PHY].index = GOOGLE_USB2_PHY;
+ gphy->insts[GOOGLE_USB2_PHY].parent = gphy;
+ if (IS_ERR(gphy->insts[GOOGLE_USB2_PHY].phy))
+ return dev_err_probe(dev, PTR_ERR(gphy->insts[GOOGLE_USB2_PHY].phy),
"failed to create usb2 phy instance\n");
- inst->phy = phy;
- phy_set_drvdata(phy, inst);
+ phy_set_drvdata(gphy->insts[GOOGLE_USB2_PHY].phy, &gphy->insts[GOOGLE_USB2_PHY]);
- inst->num_clks = 2;
- inst->clks = devm_kcalloc(dev, inst->num_clks, sizeof(*inst->clks), GFP_KERNEL);
- if (!inst->clks)
- return -ENOMEM;
- inst->clks[0].id = "usb2";
- inst->clks[1].id = "usb2_apb";
- ret = devm_clk_bulk_get(dev, inst->num_clks, inst->clks);
+ gphy->insts[GOOGLE_USB3_PHY].phy = devm_phy_create(dev, NULL, &google_usb3_phy_ops);
+ gphy->insts[GOOGLE_USB3_PHY].index = GOOGLE_USB3_PHY;
+ gphy->insts[GOOGLE_USB3_PHY].parent = gphy;
+ if (IS_ERR(gphy->insts[GOOGLE_USB3_PHY].phy))
+ return dev_err_probe(dev, PTR_ERR(gphy->insts[GOOGLE_USB3_PHY].phy),
+ "failed to create usb3 phy instance\n");
+ phy_set_drvdata(gphy->insts[GOOGLE_USB3_PHY].phy, &gphy->insts[GOOGLE_USB3_PHY]);
+
+ ret = google_usb_phy_parse_clocks(gphy);
if (ret)
- return dev_err_probe(dev, ret, "failed to get u2 phy clks\n");
+ return ret;
- inst->num_rsts = 2;
- inst->rsts = devm_kcalloc(dev, inst->num_rsts, sizeof(*inst->rsts), GFP_KERNEL);
- if (!inst->rsts)
- return -ENOMEM;
- inst->rsts[0].id = "usb2";
- inst->rsts[1].id = "usb2_apb";
- ret = devm_reset_control_bulk_get_exclusive(dev, inst->num_rsts, inst->rsts);
+ ret = google_usb_phy_parse_resets(gphy);
if (ret)
- return dev_err_probe(dev, ret, "failed to get u2 phy resets\n");
+ return ret;
phy_provider = devm_of_phy_provider_register(dev, google_usb_phy_xlate);
if (IS_ERR(phy_provider))
base-commit: 2ace2e949979b82f82f12dd76d7c5a6145246ca3
--
2.55.0.rc0.786.g65d90a0328-goog
^ permalink raw reply related
* Re: [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Maxime Chevallier @ 2026-06-22 17:51 UTC (permalink / raw)
To: Ben Dooks, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260622143707.497198-1-ben.dooks@codethink.co.uk>
Hi Ben,
On 6/22/26 16:37, Ben Dooks wrote:
> The print in ndesc_display_ring() sends the des2 and des3
> to the pr_info() without passing them through the relevant
> conversion to cpu order.
>
> Fix the (prototype) sparse warnings by using le32_to_cpu():
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
I agree on the principle, but this isn't a fix so this'll have to wait
until net-next re-opens :)
Thanks,
Maxime
> ---
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> index c4b613564f87..74c9b7b1fe8f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> @@ -258,7 +258,7 @@ static void ndesc_display_ring(void *head, unsigned int size, bool rx,
> pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x",
> i, &dma_addr,
> (unsigned int)x, (unsigned int)(x >> 32),
> - p->des2, p->des3);
> + le32_to_cpu(p->des2), le32_to_cpu(p->des3));
> p++;
> }
> pr_info("\n");
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-22 17:13 UTC (permalink / raw)
To: Harry Yoo
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <2208123f-8a51-483b-aa93-c35d8d053d25@kernel.org>
Hi Harry,
On Mon, Jun 22, 2026 at 09:42:10PM +0900, Harry Yoo wrote:
> On 6/19/26 10:19 PM, Catalin Marinas wrote:
> > On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
> >> On 6/12/26 1:44 PM, Dev Jain wrote:
> >>> Now, when a memory object will be freed, it will retain the random tag it
> >>> had at allocation time. This compromises on catching UAF bugs, till the
> >>> time the object is not reallocated, at which point it will have a new
> >>> random tag.
> >>>
> >>> Hence, not catching "use-after-free-before-reallocation" and not catching
> >>> "double-free" will be the compromise for reduced KASAN overhead.
> >>
> >> I doubt users who care about security enough to enable HW_TAGS KASAN
> >> are willing to compromise on security just to save a few instructions
> >> to store tags in the free path.
> >>
> >> To me, it looks like too much of a compromise on security for little
> >> performance gain.
> >
> > I don't think there's much compromise on security for use-after-free.
>
> I think it depends... OH, WAIT! I see what you mean.
>
> You mean use-after-free before reallocation does not lead to much
> compromise on security because objects are initialized after allocation?
>
> You're probably right.
>
> Hmm, but stores to e.g.) free pointer, fields initialized by
> constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
> will be undiscovered if they happen before reallocation.
Even with SLAB_TYPESAFE_BY_RCU, the object isn't tagged on free either
(or realloc, only if the actual slab page ends up freed). But we don't
get type confusion for such slab.
However, without tagging on free, one could argue that it reduces
security for cases where the page is re-allocated as untagged - e.g. all
user pages mapped without PROT_MTE. Currently we have a deterministic
tag check fault if the page is coloured as KASAN_TAG_INVALID. I think
for this patch, it might be better to only do such skip on free in
kasan_poison_slab() rather than kasan_poison(). Freed pages would then
be tagged.
An alternative would be tagging on free only with a new tag and skipping
it on re-alloc. But we'd need to track when it's a completely new
allocation or a reused object (I haven't looked I'm pretty sure it's
doable).
--
Catalin
^ permalink raw reply
* Re: [PATCH 10/11] regulator: db8500: Add power domain regulators
From: Mark Brown @ 2026-06-22 17:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-10-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
On Thu, Jun 18, 2026 at 07:00:56AM +0200, Linus Walleij wrote:
> +static int db8500_regulator_get_voltage(struct regulator_dev *rdev)
> +{
> + struct db8500_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + if (!info->desc.fixed_uV)
> + return -EINVAL;
> +
> + return info->desc.fixed_uV;
> +}
The core supports single fixed voltages, set desc->fixed_uV.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 0/2] PCI: Configure Root Port MPS during host probing
From: Bjorn Helgaas @ 2026-06-22 17:14 UTC (permalink / raw)
To: Hans Zhang
Cc: bhelgaas, Manivannan Sadhasivam, lpieralisi, kwilczynski, heiko,
yue.wang, pali, neil.armstrong, robh, jingoohan1, khilman,
jbrunet, martin.blumenstingl, cassel, linux-pci, linux-kernel,
linux-arm-kernel, linux-amlogic, linux-rockchip
In-Reply-To: <dae17d36-c7d2-467b-a621-3c55e08a67a8@163.com>
On Fri, Jun 19, 2026 at 11:29:39PM +0800, Hans Zhang wrote:
> On 5/6/26 22:00, Manivannan Sadhasivam wrote:
> > On Fri, Nov 28, 2025 at 01:09:06AM +0800, Hans Zhang wrote:
> > > Current PCIe initialization exhibits a key optimization gap: Root Ports
> > > may operate with non-optimal Maximum Payload Size (MPS) settings. While
> > > downstream device configuration is handled during bus enumeration, Root
> > > Port MPS values inherited from firmware or hardware defaults often fail
> > > to utilize the full capabilities supported by controller hardware. This
> > > results in suboptimal data transfer efficiency throughout the PCIe
> > > hierarchy.
> > >
> > > This patch series addresses this by:
> > >
> > > 1. Core PCI enhancement (Patch 1):
> > > - Proactively configures Root Port MPS during host controller probing
> > > - Sets initial MPS to hardware maximum (128 << dev->pcie_mpss)
> > > - Conditional on PCIe bus tuning being enabled (PCIE_BUS_TUNE_OFF unset)
> > > and not in PCIE_BUS_PEER2PEER mode (which requires default 128 bytes)
> > > - Maintains backward compatibility via PCIE_BUS_TUNE_OFF check
> > > - Preserves standard MPS negotiation during downstream enumeration
> > >
> > > 2. Driver cleanup (Patch 2):
> > > - Removes redundant MPS configuration from Meson PCIe controller driver
> > > - Functionality is now centralized in PCI core
> > > - Simplifies driver maintenance long-term
> > >
> >
> > For the series,
> >
> > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> >
> > Bjorn: Could you please take a look? This series has been floating for a
> > while...
>
> Hello Bjorn,
>
> Any chance for this series to be applied?
It's too late for v7.2; we're already more than halfway through the
merge window. We can look again for v7.3 after v7.2-rc1.
^ permalink raw reply
* Re: [PATCH 09/11] regulator: db8500-prcmu: Remove EPOD regulators
From: Mark Brown @ 2026-06-22 17:00 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-9-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 160 bytes --]
On Thu, Jun 18, 2026 at 07:00:55AM +0200, Linus Walleij wrote:
> Remove the obsolete DB8500 PRCMU regulator drivers.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Re: Re: [PATCH v2] PCI: host-common: Request bus reassignment when not probe-only
From: Bjorn Helgaas @ 2026-06-22 16:56 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: bjorn@helgaas.com, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
will@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, robh@kernel.org, vidyas@nvidia.com
In-Reply-To: <MN0PR18MB584758C9286C78B6EE947FE7D3182@MN0PR18MB5847.namprd18.prod.outlook.com>
On Fri, Jun 12, 2026 at 04:03:25AM +0000, Ratheesh Kannoth wrote:
> ...
> Kindly advise if there are any outstanding action items required
> from my side. I see that the patch is not available in net-next yet
> or backported to stable versions. I want to ensure I haven't missed
> a step, so please excuse my impatience if it is simply a matter of
> the usual release cycle.
This is queued on pci/controller/host-common and is in pci/next for
v7.2. I will ask Linus to pull that branch sometime this week. This
is separate from net-next, so it won't appear there. Backports to
stable will happen after Linus pulls the branch.
Bjorn
^ permalink raw reply
* Re: [PATCH kvmtool v2 7/7] arm64: Improve KVM_ARM_VCPU_PMU_V3_CTRL diagnostics
From: Oliver Upton @ 2026-06-22 16:55 UTC (permalink / raw)
To: Alexandru Elisei
Cc: will, julien.thierry.kdev, maz, jean-philippe.brucker,
andre.przywara, suzuki.poulose, kvm, linux-arm-kernel, kvmarm
In-Reply-To: <ajj6oGxytFm2NE4T@raptor>
On Mon, Jun 22, 2026 at 10:04:32AM +0100, Alexandru Elisei wrote:
> Hi Oliver,
>
> On Thu, Jun 18, 2026 at 12:06:12PM -0700, Oliver Upton wrote:
> > The whole if (ret) die_perror(...) thing is a bit repetetive IMO. A
> > treewide cleanup replacing this with macros would be nice, then you could
> > stringize the ioctl under the hood.
>
> Thank you for having a look, that's a great idea, it will avoid out of bounds
> array access if KVM gets a new PMU ioctl and the name array is not updated at
> the same time - that's quite possible since ioctl numbers are pulled by running
> update_headers.sh, and the dependency is not obvious.
>
> I think the compilation errors are a bit higher priority than this, and a
> treewide change would more involved, possibly involving a change in behaviour
> (the gic seems to propagate the error instead of calling die_perror(), for
> example), would you mind if for this series I'll only introduce the macro for
> the pmu and convert the rest of the code in a separate series?
Fine by me, thanks Alex :)
Best,
Oliver
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Doug Anderson @ 2026-06-22 16:52 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <ajk-Vge2qhaY-TwJ@thinkstation>
Hi,
On Mon, Jun 22, 2026 at 6:56 AM Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> The ratio is flat across the whole 1-to-72 sweep, so -- relevant to the
> scalability question -- it's a constant per-syscall tax, not a contention
> effect. The impact tracks syscall/exception density: page_fault1, a more
> realistic workload, stays within ~5%.
FWIW, I'm not sure 5% is truly a "realistic" measure of the overhead
here. While it cannot be denied that pseudo-NMI has some overhead,
every time I've seen someone study it in "real world" scenarios it
ends up being fairly negligible. Not zero, mind you. ...but some
amount below 1%. ...and by this, I mean put real-world workloads on a
system with pseudo NMI enabled and pick your favorite metric. Perhaps
measure the amount of work completed in a given time. I dunno if this
is possible for you to do in this case.
> > The direction of travel is to deprecate SDEI. I wouldn't add more stuff
> > on top of this interface.
>
> I understand FEAT_NMI is the long-term answer, and I'm not arguing against
> deprecating SDEI. My concern is the gap in between. By our estimate it's
> 10+ years before the last non-FEAT_NMI machine retires from the fleet --
> for scale, we're still running Skylake today. So there's roughly a
> decade where a large installed base has neither FEAT_NMI nor affordable
> pseudo-NMI, and no way to reach a DAIF-masked CPU for an all-CPU
> backtrace or to capture a wedged CPU in a crash dump. That's the
> functional gap this series tries to cover.
>
> Given the deprecation direction, I deliberately kept the SDEI footprint as
> small as I could. The series adds no new firmware interface and no vendor
> SMC -- it uses only the standard software-signalled event (event 0) via
> SDEI_EVENT_SIGNAL, which is already present on these systems for
> firmware-first RAS (APEI/GHES). And SDEI is only ever invoked in a "bad
> state": to deliver a backtrace signal to a CPU that a normal IPI can't
> reach, or to stop a CPU that ignored the stop IPIs. Nothing on any hot or
> steady-state path touches it.
>
> If even that minimal use is unacceptable on a deprecated interface, I'd
> rather know now and redirect the effort -- but I'd appreciate a pointer to
> what should cover this gap for existing silicon in the meantime.
FWIW, despite the fact that pseudo-NMI (in my experience) ends up
being mostly negligible, personally I'd be in favor of landing Kiryl's
patches. I dunno how many times I've had the discussion of pseudo-NMI
overhead over the years and it's certainly very easy to show that
there is _some_ overhead and that in pathological cases there is a lot
of overhead. As Kiryl says, the patches don't add a ton of extra
complexity and they even combine some of the stop/crash-stop code,
which is nice. Having them as a stop-gap until true NMI is available
seems nice to me. ...of course, I'm not an ARM maintainer, so it's
obviously not up to me. :-)
-Doug
^ permalink raw reply
* Re: [PATCH 1/6] arm64: mm: remove unreachable invalid range check in kasan_init_shadow()
From: Andrey Ryabinin @ 2026-06-22 16:52 UTC (permalink / raw)
To: Sang-Heon Jeon, Catalin Marinas, Will Deacon
Cc: Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, Vincenzo Frascino
In-Reply-To: <20260621145919.1453-2-ekffu200098@gmail.com>
Sang-Heon Jeon <ekffu200098@gmail.com> writes:
> kasan_init_shadow() maps each memblock region with for_each_mem_range()
> and breaks the loop when start >= end. for_each_mem_range() never returns
> an invalid range, so start < end always.
>
> Therefore the start >= end check is unreachable, so remove it.
>
> No functional change.
>
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> ---
> arch/arm64/mm/kasan_init.c | 3 ---
> 1 file changed, 3 deletions(-)
>
Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 3fcad956fdf7..45fbdce684c8 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -353,9 +353,6 @@ static void __init kasan_init_shadow(void)
> void *start = (void *)__phys_to_virt(pa_start);
> void *end = (void *)__phys_to_virt(pa_end);
>
> - if (start >= end)
> - break;
> -
> kasan_map_populate((unsigned long)kasan_mem_to_shadow(start),
> (unsigned long)kasan_mem_to_shadow(end),
> early_pfn_to_nid(virt_to_pfn(start)));
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 16:51 UTC (permalink / raw)
To: Randy Dunlap
Cc: Peter Zijlstra, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Julia Lawall, Yury Norov, linux-doc,
linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <08b3c961-18bb-43d9-8d7f-8a87bcad0afa@infradead.org>
On Mon, 22 Jun 2026 09:40:45 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> > Did you forget your C 101 class? If you use a function, you gotta
> > include the relevant header.
>
> Also item #1 in Documentation/process/submit-checklist.rst.
What is that? Remove all trace_printk()s before you submit?
Because that is what you should do. But now you also need to remember
to remove the include <linux/trace_printk.h> too. Or, I guess if
someone uses it a lot, they may just keep it in their files without the
trace_printk()s.
-- Steve
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Ard Biesheuvel @ 2026-06-22 16:42 UTC (permalink / raw)
To: Kevin Brodsky, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Fuad Tabba
In-Reply-To: <2deff570-0497-4438-94ba-a9691881a016@arm.com>
Hi Kevin,
On Mon, Jun 22, 2026 at 5:23 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
>
> On 19/06/2026 18:39, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Fuad reports that in some cases, the KVM init code may apply relocations
> > to variables that reside in .data, and does so via the linear map. This
> > means that remapping .data read-only beforehand is a bad idea, and
> > results in an early boot crash.
> >
> > These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> > CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> > testing.
> >
> > So move the remap to mark_rodata_ro(), which is a reasonable place to
> > put this, and ensures that it happens much later during the boot. It
> > also means that rodata=off is now taken into account, and so the linear
> > alias will remain writable in that case.
> >
> > Cc: Fuad Tabba <fuad.tabba@linux.dev>
> > Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > arch/arm64/mm/mmu.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9f354971b7e4..1f7eca86b5c1 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> > __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> > flags);
> > }
> > -
> > - /* Map the kernel data/bss read-only in the linear map */
> > - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> > - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> > - (unsigned long)lm_alias(__bss_stop));
> > }
> >
> > void mark_rodata_ro(void)
> > @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> > update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> > (unsigned long)_stext - (unsigned long)_text,
> > PAGE_KERNEL_RO);
> > +
> > + /* Map the kernel data/bss read-only in the linear map */
> > + update_mapping_prot(__pa_symbol(__init_end),
> > + (unsigned long)lm_alias(__init_end),
> > + (unsigned long)__bss_stop - (unsigned long)__init_end,
> > + PAGE_KERNEL_RO);
>
> I was rather confused by this patch until I saw in master:
>
> f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the
> linear map"
> 81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bss"
>
> ... which explains the diff, but it looks like there are multiple issues
> here. Is my understanding correct that these reverts fix kvm_arm_init()
> because it needs to *read* from the linear map, while this new patch
> fixes some KVM configurations that need to *write* to the linear map?
>
Basically, yes.
> If so it might be good to give a recap in the commit message, because
> the reverts are easy to miss.
>
Ok
> It would also be good to explain why we can't do this in
> mark_linear_text_alias_ro() (presumably because this is too early). I do
> agree that honouring rodata=off is a good thing, though.
>
I didn't consider that tbh - I'll check whether that is a more suitable
location. But generally, I think doing it later rather than earlier is
fine because it reduces the likelihood of hidden issues such as the one
being addressed by this patch, and I don't think doing this very early
makes a meaningful difference in terms of robustness.
> BTW, if only kvm_arm_init() needs to read the data/bss via the linear
> map, maybe we can still unmap it later?
>
Yes, it is still my intent to bring back the patches that unmap this alias
entirely, including some additional tweaks for the fixmap PTE level table
that I dropped after an earlier revision. But that will be 7.3 material,
whereas this fixes a regression due to the changes that were pulled for 7.2.
^ permalink raw reply
* Re: [PATCH v2 4/5] dt-bindings: dma: sun50i-a64-dma: Add allwinner,sun60i-a733-dma compatible string
From: Conor Dooley @ 2026-06-22 16:42 UTC (permalink / raw)
To: Frank Li
Cc: Yuanshen Cao, Vinod Koul, Frank Li, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, dmaengine, linux-arm-kernel, linux-sunxi,
linux-kernel, devicetree
In-Reply-To: <ajhjj7FLn136qMmt@SMW015318>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
On Sun, Jun 21, 2026 at 05:19:59PM -0500, Frank Li wrote:
> On Sun, Jun 21, 2026 at 09:40:57PM +0000, Yuanshen Cao wrote:
>
> subject dt-bindings: dmaengine: ....
>
> > Add `allwinner,sun60i-a733-dma` to the list of compatible strings for the
> > `sun50i-a64-dma` dtbinding documentation.
> >
> > While the A733 DMA controller shares many similarities with the sun50i-a64
> > DMA controller, it requires a specific configuration due to differences in:
> > - Interrupt register layout and mapping.
> > - Number of channels per interrupt register.
> > - Support for higher (32G) address widths in LLI parameters.
> >
> > Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> > ---
>
> After fix subject tags,
Do not change this unless you're respinning for another reason. dma v
dmaengine is not worth resubmission, especially since dma is far more
commonly used and is the directory name.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> > Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > index c3e14eb6cfff..1cc3304b7414 100644
> > --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > @@ -25,6 +25,7 @@ properties:
> > - allwinner,sun50i-a64-dma
> > - allwinner,sun50i-a100-dma
> > - allwinner,sun50i-h6-dma
> > + - allwinner,sun60i-a733-dma
> > - items:
> > - const: allwinner,sun8i-r40-dma
> > - const: allwinner,sun50i-a64-dma
> > @@ -70,6 +71,7 @@ if:
> > - allwinner,sun20i-d1-dma
> > - allwinner,sun50i-a100-dma
> > - allwinner,sun50i-h6-dma
> > + - allwinner,sun60i-a733-dma
> >
> > then:
> > properties:
> >
> > --
> > 2.54.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Randy Dunlap @ 2026-06-22 16:40 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Julia Lawall, Yury Norov, linux-doc, linux-kbuild, linuxppc-dev,
dri-devel, linux-stm32, linux-arm-kernel, linux-rdma, linux-usb,
linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260622083440.GX49951@noisy.programming.kicks-ass.net>
On 6/22/26 1:34 AM, Peter Zijlstra wrote:
> On Sun, Jun 21, 2026 at 05:34:30AM -0400, Steven Rostedt wrote:
>> There's been complaints about trace_printk() being defined in kernel.h as it
>> can increase the compilation time. As it is only used by some developers for
>> debugging purposes, it should not be in kernel.h causing lots of wasted CPU
>> cycles for those that do not ever care about it.
>>
>> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
>> use it can set and not have to always remember to add #include <linux/trace_printk.h>
>> to the files they add trace_printk() while debugging. It also means that
>> those that do not have that config set will not have to worry about wasted
>> CPU cycles as it is only include in the CFLAGS when the option is set, and
>> its completely ignored otherwise.
>
> Did you forget your C 101 class? If you use a function, you gotta
> include the relevant header.
Also item #1 in Documentation/process/submit-checklist.rst.
> You don't see userspace saying: 'Hey, you know what, perhaps we should
> add stdio.h to every other header, just in case someone wants to
> printf()' either.
>
> I really don't understand your argument. Yes, maybe someone will forget
> and then either their editor (if they have a halfway modern setup with
> LSP enabled) or their build will complain, but so what? This is all
> trivial stuff, surely we have more pressing matters to concern outselves
> with?
--
~Randy
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: fix BQL underflow in shared QDMA TX ring
From: Simon Horman @ 2026-06-22 16:39 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260620-airoha-bql-fixes-v3-1-76b95374e63e@kernel.org>
On Sat, Jun 20, 2026 at 05:04:51PM +0200, Lorenzo Bianconi wrote:
> When multiple netdevs share a QDMA TX ring and one device is stopped,
> netdev_tx_reset_subqueue() zeroes that device's BQL counters while its
> pending skbs remain in the shared HW TX ring. When NAPI later completes
> those skbs via netdev_tx_completed_queue(), the already-zeroed
> dql->num_queued counter underflows.
>
> Fix the issue:
> - Remove netdev_tx_reset_subqueue() from airoha_dev_stop() so pending
> skbs are completed naturally by NAPI with proper BQL accounting.
> - Rework airoha_qdma_tx_cleanup() to disable TX DMA, flush BQL
> counters, DMA-unmap and free all pending skbs while skb->dev
> references are still valid. Use a per-queue flushing flag checked
> under q->lock in airoha_dev_xmit() to prevent races between teardown
> and transmit. Call airoha_qdma_stop_napi() before
> airoha_qdma_tx_cleanup() at the call sites.
> - Move DMA engine start into probe. Split DMA teardown so TX DMA is
> disabled in airoha_qdma_tx_cleanup() and RX DMA in
> airoha_qdma_cleanup().
> - Remove qdma->users counter since DMA lifetime is now tied to
> probe/cleanup rather than per-netdev open/stop.
>
> Fixes: a9c2ca61fec7 ("net: airoha: Support multiple net_devices for a single FE GDM port")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> Changes in v3:
> - Remove airoha_qdma users counter.
> - Drop DEV_STATE_FLUSH bit and add per-queue flushing bool to avoid any
> race between airoha_qdma_tx_flush() and airoha_dev_xmit().
> - Refactor airoha_qdma_cleanup_tx_queue().
> - Rename airoha_qdma_cleanup_tx_queue() in airoha_qdma_tx_cleanup().
> - Link to v2: https://lore.kernel.org/r/20260619-airoha-bql-fixes-v2-1-4351d6a24484@kernel.org
>
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] pwm: add Axiado AX3000 PWM driver
From: Uwe Kleine-König @ 2026-06-22 16:29 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-pwm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-axiado-ax3000-pwm-v1-2-c9797a909414@axiado.com>
[-- Attachment #1: Type: text/plain, Size: 9646 bytes --]
Hello Petar,
Just a very high-level review:
On Thu, Jun 18, 2026 at 05:26:57AM -0700, Petar Stepanovic wrote:
> The Axiado AX3000 and AX3005 SoCs include PWM controllers that can be
> used to generate configurable PWM output signals.
>
> Add a PWM driver with support for configuring period, duty cycle, and
> enable state through the Linux PWM framework.
>
> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
> ---
> MAINTAINERS | 1 +
> drivers/pwm/Kconfig | 11 +++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-axiado.c | 193 +++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 206 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 394c4a3527e8..db93fc235c32 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4319,6 +4319,7 @@ M: Prasad Bolisetty <pbolisetty@axiado.com>
> L: linux-pwm@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/pwm/axiado,ax3000-pwm.yaml
> +F: drivers/pwm/pwm-axiado.c
>
> AXIS ARTPEC ARM64 SoC SUPPORT
> M: Jesper Nilsson <jesper.nilsson@axis.com>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376..76f6c04b0e23 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -129,6 +129,17 @@ config PWM_ATMEL_TCB
> To compile this driver as a module, choose M here: the module
> will be called pwm-atmel-tcb.
>
> +config PWM_AXIADO
> + tristate "Axiado PWM support"
> + depends on ARCH_AXIADO || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> + PWM framework driver for the PWM controller found on Axiado
> + AX3000 and AX3005 SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-axiado.
> +
> config PWM_AXI_PWMGEN
> tristate "Analog Devices AXI PWM generator"
> depends on MICROBLAZE || NIOS2 || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_INTEL_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0dc0d2b69025..4466a29e780a 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PWM_ARGON_FAN_HAT) += pwm-argon-fan-hat.o
> obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
> obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
> obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
> +obj-$(CONFIG_PWM_AXIADO) += pwm-axiado.o
> obj-$(CONFIG_PWM_AXI_PWMGEN) += pwm-axi-pwmgen.o
> obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
> obj-$(CONFIG_PWM_BCM_IPROC) += pwm-bcm-iproc.o
> diff --git a/drivers/pwm/pwm-axiado.c b/drivers/pwm/pwm-axiado.c
> new file mode 100644
> index 000000000000..db197886c5c4
> --- /dev/null
> +++ b/drivers/pwm/pwm-axiado.c
> @@ -0,0 +1,193 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2021-2026 Axiado Corporation.
Please add a Limitations paragraph here like the ones found in the newer
driver files. It should answer:
- Is a period completed on configuration change?
- Is a period completed on disable?
- How does the output behave when disabled? (Low? Inactive? Freeze? High-Z?)
Also mention special properties, like being unable to set 0% or 100%
relative duty.
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/math64.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +/* Register offsets */
> +#define AX_PWM_CNTRL_REG 0x0000
> +#define AX_PWM_PERIOD_REG 0x0004
> +#define AX_PWM_HIGH_REG 0x0008
> +
> +/* PWM channels */
> +#define AX_PWM_NUM 1
This is only used once, and having
chip = devm_pwmchip_alloc(dev, 1, sizeof(*axpwm));
below simplifies grepping for channel numbers.
> +
> +/* Period and duty cycle limits */
> +#define AX_PWM_PERIOD_MIN 2
> +#define AX_PWM_PERIOD_MAX 0xfffffffeU
> +#define AX_PWM_DUTY_MIN 1
> +#define AX_PWM_DUTY_MAX 0xfffffffdU
The U suffix is not needed for hex constants (AFAIK).
> +
> +/* Control register bits */
> +#define AX_PWM_CTRL_ENABLE BIT(0)
> +#define AX_PWM_CTRL_DISABLE 0x0
> +
> +struct axiado_pwm_chip {
> + struct clk *clk;
> + void __iomem *base;
> +};
If you use axiado_pwm_ as prefix for structs and functions, please use
AXIADO_PWM_ as prefix for #defines.
> +
> +static int axiado_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + u64 duty_ns, u64 period_ns)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + unsigned long rate;
> + u64 period_cycles, duty_cycles;
> +
> + /*
> + * The hardware does not support a zero period, 0% duty cycle, or
> + * 100% duty cycle. The caller should handle 0% duty cycle by
> + * disabling the PWM.
> + */
> + if (!period_ns || !duty_ns || duty_ns >= period_ns)
> + return -EINVAL;
> +
> + rate = clk_get_rate(axpwm->clk);
> + if (!rate)
> + return -EINVAL;
> +
> + period_cycles = mul_u64_u64_div_u64(period_ns, rate, NSEC_PER_SEC);
> + if (period_cycles < AX_PWM_PERIOD_MIN ||
> + period_cycles > AX_PWM_PERIOD_MAX)
> + return -EINVAL;
> +
> + duty_cycles = mul_u64_u64_div_u64(duty_ns, rate, NSEC_PER_SEC);
> + if (duty_cycles < AX_PWM_DUTY_MIN ||
> + duty_cycles > AX_PWM_DUTY_MAX)
> + return -EINVAL;
> +
> + if (duty_cycles >= period_cycles)
> + return -EINVAL;
> +
> + writel((u32)period_cycles, axpwm->base + AX_PWM_PERIOD_REG);
> + writel((u32)duty_cycles, axpwm->base + AX_PWM_HIGH_REG);
> +
> + return 0;
> +}
> +
> +static int axiado_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + int ret;
> +
> + if (state->polarity != PWM_POLARITY_NORMAL)
> + return -EINVAL;
> +
> + if (!state->enabled || !state->duty_cycle) {
> + if (pwm->state.enabled)
> + writel(AX_PWM_CTRL_DISABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +
> + return 0;
> + }
> +
> + ret = axiado_pwm_config(chip, pwm, state->duty_cycle, state->period);
> + if (ret)
> + return ret;
> +
> + if (!pwm->state.enabled)
Ideally check hardware state and not PWM internal variables.
> + writel(AX_PWM_CTRL_ENABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +
> + return 0;
> +}
> +
> +static int axiado_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + unsigned long rate;
> + u32 period_cycles;
> + u32 duty_cycles;
> + u32 ctrl;
> +
> + rate = clk_get_rate(axpwm->clk);
> + if (!rate)
> + return -EINVAL;
> +
> + ctrl = readl(axpwm->base + AX_PWM_CNTRL_REG);
> + period_cycles = readl(axpwm->base + AX_PWM_PERIOD_REG);
> + duty_cycles = readl(axpwm->base + AX_PWM_HIGH_REG);
> +
> + state->enabled = !!(ctrl & AX_PWM_CTRL_ENABLE);
> + state->period = mul_u64_u64_div_u64(period_cycles, NSEC_PER_SEC, rate);
> + state->duty_cycle = mul_u64_u64_div_u64(duty_cycles, NSEC_PER_SEC, rate);
> + state->polarity = PWM_POLARITY_NORMAL;
Please test your driver with PWM_DEBUG enabled, the rounding is wrong
here.
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops axiado_pwm_ops = {
> + .get_state = axiado_pwm_get_state,
> + .apply = axiado_pwm_apply,
Please implement the waveform callbacke instead of .get_state() and
.apply()
> +};
> +
> +static void axiado_pwm_disable(void *data)
> +{
> + struct axiado_pwm_chip *axpwm = data;
> +
> + writel(AX_PWM_CTRL_DISABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +}
> +
> +static int axiado_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct axiado_pwm_chip *axpwm;
> + struct pwm_chip *chip;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, AX_PWM_NUM, sizeof(*axpwm));
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + axpwm = pwmchip_get_drvdata(chip);
> +
> + axpwm->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(axpwm->base))
> + return dev_err_probe(dev, PTR_ERR(axpwm->base),
> + "failed to map registers\n");
Start error messages with a capital letter please.
> +
> + ret = devm_add_action_or_reset(dev, axiado_pwm_disable, axpwm);
> + if (ret)
> + return ret;
This isn't supposed to happen. It's the responsibility of the consumer
to disable the PWM before it's freed.
> +
> +
Single empty line only.
> + axpwm->clk = devm_clk_get_enabled(dev, "pwm");
> + if (IS_ERR(axpwm->clk))
> + return dev_err_probe(dev, PTR_ERR(axpwm->clk),
> + "failed to get/enable clock\n");
Please ensure that the clk rate doesn't change while the PWM is enabled.
Then you can cache the clk rate and set chip->atomic.
> +
> + chip->ops = &axiado_pwm_ops;
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to add PWM chip\n");
> +
> + return 0;
> +}
> +
> +static const struct of_device_id axiado_pwm_match[] = {
> + { .compatible = "axiado,ax3000-pwm" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, axiado_pwm_match);
> +
> +static struct platform_driver axiado_pwm_driver = {
> + .driver = {
> + .name = "axiado-pwm",
> + .of_match_table = axiado_pwm_match,
> + },
> + .probe = axiado_pwm_probe,
> +};
> +
> +module_platform_driver(axiado_pwm_driver);
No empty line between the driver struct and the module_platform helper
please.
> +
> +MODULE_AUTHOR("Axiado Corporation");
> +MODULE_DESCRIPTION("Axiado PWM driver");
> +MODULE_LICENSE("GPL");
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Disable PRI when no priq IRQ is available
From: Breno Leitao @ 2026-06-22 16:17 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-kernel, iommu, linux-kernel, rmikey, rneu, kernel-team,
Breno Leitao
When platform firmware advertises an SMMU as PRI-capable in IDR0.PRI
but does not assign a GSIV for its priq, arm_smmu_setup_unique_irqs()
warns and continues. ARM_SMMU_FEAT_PRI remains set, so the driver
still allocates the PRI queue, programs PRIQ_BASE/PROD/CONS, enables
IRQ_CTRL_PRIQ_IRQEN, and lets IOMMU_DEV_FEAT_IOPF be advertised to
upper layers. Page Request messages from devices land in a queue no
one drains, and SVA binds appear to succeed while silently dropping
every page fault.
Clear ARM_SMMU_FEAT_PRI in the missing-IRQ path so every PRI-gated
site in the driver consistently treats the SMMU as PRI-less, instead of
the half-baked stated.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a10affb483a4f..44bafbb38e242 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4659,7 +4659,8 @@ static void arm_smmu_setup_unique_irqs(struct arm_smmu_device *smmu)
dev_warn(smmu->dev,
"failed to enable priq irq\n");
} else {
- dev_warn(smmu->dev, "no priq irq - PRI will be broken\n");
+ dev_warn(smmu->dev, "no priq irq - disabling PRI\n");
+ smmu->features &= ~ARM_SMMU_FEAT_PRI;
}
}
}
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260622-smmu_pri-a33326900c33
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH net v2 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Simon Horman @ 2026-06-22 16:16 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <ajk0kS76nahtop8g@lore-desk>
On Mon, Jun 22, 2026 at 03:11:45PM +0200, Lorenzo Bianconi wrote:
> > On Fri, Jun 19, 2026 at 01:37:14PM +0200, Lorenzo Bianconi wrote:
> > > airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> > > index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> > > real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> > > channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> > > 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> > > accesses in the networking stack.
> > > For example, allocating channel 0 then channel 3 results in
> > > real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> > > Fix this by computing real_num_tx_queues based on the highest active
> > > channel index rather than using a simple counter, in both the allocation
> > > and deletion paths.
> > >
> > > Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >
> > Thanks for the update since v1.
> >
> > Reviewed-by: Simon Horman <horms@kernel.org>
>
> Hi Simon,
>
> thx for the review.
>
> >
> > FTR, there is an AI-generated review of this patch on sashiko.dev.
> > I do not think that should impede the progress of this patch but
> > you may want to consider it in the context of follow-up.
>
> Even if it is not introduced by this patch, I do not think what is reported
> by Sashiko is a real issue since airoha_eth driver implements
> ndo_select_queue() callback and the selected queue is always in the range
> [0, AIROHA_NUM_TX_RING[. HTB queues (in the range
> [AIROHA_NUM_TX_RING, AIROHA_NUM_TX_RING + AIROHA_NUM_QOS_CHANNELS[) are just
> 'offloaded' and never used in the TC sw path. Agree?
Thanks Lorenzo,
I've looked over this more closely with the above in mind and I agree.
^ permalink raw reply
* [soc:rfc-arm-deprecation-7.2] BUILD SUCCESS 1a31334b581c956c261b6618f03fa08041c6e95e
From: kernel test robot @ 2026-06-22 16:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rfc-arm-deprecation-7.2
branch HEAD: 1a31334b581c956c261b6618f03fa08041c6e95e ARM: mark mv78xx0 support as deprecated
elapsed time: 740m
configs tested: 179
configs skipped: 137
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260622 gcc-8.5.0
arc randconfig-002-20260622 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260622 gcc-8.5.0
arm randconfig-002-20260622 gcc-8.5.0
arm randconfig-003-20260622 gcc-8.5.0
arm randconfig-004-20260622 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260622 gcc-8.5.0
arm64 randconfig-002-20260622 gcc-8.5.0
arm64 randconfig-003-20260622 gcc-8.5.0
arm64 randconfig-004-20260622 gcc-8.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260622 gcc-8.5.0
csky randconfig-002-20260622 gcc-8.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260622 gcc-8.5.0
hexagon randconfig-002-20260622 gcc-8.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260622 gcc-14
i386 buildonly-randconfig-002-20260622 gcc-14
i386 buildonly-randconfig-003-20260622 gcc-14
i386 buildonly-randconfig-004-20260622 gcc-14
i386 buildonly-randconfig-005-20260622 gcc-14
i386 buildonly-randconfig-006-20260622 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260622 clang-22
i386 randconfig-002-20260622 clang-22
i386 randconfig-003-20260622 clang-22
i386 randconfig-004-20260622 clang-22
i386 randconfig-005-20260622 clang-22
i386 randconfig-006-20260622 clang-22
i386 randconfig-007-20260622 clang-22
i386 randconfig-011-20260622 gcc-14
i386 randconfig-012-20260622 gcc-14
i386 randconfig-013-20260622 gcc-14
i386 randconfig-014-20260622 gcc-14
i386 randconfig-015-20260622 gcc-14
i386 randconfig-016-20260622 gcc-14
i386 randconfig-017-20260622 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260622 gcc-8.5.0
loongarch randconfig-002-20260622 gcc-8.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips qi_lb60_defconfig clang-17
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001-20260622 gcc-8.5.0
nios2 randconfig-002-20260622 gcc-8.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260622 gcc-14.3.0
parisc randconfig-002-20260622 gcc-14.3.0
parisc64 defconfig clang-23
powerpc akebono_defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260622 gcc-14.3.0
powerpc randconfig-002-20260622 gcc-14.3.0
powerpc64 randconfig-001-20260622 gcc-14.3.0
powerpc64 randconfig-002-20260622 gcc-14.3.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-16.1.0
sparc randconfig-001-20260622 gcc-16.1.0
sparc randconfig-002 gcc-16.1.0
sparc randconfig-002-20260622 gcc-16.1.0
sparc sparc32_defconfig gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-16.1.0
sparc64 randconfig-001-20260622 gcc-16.1.0
sparc64 randconfig-002 gcc-16.1.0
sparc64 randconfig-002-20260622 gcc-16.1.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-16.1.0
um randconfig-001-20260622 gcc-16.1.0
um randconfig-002 gcc-16.1.0
um randconfig-002-20260622 gcc-16.1.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260622 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260622 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260622 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260622 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260622 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260622 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260622 clang-22
x86_64 randconfig-002-20260622 clang-22
x86_64 randconfig-003-20260622 clang-22
x86_64 randconfig-004-20260622 clang-22
x86_64 randconfig-005-20260622 clang-22
x86_64 randconfig-006-20260622 clang-22
x86_64 randconfig-011-20260622 clang-22
x86_64 randconfig-012-20260622 clang-22
x86_64 randconfig-013-20260622 clang-22
x86_64 randconfig-014-20260622 clang-22
x86_64 randconfig-015-20260622 clang-22
x86_64 randconfig-016-20260622 clang-22
x86_64 randconfig-071-20260622 gcc-14
x86_64 randconfig-072-20260622 gcc-14
x86_64 randconfig-073-20260622 gcc-14
x86_64 randconfig-074-20260622 gcc-14
x86_64 randconfig-075-20260622 gcc-14
x86_64 randconfig-076-20260622 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa generic_kc705_defconfig gcc-16.1.0
xtensa randconfig-001 gcc-16.1.0
xtensa randconfig-001-20260622 gcc-16.1.0
xtensa randconfig-002 gcc-16.1.0
xtensa randconfig-002-20260622 gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/8] power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693 Bluetooth
From: Manivannan Sadhasivam @ 2026-06-22 15:42 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, bhelgaas, brgl,
imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260618101047.4185497-3-sherry.sun@oss.nxp.com>
On Thu, Jun 18, 2026 at 06:10:41PM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> 88W9098 is a NXP Wi-Fi/BT combo chip with PCI device ID 0x2b43 under
> Marvell Extended vendor ID. AW693 is a NXP Wi-Fi/BT combo chip with
> PCI device ID 0x3003 under NXP/Philips vendor ID.
>
> Add both chips to pwrseq_m2_pci_ids[] so that the pwrseq-pcie-m2 driver
> can create the Bluetooth serdev device when these cards are inserted into
> a PCIe M.2 Key E connector.
>
> Both chips use "nxp,88w8987-bt" as the serdev compatible string, which
> is the entry point for the btnxpuart driver. The driver identifies the
> actual chip variant at runtime via chip ID auto-detection and loads the
> appropriate firmware accordingly.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/power/sequencing/pwrseq-pcie-m2.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
> index 94c3f4b7ee36..9217ffcfa6e5 100644
> --- a/drivers/power/sequencing/pwrseq-pcie-m2.c
> +++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
> @@ -186,6 +186,10 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
> }
>
> static const struct pci_device_id pwrseq_m2_pci_ids[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x2b43),
> + .driver_data = (kernel_ulong_t)"nxp,88w8987-bt" },
> + { PCI_DEVICE(PCI_VENDOR_ID_PHILIPS, 0x3003),
> + .driver_data = (kernel_ulong_t)"nxp,88w8987-bt" },
> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1107),
> .driver_data = (kernel_ulong_t)"qcom,wcn7850-bt" },
> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1103),
> --
> 2.50.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-22 14:49 UTC (permalink / raw)
To: Marc Zyngier, Fuad Tabba
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <86y0g7q6jh.wl-maz@kernel.org>
On June 22, 2026 10:16:18 AM GMT+01:00, Marc Zyngier <maz@kernel.org>
wrote:
>On Mon, 22 Jun 2026 09:32:45 +0100,
>Fuad Tabba <fuad.tabba@linux.dev> wrote:
>>
>> On Sun, 21 Jun 2026 at 22:32, Bradley Morgan <include@grrlz.net> wrote:
>> >
>> > Protected guest faults charge long term pins to the VM's mm. Teardown
>> > can run later from file release, where current->mm may be unrelated.
>> >
>> > Drop the charge from kvm->mm instead.
>> >
>> > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to
>pkvm_pgtable_stage2_destroy()")
>> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>>
>> Reproduced by creating a protected VM, running the vCPU to fault in a
>> page, then forking and having the child close the last fd reference.
>> Without the fix, the parent's VmLck leaks (the reclaim decrements the
>> child's mm, which is freed on exit). With the fix the parent's VmLck
>> returns to zero.
>>
>> One minor observation: account_locked_vm() also passes `current` as
>> the task pointer to __account_locked_vm(), but on the decrement path
>> that is only used in the pr_debug log line, so it is technically wrong
>> but functionally harmless.
I agree with marc here. Maybe awkward.
I tested it on my pixel 7! :)
>I don't think this is wrong. Awkward, maybe. It is just that the
>rlimit check and the accounting may be different contexts, and the
>pr_debug() call covers both inc and dec.
>
>>
>> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
>> Tested-by: Fuad Tabba < fuad.tabba@linux.dev>
Thanks for the review! :)
Cheers!
>Thanks,
>
> M.
>
>
^ permalink raw reply
* Re: [PATCH] pmdomain: bcm: bcm2835-power: Raise ASB poll timeout to 100us
From: Florian Fainelli @ 2026-06-22 15:29 UTC (permalink / raw)
To: Maíra Canal, Ulf Hansson,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Stefan Wahren
Cc: linux-pm, linux-rpi-kernel, linux-arm-kernel, kernel-dev
In-Reply-To: <20260530204636.1115120-1-mcanal@igalia.com>
On 5/30/2026 9:46 PM, Maíra Canal wrote:
> Commit 18605b1b936b ("pmdomain: bcm: bcm2835-power: Increase ASB control
> timeout") raised the ASB handshake polling budget from 1us to 5us.
> Surveying the pmdomain subsystem, 5us is still one of the smallest polling
> budgets by a wide margin. Comparable handshakes in other drivers use:
>
> - 100us : starfive jh71xx-pmu, apple pmgr-pwrstate
> - 1ms : renesas rcar-sysc, rmobile-sysc (power-on)
> - 10ms : renesas rcar-gen4-sysc, sunxi sun55i-pck600
> - 1s : mediatek mtk-pm-domains, mtk-scpsys
>
> Raise the BCM2835 timeout to 100us, matching analogous drivers. 100us is
> still negligible relative to a power-domain transition and gives the V3D
> master ASB substantially more headroom to drain under heavy workloads,
> assuring us that the timeout is enough for any scenario.
>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
The response I got from our design team is that turning of the the
"slave" should be immediate as it does not support multiple outstanding
transactions, it's the "master" that might requiring bleeding out
in-flight transactions and for which a longer timeout seems reasonable.
--
Florian
^ permalink raw reply
* Re: [PATCH] mfd: db8500-prcmu: Fold dbx500 header into db8500
From: Brian Masney @ 2026-06-22 15:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Ulf Hansson, Michael Turquette, Stephen Boyd,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Lee Jones,
Liam Girdwood, Mark Brown, Zhang Rui, Lukasz Luba,
Wim Van Sebroeck, Guenter Roeck, Jaroslav Kysela, Takashi Iwai,
linux-arm-kernel, linux-clk, linux-pm, linux-watchdog,
linux-sound, kernel test robot
In-Reply-To: <20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org>
On Fri, Jun 19, 2026 at 10:27:10PM +0200, Linus Walleij wrote:
> Move the DBx500 PRCMU definitions into the DB8500 PRCMU
> header and delete the wrapper header.
>
> Convert users of simple PRCMU wrappers to call the DB8500 helpers
> directly.
>
> The dbx500-prcmu.h header was the result of an earlier attempt to
> abstract several DBx5x SoC PRCMU units to use the same abstract
> header. They are deleted from the kernel and this is not just
> causing maintenance burden and build errors.
>
> The stub code is using -ENOSYS in a way checkpatch complains about
> so replace these with -EINVAL while we're at it.
>
> Assisted-by: Codex:gpt-5-5
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
> Signed-off-by: Linus Walleij <linusw@kernel.org>
For clk:
Acked-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Kevin Brodsky @ 2026-06-22 15:23 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, catalin.marinas, will, Ard Biesheuvel, Fuad Tabba
In-Reply-To: <20260619163940.3185308-2-ardb+git@google.com>
On 19/06/2026 18:39, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Fuad reports that in some cases, the KVM init code may apply relocations
> to variables that reside in .data, and does so via the linear map. This
> means that remapping .data read-only beforehand is a bad idea, and
> results in an early boot crash.
>
> These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> testing.
>
> So move the remap to mark_rodata_ro(), which is a reasonable place to
> put this, and ensures that it happens much later during the boot. It
> also means that rodata=off is now taken into account, and so the linear
> alias will remain writable in that case.
>
> Cc: Fuad Tabba <fuad.tabba@linux.dev>
> Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/mm/mmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 9f354971b7e4..1f7eca86b5c1 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> flags);
> }
> -
> - /* Map the kernel data/bss read-only in the linear map */
> - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> - (unsigned long)lm_alias(__bss_stop));
> }
>
> void mark_rodata_ro(void)
> @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> (unsigned long)_stext - (unsigned long)_text,
> PAGE_KERNEL_RO);
> +
> + /* Map the kernel data/bss read-only in the linear map */
> + update_mapping_prot(__pa_symbol(__init_end),
> + (unsigned long)lm_alias(__init_end),
> + (unsigned long)__bss_stop - (unsigned long)__init_end,
> + PAGE_KERNEL_RO);
I was rather confused by this patch until I saw in master:
f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the
linear map"
81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bss"
... which explains the diff, but it looks like there are multiple issues
here. Is my understanding correct that these reverts fix kvm_arm_init()
because it needs to *read* from the linear map, while this new patch
fixes some KVM configurations that need to *write* to the linear map?
If so it might be good to give a recap in the commit message, because
the reverts are easy to miss.
It would also be good to explain why we can't do this in
mark_linear_text_alias_ro() (presumably because this is too early). I do
agree that honouring rodata=off is a good thing, though.
BTW, if only kvm_arm_init() needs to read the data/bss via the linear
map, maybe we can still unmap it later?
- Kevin
^ permalink raw reply
* Re: [PATCH v4 2/2] media: i2c: ov5640: Add reset controller support with GPIO fallback
From: Frank Li @ 2026-06-22 15:02 UTC (permalink / raw)
To: Philipp Zabel
Cc: robby.cai, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
kieran.bingham, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <7ee62b699c5cabb00cd7706ea42573da81c5bc84.camel@pengutronix.de>
On Mon, Jun 22, 2026 at 11:05:34AM +0200, Philipp Zabel wrote:
> On Fr, 2026-06-19 at 09:18 -0500, Frank Li wrote:
> > On Fri, Jun 19, 2026 at 06:05:32PM +0800, robby.cai@oss.nxp.com wrote:
> > > [You don't often get email from robby.cai@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > From: Robby Cai <robby.cai@nxp.com>
> > >
> > > Add support for the reset controller framework by acquiring the reset
> > > line using devm_reset_control_get_optional_shared_deasserted(). This
> > > allows the driver to handle reset lines provided by a reset controller,
> > > including shared ones, while avoiding unbalanced deassert counts.
> > >
> > > Retain support for legacy reset-gpios as a fallback when no reset
> > > controller is defined. In that case, request the GPIO and keep it in the
> > > deasserted state as the initial configuration.
> > >
> > > This enables the driver to support both reset-controller-backed reset
> > > lines and older GPIO-based descriptions while preserving the existing
> > > power-up sequencing behavior.
> > >
> > > Signed-off-by: Robby Cai <robby.cai@nxp.com>
> > > ---
> > > drivers/media/i2c/ov5640.c | 80 +++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 70 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index 85ecc23b3587..5e6db8aacb11 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/module.h>
> > > #include <linux/pm_runtime.h>
> > > #include <linux/regulator/consumer.h>
> > > +#include <linux/reset.h>
> > > #include <linux/slab.h>
> > > #include <linux/types.h>
> > > #include <media/v4l2-async.h>
> > > @@ -442,6 +443,7 @@ struct ov5640_dev {
> > > u32 xclk_freq;
> > >
> > > struct regulator_bulk_data supplies[OV5640_NUM_SUPPLIES];
> > > + struct reset_control *reset;
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *pwdn_gpio;
> > > bool upside_down;
> > > @@ -2431,6 +2433,48 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
> > > return ov5640_set_framefmt(sensor, &sensor->fmt);
> > > }
> > >
> > > +static int ov5640_get_reset(struct device *dev, struct ov5640_dev *sensor)
> > > +{
> > > + /* use deasserted version to avoid unbalanced deassert counts */
> > > + sensor->reset =
> > > + devm_reset_control_get_optional_shared_deasserted(dev, NULL);
> > > + if (IS_ERR(sensor->reset))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset),
> > > + "Failed to get reset\n");
> > > + else if (sensor->reset)
> > > + return 0;
> > > +
> > > + /*
> > > + * fallback to legacy reset-gpios
> > > + * GPIOD_OUT_HIGH ensures deasserted state for ACTIVE_LOW reset
> > > + */
> > > + sensor->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(sensor->reset_gpio))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset_gpio),
> > > + "Failed to get reset gpio");
> >
> > I think needn't fallback here, NO ABI change, just change to use reset-gpio
> > driver.
>
> Please keep the gpiod fallback, the reset-gpio driver may not be
> available on all platforms using ov5640.
Maybe try promote reset-gpio is default build in / as module. Leave such
fallback every where make code complex.
Krysztof:
Any suggestion?
Frank
>
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int ov5640_reset_assert(struct ov5640_dev *sensor)
> > > +{
> > > + if (sensor->reset)
> > > + return reset_control_assert(sensor->reset);
> >
> > needn't check sensor->reset, reset_control_assert() is no ops if NULL.
> >
> > > +
> > > + gpiod_set_value_cansleep(sensor->reset_gpio, 1);
> >
> > Needn't fallback, directly replace.
>
> See above.
>
>
> regards
> Philipp
^ 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