linux-kernel - Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus message-connection-id property

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 for Android: free password hash cracker in your pocket

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

Message-ID: <63ca8d08-2fd3-440e-858a-f8d79890016f@kernel.org>
Date: Mon, 14 Jul 2025 09:56:57 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Hardik Garg <hargar@...ux.microsoft.com>
Cc: apais@...rosoft.com, conor+dt@...nel.org, decui@...rosoft.com,
 devicetree@...r.kernel.org, haiyangz@...rosoft.com, hargar@...rosoft.com,
 krzk+dt@...nel.org, kys@...rosoft.com, linux-hyperv@...r.kernel.org,
 linux-kernel@...r.kernel.org, robh@...nel.org, ssengar@...ux.microsoft.com,
 wei.liu@...nel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus
 message-connection-id property

On 14/07/2025 09:48, Hardik Garg wrote:
> Thank you for your review, Krzysztof. I apologize for the delay in 
> my response.

You got review after 8 hours.

You respond after 3 weeks.

> 
>>> What is a connection ID and why it cannot be inferred from existing
>>> system API?
> 
> The connection-id determines which hypervisor communication channel the
> guest should use to talk to the VMBus host. Reading from DeviceTree allows
> platforms to specify their preferred communication channel, making it more
> flexible (I will add this detail in the commit message). Presently, this

We don't add properties to make things flexible.



> value is hardcoded and there is no existing API to read it.
> 
>>> There's a reason why you have here generic property - this is generic
>>> and/or discoverable and/or whatever software interface. Adding now more
>>> properties, just because you made it generic, is not the way.
> 
> Presently the value is hardcoded and we want to provide a functionality to
> the user to specify their prefered communication channel. This is a
> virtualized hardware property for us.

That's not really acceptable reason. With such approach I would add 100
properties to make various things "flexible".

Best regards,
Krzysztof