* [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used @ 2024-05-02 12:33 Udipto Goswami 2024-05-02 13:12 ` Dmitry Baryshkov 2024-05-03 5:37 ` kernel test robot 0 siblings, 2 replies; 8+ messages in thread From: Udipto Goswami @ 2024-05-02 12:33 UTC (permalink / raw) To: Bjorn Andersson, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I Cc: linux-arm-msm, linux-phy, linux-kernel, Udipto Goswami The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. If one of the regulators is not voted to the required minimum voltage for phy to operate, then High speed mode of operation will fail. On certain targets like (qcm6490_rb3gen2) where the minimum voltage of the regulator is lower than the operating voltage of the phy. If not voted properly, the phy supply would be limited to the min value of the LDO thereby rendering the phy non-operational. The current implementation of the regulators in the Femto PHY is not setting the load and voltage for each LDO. The appropriate voltages and loads required for the PHY to operate should be set. Implement a bulk operation api to set load & voltages before doing bulk enable. This will ensure that the PHY remains operational under all conditions. Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com> --- drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 121 +++++++++++++++++- 1 file changed, 114 insertions(+), 7 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c index eb0b0f61d98e..cbe9cdaa6849 100644 --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c @@ -78,11 +78,39 @@ #define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0) -static const char * const qcom_snps_hsphy_vreg_names[] = { - "vdda-pll", "vdda33", "vdda18", + +struct qcom_snps_hsphy_regulator_data { + const char *name; + unsigned int enable_load; + unsigned int min_voltage; + unsigned int max_voltage; +}; + +static const struct qcom_snps_hsphy_regulator_data hsphy_vreg_l[] = { + { + .name = "vdda-pll", + .enable_load = 30000, + .min_voltage = 825000, + .max_voltage = 925000, + }, + + { + .name = "vdda18", + .enable_load = 19000, + .min_voltage = 1704000, + .max_voltage = 1800000 + }, + + { + .name = "vdda33", + .enable_load = 16000, + .min_voltage = 3050000, + .max_voltage = 3300000 + }, + }; -#define SNPS_HS_NUM_VREGS ARRAY_SIZE(qcom_snps_hsphy_vreg_names) +#define SNPS_HS_NUM_VREGS ARRAY_SIZE(hsphy_vreg_l) struct override_param { s32 value; @@ -132,12 +160,90 @@ struct qcom_snps_hsphy { struct clk_bulk_data *clks; struct reset_control *phy_reset; struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS]; + const struct qcom_snps_hsphy_regulator_data *vreg_list; bool phy_initialized; enum phy_mode mode; struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS]; }; +static int __vdda_phy_bulk_enable_disable(struct qcom_snps_hsphy *hsphy, bool on) +{ + int ret = 0; + int i; + + if (!on) + goto disable_vdd; + + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { + + ret = regulator_set_load(hsphy->vregs[i].consumer, + hsphy->vreg_list[i].enable_load); + + if (ret < 0) { + dev_err(hsphy->dev, "unable to set HPM of %s %d\n", + hsphy->vregs[i].supply, ret); + goto err_vdd; + } + } + + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { + ret = regulator_set_voltage(hsphy->vregs[i].consumer, + hsphy->vreg_list[i].min_voltage, + hsphy->vreg_list[i].max_voltage); + if (ret) { + dev_err(hsphy->dev, + "unable to set voltage of regulator %s %d\n", + hsphy->vregs[i].supply, ret); + goto put_vdd_lpm; + } + } + + ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); + if (ret) + goto unconfig_vdd; + + return ret; + +disable_vdd: + regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); + +unconfig_vdd: + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { + ret = regulator_set_voltage(hsphy->vregs[i].consumer, 0, + hsphy->vreg_list[i].max_voltage); + if (ret) { + dev_err(hsphy->dev, + "unable to set voltage of regulator %s %d\n", + hsphy->vregs[i].supply, ret); + } + } + +put_vdd_lpm: + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { + ret = regulator_set_load(hsphy->vregs[i].consumer, 0); + + if (ret < 0) { + dev_err(hsphy->dev, "unable to set LPM of %s %d\n", + hsphy->vregs[i].supply, ret); + } + } + +err_vdd: + return ret; + +} + +static int vdda_phy_bulk_enable(struct qcom_snps_hsphy *hsphy) +{ + return __vdda_phy_bulk_enable_disable(hsphy, true); +} + +static int vdda_phy_bulk_disable(struct qcom_snps_hsphy *hsphy) +{ + return __vdda_phy_bulk_enable_disable(hsphy, false); +} + static int qcom_snps_hsphy_clk_init(struct qcom_snps_hsphy *hsphy) { struct device *dev = hsphy->dev; @@ -390,7 +496,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__); - ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); + ret = vdda_phy_bulk_enable(hsphy); if (ret) return ret; @@ -471,7 +577,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) disable_clks: clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); poweroff_phy: - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); + ret = vdda_phy_bulk_disable(hsphy); return ret; } @@ -482,7 +588,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy) reset_control_assert(hsphy->phy_reset); clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); + vdda_phy_bulk_disable(hsphy); hsphy->phy_initialized = false; return 0; @@ -592,8 +698,9 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev) num = ARRAY_SIZE(hsphy->vregs); for (i = 0; i < num; i++) - hsphy->vregs[i].supply = qcom_snps_hsphy_vreg_names[i]; + hsphy->vregs[i].supply = hsphy_vreg_l[i].name; + hsphy->vreg_list = hsphy_vreg_l; ret = devm_regulator_bulk_get(dev, num, hsphy->vregs); if (ret) return dev_err_probe(dev, ret, -- 2.17.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-02 12:33 [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used Udipto Goswami @ 2024-05-02 13:12 ` Dmitry Baryshkov 2024-05-03 5:23 ` Udipto Goswami 2024-05-07 11:43 ` Konrad Dybcio 2024-05-03 5:37 ` kernel test robot 1 sibling, 2 replies; 8+ messages in thread From: Dmitry Baryshkov @ 2024-05-02 13:12 UTC (permalink / raw) To: Udipto Goswami Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, linux-arm-msm, linux-phy, linux-kernel On Thu, 2 May 2024 at 15:33, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: > > The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. > If one of the regulators is not voted to the required minimum voltage > for phy to operate, then High speed mode of operation will fail. > > On certain targets like (qcm6490_rb3gen2) where the minimum voltage > of the regulator is lower than the operating voltage of the phy. > If not voted properly, the phy supply would be limited to the min value > of the LDO thereby rendering the phy non-operational. > > The current implementation of the regulators in the Femto PHY is not > setting the load and voltage for each LDO. The appropriate voltages and > loads required for the PHY to operate should be set. Please move min/max voltages to the DTS. There is no need to set them from the driver. Also, is there any reason why you can't use `regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;` like other boards do? > > Implement a bulk operation api to set load & voltages before doing bulk > enable. This will ensure that the PHY remains operational under all > conditions. > > Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com> > --- > drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 121 +++++++++++++++++- > 1 file changed, 114 insertions(+), 7 deletions(-) > > diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c > index eb0b0f61d98e..cbe9cdaa6849 100644 > --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c > +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c > @@ -78,11 +78,39 @@ > > #define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0) > > -static const char * const qcom_snps_hsphy_vreg_names[] = { > - "vdda-pll", "vdda33", "vdda18", > + > +struct qcom_snps_hsphy_regulator_data { > + const char *name; > + unsigned int enable_load; > + unsigned int min_voltage; > + unsigned int max_voltage; > +}; > + > +static const struct qcom_snps_hsphy_regulator_data hsphy_vreg_l[] = { > + { > + .name = "vdda-pll", > + .enable_load = 30000, > + .min_voltage = 825000, > + .max_voltage = 925000, > + }, > + > + { > + .name = "vdda18", > + .enable_load = 19000, > + .min_voltage = 1704000, > + .max_voltage = 1800000 > + }, > + > + { > + .name = "vdda33", > + .enable_load = 16000, > + .min_voltage = 3050000, > + .max_voltage = 3300000 > + }, > + > }; > > -#define SNPS_HS_NUM_VREGS ARRAY_SIZE(qcom_snps_hsphy_vreg_names) > +#define SNPS_HS_NUM_VREGS ARRAY_SIZE(hsphy_vreg_l) > > struct override_param { > s32 value; > @@ -132,12 +160,90 @@ struct qcom_snps_hsphy { > struct clk_bulk_data *clks; > struct reset_control *phy_reset; > struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS]; > + const struct qcom_snps_hsphy_regulator_data *vreg_list; > > bool phy_initialized; > enum phy_mode mode; > struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS]; > }; > > +static int __vdda_phy_bulk_enable_disable(struct qcom_snps_hsphy *hsphy, bool on) Separate functions, please. > +{ > + int ret = 0; > + int i; > + > + if (!on) > + goto disable_vdd; > + > + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > + > + ret = regulator_set_load(hsphy->vregs[i].consumer, > + hsphy->vreg_list[i].enable_load); > + > + if (ret < 0) { > + dev_err(hsphy->dev, "unable to set HPM of %s %d\n", > + hsphy->vregs[i].supply, ret); > + goto err_vdd; > + } > + } > + > + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > + ret = regulator_set_voltage(hsphy->vregs[i].consumer, > + hsphy->vreg_list[i].min_voltage, > + hsphy->vreg_list[i].max_voltage); > + if (ret) { > + dev_err(hsphy->dev, > + "unable to set voltage of regulator %s %d\n", > + hsphy->vregs[i].supply, ret); > + goto put_vdd_lpm; > + } > + } > + > + ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > + if (ret) > + goto unconfig_vdd; > + > + return ret; > + > +disable_vdd: > + regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > + > +unconfig_vdd: > + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > + ret = regulator_set_voltage(hsphy->vregs[i].consumer, 0, > + hsphy->vreg_list[i].max_voltage); > + if (ret) { > + dev_err(hsphy->dev, > + "unable to set voltage of regulator %s %d\n", > + hsphy->vregs[i].supply, ret); > + } > + } > + > +put_vdd_lpm: > + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > + ret = regulator_set_load(hsphy->vregs[i].consumer, 0); > + > + if (ret < 0) { > + dev_err(hsphy->dev, "unable to set LPM of %s %d\n", > + hsphy->vregs[i].supply, ret); > + } > + } > + > +err_vdd: > + return ret; > + > +} > + > +static int vdda_phy_bulk_enable(struct qcom_snps_hsphy *hsphy) > +{ > + return __vdda_phy_bulk_enable_disable(hsphy, true); > +} > + > +static int vdda_phy_bulk_disable(struct qcom_snps_hsphy *hsphy) > +{ > + return __vdda_phy_bulk_enable_disable(hsphy, false); > +} > + > static int qcom_snps_hsphy_clk_init(struct qcom_snps_hsphy *hsphy) > { > struct device *dev = hsphy->dev; > @@ -390,7 +496,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) > > dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__); > > - ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > + ret = vdda_phy_bulk_enable(hsphy); > if (ret) > return ret; > > @@ -471,7 +577,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) > disable_clks: > clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); > poweroff_phy: > - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > + ret = vdda_phy_bulk_disable(hsphy); > > return ret; > } > @@ -482,7 +588,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy) > > reset_control_assert(hsphy->phy_reset); > clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); > - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > + vdda_phy_bulk_disable(hsphy); > hsphy->phy_initialized = false; > > return 0; > @@ -592,8 +698,9 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev) > > num = ARRAY_SIZE(hsphy->vregs); > for (i = 0; i < num; i++) > - hsphy->vregs[i].supply = qcom_snps_hsphy_vreg_names[i]; > + hsphy->vregs[i].supply = hsphy_vreg_l[i].name; > > + hsphy->vreg_list = hsphy_vreg_l; > ret = devm_regulator_bulk_get(dev, num, hsphy->vregs); > if (ret) > return dev_err_probe(dev, ret, > -- > 2.17.1 > > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-02 13:12 ` Dmitry Baryshkov @ 2024-05-03 5:23 ` Udipto Goswami 2024-05-03 18:29 ` Dmitry Baryshkov 2024-05-07 11:43 ` Konrad Dybcio 1 sibling, 1 reply; 8+ messages in thread From: Udipto Goswami @ 2024-05-03 5:23 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, linux-arm-msm, linux-phy, linux-kernel Hi Dmitry, On 5/2/2024 6:42 PM, Dmitry Baryshkov wrote: > On Thu, 2 May 2024 at 15:33, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: >> >> The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. >> If one of the regulators is not voted to the required minimum voltage >> for phy to operate, then High speed mode of operation will fail. >> >> On certain targets like (qcm6490_rb3gen2) where the minimum voltage >> of the regulator is lower than the operating voltage of the phy. >> If not voted properly, the phy supply would be limited to the min value >> of the LDO thereby rendering the phy non-operational. >> >> The current implementation of the regulators in the Femto PHY is not >> setting the load and voltage for each LDO. The appropriate voltages and >> loads required for the PHY to operate should be set. > > Please move min/max voltages to the DTS. There is no need to set them > from the driver. that also can be done. > > Also, is there any reason why you can't use `regulator-initial-mode = > <RPMH_REGULATOR_MODE_HPM>;` like other boards do? but the regulator loads & voltages for the phy doesn't change for every platform. Phys operational limits will still be the same for all the different platforms which exists today and the upcoming ones as well if they use it. Suppose te LDO's HPM is 2000 but the phy require 6000, its not getting enough power, same for reverse say 6000 in LDO's HPM and phy require 2000, isn't this power leakage ? This also seems to be the case with voltages as well, the phy require 0.88V for operation but if LDO is lower then that say 0.70, phy won't work. So instead of doing it seperately doesn't it make sense to do it in driver ? > >> >> Implement a bulk operation api to set load & voltages before doing bulk >> enable. This will ensure that the PHY remains operational under all >> conditions. >> >> Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com> >> --- >> drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 121 +++++++++++++++++- >> 1 file changed, 114 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c >> index eb0b0f61d98e..cbe9cdaa6849 100644 >> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c >> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c >> @@ -78,11 +78,39 @@ >> >> #define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0) >> >> -static const char * const qcom_snps_hsphy_vreg_names[] = { >> - "vdda-pll", "vdda33", "vdda18", >> + >> +struct qcom_snps_hsphy_regulator_data { >> + const char *name; >> + unsigned int enable_load; >> + unsigned int min_voltage; >> + unsigned int max_voltage; >> +}; >> + >> +static const struct qcom_snps_hsphy_regulator_data hsphy_vreg_l[] = { >> + { >> + .name = "vdda-pll", >> + .enable_load = 30000, >> + .min_voltage = 825000, >> + .max_voltage = 925000, >> + }, >> + >> + { >> + .name = "vdda18", >> + .enable_load = 19000, >> + .min_voltage = 1704000, >> + .max_voltage = 1800000 >> + }, >> + >> + { >> + .name = "vdda33", >> + .enable_load = 16000, >> + .min_voltage = 3050000, >> + .max_voltage = 3300000 >> + }, >> + >> }; >> >> -#define SNPS_HS_NUM_VREGS ARRAY_SIZE(qcom_snps_hsphy_vreg_names) >> +#define SNPS_HS_NUM_VREGS ARRAY_SIZE(hsphy_vreg_l) >> >> struct override_param { >> s32 value; >> @@ -132,12 +160,90 @@ struct qcom_snps_hsphy { >> struct clk_bulk_data *clks; >> struct reset_control *phy_reset; >> struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS]; >> + const struct qcom_snps_hsphy_regulator_data *vreg_list; >> >> bool phy_initialized; >> enum phy_mode mode; >> struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS]; >> }; >> >> +static int __vdda_phy_bulk_enable_disable(struct qcom_snps_hsphy *hsphy, bool on) > > Separate functions, please. sure. > >> +{ >> + int ret = 0; >> + int i; >> + >> + if (!on) >> + goto disable_vdd; >> + >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { >> + >> + ret = regulator_set_load(hsphy->vregs[i].consumer, >> + hsphy->vreg_list[i].enable_load); >> + >> + if (ret < 0) { >> + dev_err(hsphy->dev, "unable to set HPM of %s %d\n", >> + hsphy->vregs[i].supply, ret); >> + goto err_vdd; >> + } >> + } >> + >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { >> + ret = regulator_set_voltage(hsphy->vregs[i].consumer, >> + hsphy->vreg_list[i].min_voltage, >> + hsphy->vreg_list[i].max_voltage); >> + if (ret) { >> + dev_err(hsphy->dev, >> + "unable to set voltage of regulator %s %d\n", >> + hsphy->vregs[i].supply, ret); >> + goto put_vdd_lpm; >> + } >> + } >> + >> + ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); >> + if (ret) >> + goto unconfig_vdd; >> + >> + return ret; >> + >> +disable_vdd: >> + regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); >> + >> +unconfig_vdd: >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { >> + ret = regulator_set_voltage(hsphy->vregs[i].consumer, 0, >> + hsphy->vreg_list[i].max_voltage); >> + if (ret) { >> + dev_err(hsphy->dev, >> + "unable to set voltage of regulator %s %d\n", >> + hsphy->vregs[i].supply, ret); >> + } >> + } >> + >> +put_vdd_lpm: >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { >> + ret = regulator_set_load(hsphy->vregs[i].consumer, 0); >> + >> + if (ret < 0) { >> + dev_err(hsphy->dev, "unable to set LPM of %s %d\n", >> + hsphy->vregs[i].supply, ret); >> + } >> + } >> + >> +err_vdd: >> + return ret; >> + >> +} >> + >> +static int vdda_phy_bulk_enable(struct qcom_snps_hsphy *hsphy) >> +{ >> + return __vdda_phy_bulk_enable_disable(hsphy, true); >> +} >> + >> +static int vdda_phy_bulk_disable(struct qcom_snps_hsphy *hsphy) >> +{ >> + return __vdda_phy_bulk_enable_disable(hsphy, false); >> +} >> + >> static int qcom_snps_hsphy_clk_init(struct qcom_snps_hsphy *hsphy) >> { >> struct device *dev = hsphy->dev; >> @@ -390,7 +496,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) >> >> dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__); >> >> - ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); >> + ret = vdda_phy_bulk_enable(hsphy); >> if (ret) >> return ret; >> >> @@ -471,7 +577,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) >> disable_clks: >> clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); >> poweroff_phy: >> - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); >> + ret = vdda_phy_bulk_disable(hsphy); >> >> return ret; >> } >> @@ -482,7 +588,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy) >> >> reset_control_assert(hsphy->phy_reset); >> clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); >> - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); >> + vdda_phy_bulk_disable(hsphy); >> hsphy->phy_initialized = false; >> >> return 0; >> @@ -592,8 +698,9 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev) >> >> num = ARRAY_SIZE(hsphy->vregs); >> for (i = 0; i < num; i++) >> - hsphy->vregs[i].supply = qcom_snps_hsphy_vreg_names[i]; >> + hsphy->vregs[i].supply = hsphy_vreg_l[i].name; >> >> + hsphy->vreg_list = hsphy_vreg_l; >> ret = devm_regulator_bulk_get(dev, num, hsphy->vregs); >> if (ret) >> return dev_err_probe(dev, ret, >> -- >> 2.17.1 -Udipto ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-03 5:23 ` Udipto Goswami @ 2024-05-03 18:29 ` Dmitry Baryshkov 0 siblings, 0 replies; 8+ messages in thread From: Dmitry Baryshkov @ 2024-05-03 18:29 UTC (permalink / raw) To: Udipto Goswami Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, linux-arm-msm, linux-phy, linux-kernel On Fri, 3 May 2024 at 08:24, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: > > Hi Dmitry, > > On 5/2/2024 6:42 PM, Dmitry Baryshkov wrote: > > On Thu, 2 May 2024 at 15:33, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: > >> > >> The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. > >> If one of the regulators is not voted to the required minimum voltage > >> for phy to operate, then High speed mode of operation will fail. > >> > >> On certain targets like (qcm6490_rb3gen2) where the minimum voltage > >> of the regulator is lower than the operating voltage of the phy. > >> If not voted properly, the phy supply would be limited to the min value > >> of the LDO thereby rendering the phy non-operational. > >> > >> The current implementation of the regulators in the Femto PHY is not > >> setting the load and voltage for each LDO. The appropriate voltages and > >> loads required for the PHY to operate should be set. > > > > Please move min/max voltages to the DTS. There is no need to set them > > from the driver. > that also can be done. > > > > Also, is there any reason why you can't use `regulator-initial-mode = > > <RPMH_REGULATOR_MODE_HPM>;` like other boards do? > > > but the regulator loads & voltages for the phy doesn't change for every > platform. > Phys operational limits will still be the same for all the different > platforms which exists today and the upcoming ones as well if they use it. > > Suppose te LDO's HPM is 2000 but the phy require 6000, its not getting > enough power, same for reverse say 6000 in LDO's HPM and phy require > 2000, isn't this power leakage ? > > This also seems to be the case with voltages as well, the phy require > 0.88V for operation but if LDO is lower then that say 0.70, phy won't work. > > So instead of doing it seperately doesn't it make sense to do it in driver ? For RPMh regulators the load isn't propagated to the regulator at all. Only the mode is being selected based on the load. For the voltages: no. The DT constraints should provide boundaries for the regulator to supply all devices. So setting voltages in the driver is not correct. Last, but not least. Please take a look around before writing the patch. It's true that some of the drivers for Qualcomm platforms set the load. And some of them get this removed in favour of setting the mode (that depends on the situation).However I think none of the consumers on Qualcomm platforms set the voltage boundaries. > > > >> > >> Implement a bulk operation api to set load & voltages before doing bulk > >> enable. This will ensure that the PHY remains operational under all > >> conditions. > >> > >> Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com> > >> --- > >> drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 121 +++++++++++++++++- > >> 1 file changed, 114 insertions(+), 7 deletions(-) > >> > >> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c > >> index eb0b0f61d98e..cbe9cdaa6849 100644 > >> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c > >> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c > >> @@ -78,11 +78,39 @@ > >> > >> #define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0) > >> > >> -static const char * const qcom_snps_hsphy_vreg_names[] = { > >> - "vdda-pll", "vdda33", "vdda18", > >> + > >> +struct qcom_snps_hsphy_regulator_data { > >> + const char *name; > >> + unsigned int enable_load; > >> + unsigned int min_voltage; > >> + unsigned int max_voltage; > >> +}; > >> + > >> +static const struct qcom_snps_hsphy_regulator_data hsphy_vreg_l[] = { > >> + { > >> + .name = "vdda-pll", > >> + .enable_load = 30000, > >> + .min_voltage = 825000, > >> + .max_voltage = 925000, > >> + }, > >> + > >> + { > >> + .name = "vdda18", > >> + .enable_load = 19000, > >> + .min_voltage = 1704000, > >> + .max_voltage = 1800000 > >> + }, > >> + > >> + { > >> + .name = "vdda33", > >> + .enable_load = 16000, > >> + .min_voltage = 3050000, > >> + .max_voltage = 3300000 > >> + }, > >> + > >> }; > >> > >> -#define SNPS_HS_NUM_VREGS ARRAY_SIZE(qcom_snps_hsphy_vreg_names) > >> +#define SNPS_HS_NUM_VREGS ARRAY_SIZE(hsphy_vreg_l) > >> > >> struct override_param { > >> s32 value; > >> @@ -132,12 +160,90 @@ struct qcom_snps_hsphy { > >> struct clk_bulk_data *clks; > >> struct reset_control *phy_reset; > >> struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS]; > >> + const struct qcom_snps_hsphy_regulator_data *vreg_list; > >> > >> bool phy_initialized; > >> enum phy_mode mode; > >> struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS]; > >> }; > >> > >> +static int __vdda_phy_bulk_enable_disable(struct qcom_snps_hsphy *hsphy, bool on) > > > > Separate functions, please. > sure. > > > >> +{ > >> + int ret = 0; > >> + int i; > >> + > >> + if (!on) > >> + goto disable_vdd; > >> + > >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > >> + > >> + ret = regulator_set_load(hsphy->vregs[i].consumer, > >> + hsphy->vreg_list[i].enable_load); > >> + > >> + if (ret < 0) { > >> + dev_err(hsphy->dev, "unable to set HPM of %s %d\n", > >> + hsphy->vregs[i].supply, ret); > >> + goto err_vdd; > >> + } > >> + } > >> + > >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > >> + ret = regulator_set_voltage(hsphy->vregs[i].consumer, > >> + hsphy->vreg_list[i].min_voltage, > >> + hsphy->vreg_list[i].max_voltage); > >> + if (ret) { > >> + dev_err(hsphy->dev, > >> + "unable to set voltage of regulator %s %d\n", > >> + hsphy->vregs[i].supply, ret); > >> + goto put_vdd_lpm; > >> + } > >> + } > >> + > >> + ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > >> + if (ret) > >> + goto unconfig_vdd; > >> + > >> + return ret; > >> + > >> +disable_vdd: > >> + regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > >> + > >> +unconfig_vdd: > >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > >> + ret = regulator_set_voltage(hsphy->vregs[i].consumer, 0, > >> + hsphy->vreg_list[i].max_voltage); > >> + if (ret) { > >> + dev_err(hsphy->dev, > >> + "unable to set voltage of regulator %s %d\n", > >> + hsphy->vregs[i].supply, ret); > >> + } > >> + } > >> + > >> +put_vdd_lpm: > >> + for (i = 0; i < SNPS_HS_NUM_VREGS; i++) { > >> + ret = regulator_set_load(hsphy->vregs[i].consumer, 0); > >> + > >> + if (ret < 0) { > >> + dev_err(hsphy->dev, "unable to set LPM of %s %d\n", > >> + hsphy->vregs[i].supply, ret); > >> + } > >> + } > >> + > >> +err_vdd: > >> + return ret; > >> + > >> +} > >> + > >> +static int vdda_phy_bulk_enable(struct qcom_snps_hsphy *hsphy) > >> +{ > >> + return __vdda_phy_bulk_enable_disable(hsphy, true); > >> +} > >> + > >> +static int vdda_phy_bulk_disable(struct qcom_snps_hsphy *hsphy) > >> +{ > >> + return __vdda_phy_bulk_enable_disable(hsphy, false); > >> +} > >> + > >> static int qcom_snps_hsphy_clk_init(struct qcom_snps_hsphy *hsphy) > >> { > >> struct device *dev = hsphy->dev; > >> @@ -390,7 +496,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) > >> > >> dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__); > >> > >> - ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > >> + ret = vdda_phy_bulk_enable(hsphy); > >> if (ret) > >> return ret; > >> > >> @@ -471,7 +577,7 @@ static int qcom_snps_hsphy_init(struct phy *phy) > >> disable_clks: > >> clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); > >> poweroff_phy: > >> - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > >> + ret = vdda_phy_bulk_disable(hsphy); > >> > >> return ret; > >> } > >> @@ -482,7 +588,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy) > >> > >> reset_control_assert(hsphy->phy_reset); > >> clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks); > >> - regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs); > >> + vdda_phy_bulk_disable(hsphy); > >> hsphy->phy_initialized = false; > >> > >> return 0; > >> @@ -592,8 +698,9 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev) > >> > >> num = ARRAY_SIZE(hsphy->vregs); > >> for (i = 0; i < num; i++) > >> - hsphy->vregs[i].supply = qcom_snps_hsphy_vreg_names[i]; > >> + hsphy->vregs[i].supply = hsphy_vreg_l[i].name; > >> > >> + hsphy->vreg_list = hsphy_vreg_l; > >> ret = devm_regulator_bulk_get(dev, num, hsphy->vregs); > >> if (ret) > >> return dev_err_probe(dev, ret, > >> -- > >> 2.17.1 > > -Udipto -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-02 13:12 ` Dmitry Baryshkov 2024-05-03 5:23 ` Udipto Goswami @ 2024-05-07 11:43 ` Konrad Dybcio 2024-05-07 11:55 ` Dmitry Baryshkov 1 sibling, 1 reply; 8+ messages in thread From: Konrad Dybcio @ 2024-05-07 11:43 UTC (permalink / raw) To: Dmitry Baryshkov, Udipto Goswami Cc: Bjorn Andersson, Vinod Koul, Kishon Vijay Abraham I, linux-arm-msm, linux-phy, linux-kernel On 5/2/24 15:12, Dmitry Baryshkov wrote: > On Thu, 2 May 2024 at 15:33, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: >> >> The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. >> If one of the regulators is not voted to the required minimum voltage >> for phy to operate, then High speed mode of operation will fail. >> >> On certain targets like (qcm6490_rb3gen2) where the minimum voltage >> of the regulator is lower than the operating voltage of the phy. >> If not voted properly, the phy supply would be limited to the min value >> of the LDO thereby rendering the phy non-operational. >> >> The current implementation of the regulators in the Femto PHY is not >> setting the load and voltage for each LDO. The appropriate voltages and >> loads required for the PHY to operate should be set. > > Please move min/max voltages to the DTS. There is no need to set them > from the driver. > > Also, is there any reason why you can't use `regulator-initial-mode = > <RPMH_REGULATOR_MODE_HPM>;` like other boards do? The point is to aggregate the values and switch to HPM if a threshold is crossed (or stay in LPM otherwise) Konrad ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-07 11:43 ` Konrad Dybcio @ 2024-05-07 11:55 ` Dmitry Baryshkov 2024-05-07 13:41 ` Konrad Dybcio 0 siblings, 1 reply; 8+ messages in thread From: Dmitry Baryshkov @ 2024-05-07 11:55 UTC (permalink / raw) To: Konrad Dybcio Cc: Udipto Goswami, Bjorn Andersson, Vinod Koul, Kishon Vijay Abraham I, linux-arm-msm, linux-phy, linux-kernel On Tue, 7 May 2024 at 14:43, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > On 5/2/24 15:12, Dmitry Baryshkov wrote: > > On Thu, 2 May 2024 at 15:33, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: > >> > >> The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. > >> If one of the regulators is not voted to the required minimum voltage > >> for phy to operate, then High speed mode of operation will fail. > >> > >> On certain targets like (qcm6490_rb3gen2) where the minimum voltage > >> of the regulator is lower than the operating voltage of the phy. > >> If not voted properly, the phy supply would be limited to the min value > >> of the LDO thereby rendering the phy non-operational. > >> > >> The current implementation of the regulators in the Femto PHY is not > >> setting the load and voltage for each LDO. The appropriate voltages and > >> loads required for the PHY to operate should be set. > > > > Please move min/max voltages to the DTS. There is no need to set them > > from the driver. > > > > Also, is there any reason why you can't use `regulator-initial-mode = > > <RPMH_REGULATOR_MODE_HPM>;` like other boards do? > > The point is to aggregate the values and switch to HPM if a threshold is > crossed (or stay in LPM otherwise) I see that other boards use regulator-initial-mode for the USB PHY regulators. Are we going to change all of them too? Also note, that while the combo QMP driver sets the loads, the pure USB QMP PHY driver doesn't set the loads. This way we can end up with the undervolted PHY. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-07 11:55 ` Dmitry Baryshkov @ 2024-05-07 13:41 ` Konrad Dybcio 0 siblings, 0 replies; 8+ messages in thread From: Konrad Dybcio @ 2024-05-07 13:41 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Udipto Goswami, Bjorn Andersson, Vinod Koul, Kishon Vijay Abraham I, linux-arm-msm, linux-phy, linux-kernel On 5/7/24 13:55, Dmitry Baryshkov wrote: > On Tue, 7 May 2024 at 14:43, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 5/2/24 15:12, Dmitry Baryshkov wrote: >>> On Thu, 2 May 2024 at 15:33, Udipto Goswami <quic_ugoswami@quicinc.com> wrote: >>>> >>>> The Femto phy depends on 0.88/ 1.8/ 3.3V regulators for its operation. >>>> If one of the regulators is not voted to the required minimum voltage >>>> for phy to operate, then High speed mode of operation will fail. >>>> >>>> On certain targets like (qcm6490_rb3gen2) where the minimum voltage >>>> of the regulator is lower than the operating voltage of the phy. >>>> If not voted properly, the phy supply would be limited to the min value >>>> of the LDO thereby rendering the phy non-operational. >>>> >>>> The current implementation of the regulators in the Femto PHY is not >>>> setting the load and voltage for each LDO. The appropriate voltages and >>>> loads required for the PHY to operate should be set. >>> >>> Please move min/max voltages to the DTS. There is no need to set them >>> from the driver. >>> >>> Also, is there any reason why you can't use `regulator-initial-mode = >>> <RPMH_REGULATOR_MODE_HPM>;` like other boards do? >> >> The point is to aggregate the values and switch to HPM if a threshold is >> crossed (or stay in LPM otherwise) > > I see that other boards use regulator-initial-mode for the USB PHY > regulators. Are we going to change all of them too? Not sure about initial mode yet. > Also note, that while the combo QMP driver sets the loads, the pure > USB QMP PHY driver doesn't set the loads. This way we can end up with > the undervolted PHY. Sounds like something to fix, then Konrad ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used 2024-05-02 12:33 [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used Udipto Goswami 2024-05-02 13:12 ` Dmitry Baryshkov @ 2024-05-03 5:37 ` kernel test robot 1 sibling, 0 replies; 8+ messages in thread From: kernel test robot @ 2024-05-03 5:37 UTC (permalink / raw) To: Udipto Goswami, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I Cc: oe-kbuild-all, linux-arm-msm, linux-phy, linux-kernel, Udipto Goswami Hi Udipto, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.9-rc6 next-20240502] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Udipto-Goswami/phy-qcom-snps-femto-v2-Add-load-and-voltage-setting-for-LDO-s-used/20240502-203521 base: linus/master patch link: https://lore.kernel.org/r/20240502123312.31083-1-quic_ugoswami%40quicinc.com patch subject: [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used config: x86_64-buildonly-randconfig-003-20240503 (https://download.01.org/0day-ci/archive/20240503/202405031311.9f1PrPou-lkp@intel.com/config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240503/202405031311.9f1PrPou-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202405031311.9f1PrPou-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c:168: warning: Function parameter or struct member 'vreg_list' not described in 'qcom_snps_hsphy' vim +168 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c df2217ff17a820 Krishna Kurapati 2022-09-06 136 51e8114f80d076 Wesley Cheng 2020-05-04 137 /** 51e8114f80d076 Wesley Cheng 2020-05-04 138 * struct qcom_snps_hsphy - snps hs phy attributes 51e8114f80d076 Wesley Cheng 2020-05-04 139 * 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 140 * @dev: device structure 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 141 * 51e8114f80d076 Wesley Cheng 2020-05-04 142 * @phy: generic phy 51e8114f80d076 Wesley Cheng 2020-05-04 143 * @base: iomapped memory space for snps hs phy 51e8114f80d076 Wesley Cheng 2020-05-04 144 * 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 145 * @num_clks: number of clocks 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 146 * @clks: array of clocks 51e8114f80d076 Wesley Cheng 2020-05-04 147 * @phy_reset: phy reset control 51e8114f80d076 Wesley Cheng 2020-05-04 148 * @vregs: regulator supplies bulk data 51e8114f80d076 Wesley Cheng 2020-05-04 149 * @phy_initialized: if PHY has been initialized correctly dcbec046507615 Wesley Cheng 2020-06-25 150 * @mode: contains the current mode the PHY is in 2a881183dc5ab2 Krzysztof Kozlowski 2023-05-07 151 * @update_seq_cfg: tuning parameters for phy init 51e8114f80d076 Wesley Cheng 2020-05-04 152 */ 51e8114f80d076 Wesley Cheng 2020-05-04 153 struct qcom_snps_hsphy { 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 154 struct device *dev; 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 155 51e8114f80d076 Wesley Cheng 2020-05-04 156 struct phy *phy; 51e8114f80d076 Wesley Cheng 2020-05-04 157 void __iomem *base; 51e8114f80d076 Wesley Cheng 2020-05-04 158 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 159 int num_clks; 8a0eb8f9b9a002 Adrien Thierry 2023-06-29 160 struct clk_bulk_data *clks; 51e8114f80d076 Wesley Cheng 2020-05-04 161 struct reset_control *phy_reset; 51e8114f80d076 Wesley Cheng 2020-05-04 162 struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS]; 4dac559b5584a2 Udipto Goswami 2024-05-02 163 const struct qcom_snps_hsphy_regulator_data *vreg_list; 51e8114f80d076 Wesley Cheng 2020-05-04 164 51e8114f80d076 Wesley Cheng 2020-05-04 165 bool phy_initialized; dcbec046507615 Wesley Cheng 2020-06-25 166 enum phy_mode mode; df2217ff17a820 Krishna Kurapati 2022-09-06 167 struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS]; 51e8114f80d076 Wesley Cheng 2020-05-04 @168 }; 51e8114f80d076 Wesley Cheng 2020-05-04 169 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-05-07 13:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-05-02 12:33 [PATCH] phy: qcom-snps-femto-v2: Add load and voltage setting for LDO's used Udipto Goswami 2024-05-02 13:12 ` Dmitry Baryshkov 2024-05-03 5:23 ` Udipto Goswami 2024-05-03 18:29 ` Dmitry Baryshkov 2024-05-07 11:43 ` Konrad Dybcio 2024-05-07 11:55 ` Dmitry Baryshkov 2024-05-07 13:41 ` Konrad Dybcio 2024-05-03 5:37 ` kernel test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox