All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Landge, Sudan" <sudanl@amazon.co.uk>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 3/4] dt-bindings: Add bindings for vmgenid
Date: Wed, 20 Mar 2024 11:24:07 +0100	[thread overview]
Message-ID: <cfdb77c8-e893-41bf-965f-1013f3fc910e@linaro.org> (raw)
In-Reply-To: <f221da06-2a7c-4db3-a0de-870156865631@amazon.co.uk>

On 20/03/2024 11:17, Landge, Sudan wrote:
> 
> On 19/03/2024 15:28, Krzysztof Kozlowski wrote:
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>

Why did you remove all the people from CC list?

>>
>> On 19/03/2024 15:32, Sudan Landge wrote:
>>> Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
>>> ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
>>> ACPI only device.
>> That's not a valid rationale. Second today... we do not add things to
>> bindings just because someone added some crazy or not crazy idea to Linux.
>>
>> Bindings represent the hardware.
>>
>> Please come with real rationale. Even if this is accepted, above reason
>> is just wrong and will be used as an excuse to promote more crap into
>> bindings.
> 
> Thank you for the quick review.
> 
> I will add more details to the problem we are trying to fix with an 
> updated cover letter
> 
> but to summarize the problem briefly:
> 
> Firecracker is a minimalist feature hypervisor and we do not have ACPI 
> support
> 
> for ARM yet. The vmgenid devicetree support looked a better option because
> 
> supporting ACPI on ARM means supporting UEFI which adds a lot of complexity.

That does not convince me. Amount of work for you is not making virtual
stuff real hardware. Come with some other discoverable protocol - you
have full control of both sides of this thing.

> 
>> A nit, subject: drop second/last, redundant "bindings". The
>> "dt-bindings" prefix is already stating that these are bindings.
>> See also:
>> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>>
>> Please use subject prefixes matching the subsystem. You can get them for
>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>> your patch is touching.
> Got it, thanks.
>>> Add a devicetree binding support for vmgenid so that hypervisors
>>> can support vmgenid without the need to support ACPI.
>> Devicetree is not for virtual platforms. Virtual platform can define
>> whatever interface they want (virtio, ACPI, "VTree" (just invented now)).
> Sorry for my lack of experience in this area. I took reference of virtio 
> devices when I
> 
> uploaded the patch. We would still like to support vmgenid via a 
> devicetree so I'll
> 
> revert with a new approach.

There are other solutions, I think. This was discussed already multiple
times.

> 
>>> Signed-off-by: Sudan Landge<sudanl@amazon.com>
>>> ---
>>>   .../devicetree/bindings/vmgenid/vmgenid.yaml  | 57 +++++++++++++++++++
>> No, you do not get your own hardware subsystem. Use existing ones.
> 
> Got it. The changes are related to the "rng" subsystem so I'll rethink 
> if that is the
> 
> right place for this and revert.

Your wrapping is odd. Please use some decent email client.

Anyway, I am not discussing topics semi-private. Keep all maintainers in
loop.

Best regards,
Krzysztof


  parent reply	other threads:[~2024-03-20 10:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19 14:32 [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support Sudan Landge
2024-03-19 14:32 ` [PATCH v1 1/4] virt: vmgenid: rearrange code to make review easier Sudan Landge
2024-03-19 14:32 ` [PATCH v1 2/4] virt: vmgenid: change implementation to use a platform driver Sudan Landge
2024-03-19 14:32 ` [PATCH v1 3/4] dt-bindings: Add bindings for vmgenid Sudan Landge
2024-03-19 15:28   ` Krzysztof Kozlowski
     [not found]     ` <f221da06-2a7c-4db3-a0de-870156865631@amazon.co.uk>
2024-03-20 10:24       ` Krzysztof Kozlowski [this message]
2024-03-20 12:16         ` Landge, Sudan
2024-03-19 14:32 ` [PATCH v1 4/4] virt: vmgenid: add support for devicetree bindings Sudan Landge
2024-03-19 15:30   ` Krzysztof Kozlowski
2024-03-20  8:14   ` kernel test robot
2024-03-20 13:35   ` kernel test robot
2024-03-20 16:54   ` kernel test robot
2024-03-21  1:10   ` kernel test robot
2024-03-19 15:24 ` [PATCH v1 0/4] virt: vmgenid: Add devicetree bindings support Krzysztof Kozlowski
2024-03-20 13:50   ` David Woodhouse
2024-03-20 16:15     ` Rob Herring
2024-03-20 16:55       ` David Woodhouse
2024-03-21 13:32         ` Rob Herring
2024-03-21 17:39           ` Landge, Sudan
2024-03-22  5:40             ` Krzysztof Kozlowski
2024-03-22  8:21               ` David Woodhouse
2024-03-22 13:22                 ` Rob Herring
2024-03-22 14:27                   ` David Woodhouse
2024-03-22 16:39                     ` Landge, Sudan
2024-03-19 15:32 ` Krzysztof Kozlowski

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=cfdb77c8-e893-41bf-965f-1013f3fc910e@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudanl@amazon.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.