From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Rosen Penev <rosenp@gmail.com>,
linux-phy@lists.infradead.org
Cc: Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
"open list:ARM/QUALCOMM MAILING LIST"
<linux-arm-msm@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
open "list:KERNEL" HARDENING "(not" covered by other
"areas):Keyword:b__counted_by(_le|_be)?b"
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array
Date: Tue, 10 Mar 2026 14:39:01 +0100 [thread overview]
Message-ID: <f677e96f-2d7f-44b9-b06e-3d184777b50f@oss.qualcomm.com> (raw)
In-Reply-To: <5bcef6ea-e83b-47c3-b75a-cfd13e4073c7@embeddedor.com>
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
prev parent reply other threads:[~2026-03-10 13:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 23:06 [PATCH] phy: qualcomm: usb-hs-28nm: use flex array Rosen Penev
2026-03-05 10:06 ` Konrad Dybcio
2026-03-05 4:52 ` Gustavo A. R. Silva
2026-03-10 13:39 ` Konrad Dybcio [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f677e96f-2d7f-44b9-b06e-3d184777b50f@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=gustavo@embeddedor.com \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=rosenp@gmail.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox