[PATCH] phy: qualcomm: usb-hs-28nm: use flex array

[PATCH] phy: qualcomm: usb-hs-28nm: use flex array

[Rosen Penev]

Allows simplifying allocation to a single kzalloc call.

Also allows using __counted_by for extra runtime analysis.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c b/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
index a52a9bf13b75..b2ea038a8f25 100644
--- a/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
+++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
@@ -56,13 +56,13 @@ struct hsphy_data {
 
 struct hsphy_priv {
 	void __iomem *base;
-	struct clk_bulk_data *clks;
 	int num_clks;
 	struct reset_control *phy_reset;
 	struct reset_control *por_reset;
 	struct regulator_bulk_data vregs[VREG_NUM];
 	const struct hsphy_data *data;
 	enum phy_mode mode;
+	struct clk_bulk_data clks[] __counted_by(num_clks);
 };
 
 static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode,
@@ -309,23 +309,21 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 	struct phy_provider *provider;
 	struct hsphy_priv *priv;
 	struct phy *phy;
+	size_t size;
 	int ret;
 	int i;
 
-	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	size = ARRAY_SIZE(qcom_snps_hsphy_clks);
+	priv = devm_kzalloc(dev, struct_size(priv, clks, size), GFP_KERNEL);
 	if (!priv)
 		return -ENOMEM;
 
+	priv->num_clks = size;
+
 	priv->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(priv->base))
 		return PTR_ERR(priv->base);
 
-	priv->num_clks = ARRAY_SIZE(qcom_snps_hsphy_clks);
-	priv->clks = devm_kcalloc(dev, priv->num_clks, sizeof(*priv->clks),
-				  GFP_KERNEL);
-	if (!priv->clks)
-		return -ENOMEM;
-
 	for (i = 0; i < priv->num_clks; i++)
 		priv->clks[i].id = qcom_snps_hsphy_clks[i];
 
-- 
2.53.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array

[Gustavo A. R. Silva]

Hi!

On 3/5/26 19:06, Konrad Dybcio wrote:
> On 3/5/26 12:06 AM, Rosen Penev wrote:
>> Allows simplifying allocation to a single kzalloc call.
>>
>> Also allows using __counted_by for extra runtime analysis.
>>
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> ---
> 
> I don't see how this is an improvement - __counted_by() is useful for
> cases where we don't know how many entries there are, but in this
> case it's fully deterministic (as priv->num_clks is a compile-time
> constant)

Will this always be the case in the future (entries being a compile-time
constant)?

Thanks
-Gustavo

> 
> Konrad
> 


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array

[Konrad Dybcio]

On 3/5/26 12:06 AM, Rosen Penev wrote:
> Allows simplifying allocation to a single kzalloc call.
> 
> Also allows using __counted_by for extra runtime analysis.
> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---

I don't see how this is an improvement - __counted_by() is useful for
cases where we don't know how many entries there are, but in this
case it's fully deterministic (as priv->num_clks is a compile-time
constant)

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array

[Konrad Dybcio]

On 3/5/26 5:52 AM, Gustavo A. R. Silva wrote:
> Hi!
> 
> On 3/5/26 19:06, Konrad Dybcio wrote:
>> On 3/5/26 12:06 AM, Rosen Penev wrote:
>>> Allows simplifying allocation to a single kzalloc call.
>>>
>>> Also allows using __counted_by for extra runtime analysis.
>>>
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>
>> I don't see how this is an improvement - __counted_by() is useful for
>> cases where we don't know how many entries there are, but in this
>> case it's fully deterministic (as priv->num_clks is a compile-time
>> constant)
> 
> Will this always be the case in the future (entries being a compile-time
> constant)?

While I'm not high up enough to make those decisions, and if I were, I
would very much not be allowed to disclose them, my personal prediction
is that we are probably not going to make many more 28nm chips, if any
(see filename)

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy