linux-kernel - Re: [PATCH v1 1/2] dt-bindings: arm: qcom,coresight-tpdm: Rename qcom,dsb-element-size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <729a4c17-9e86-467f-85cf-652c503fa14e@arm.com>
Date: Wed, 14 Feb 2024 16:18:33 +0000
From: Suzuki K Poulose <suzuki.poulose@....com>
To: Rob Herring <robh@...nel.org>
Cc: Mao Jinlong <quic_jinlmao@...cinc.com>, Mike Leach
 <mike.leach@...aro.org>, James Clark <james.clark@....com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Tao Zhang <quic_taozha@...cinc.com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v1 1/2] dt-bindings: arm: qcom,coresight-tpdm: Rename
 qcom,dsb-element-size

On 14/02/2024 16:03, Rob Herring wrote:
> On Wed, Feb 14, 2024 at 9:56 AM Suzuki K Poulose <suzuki.poulose@....com> wrote:
>>
>> On 13/02/2024 22:29, Rob Herring wrote:
>>> On Tue, Feb 13, 2024 at 08:05:17AM -0800, Mao Jinlong wrote:
>>>> Change qcom,dsb-element-size to qcom,dsb-element-bits as the unit is
>>>> bit.
>>>
>>> That may be, but this is an ABI and you are stuck with it. Unless, you
>>> can justify why that doesn't matter. (IIRC, this is new, so maybe no
>>> users yet?)
>>
>> This was added and support queued in v6.8. This change won't make it to
>> v6.8 (given it has to go via two levels and is technically not a fix).
> 
> I'd argue it is a fix. But given no users yet, delaying is fine.

I agree it is a fix, but not something that maintainers would like to
pull it during an rc cycle. As you said, since there are no real users
for this yet (and given it is all under a single vendor), it may be fine
to queue this if the DT maintainers are OK with this.


> 
>> As James also pointed out, it doesn't matter what the name is (now that
>> it has been published).
> 
> v6.8 final is what we consider published.

I can't send this to Greg as a fix. For v6.8. We can fix it for v6.9 cycle.

Suzuki
> 
> Rob