linux-kernel - Re: [PATCH v5 03/13] gunyah: Common types and error codes for Gunyah hypercalls

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: <b738a208-26a8-03fa-b54f-811dd7c649dd@quicinc.com>
Date:   Tue, 11 Oct 2022 11:50:04 -0700
From:   Trilok Soni <quic_tsoni@...cinc.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Elliot Berman <quic_eberman@...cinc.com>
CC:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Arnd Bergmann <arnd@...db.de>,
        Murali Nalajala <quic_mnalajal@...cinc.com>,
        "Srivatsa Vaddagiri" <quic_svaddagi@...cinc.com>,
        Carl van Schaik <quic_cvanscha@...cinc.com>,
        Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        "Will Deacon" <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        <devicetree@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 03/13] gunyah: Common types and error codes for Gunyah
 hypercalls

On 10/11/2022 11:48 AM, Greg Kroah-Hartman wrote:
> On Tue, Oct 11, 2022 at 11:21:36AM -0700, Elliot Berman wrote:
>>
>>
>> On 10/11/2022 12:21 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Oct 10, 2022 at 05:08:30PM -0700, Elliot Berman wrote:
>>>> Add architecture-independent standard error codes, types, and macros for
>>>> Gunyah hypercalls.
>>>>
>>>> Signed-off-by: Elliot Berman <quic_eberman@...cinc.com>
>>>> ---
>>>>    MAINTAINERS                  |  1 +
>>>>    include/asm-generic/gunyah.h | 74 ++++++++++++++++++++++++++++++++++++
>>>>    2 files changed, 75 insertions(+)
>>>>    create mode 100644 include/asm-generic/gunyah.h
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index ef6de7599d98..4fe8cec61551 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -8886,6 +8886,7 @@ L:	linux-arm-msm@...r.kernel.org
>>>>    S:	Supported
>>>>    F:	Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
>>>>    F:	Documentation/virt/gunyah/
>>>> +F:	include/asm-generic/gunyah.h
>>>>    HABANALABS PCI DRIVER
>>>>    M:	Oded Gabbay <ogabbay@...nel.org>
>>>> diff --git a/include/asm-generic/gunyah.h b/include/asm-generic/gunyah.h
>>>> new file mode 100644
>>>> index 000000000000..64a02dd3b5ad
>>>> --- /dev/null
>>>> +++ b/include/asm-generic/gunyah.h
>>>
>>> Why not include/linux/gunyah.h?  Why asm-generic?  This is not an
>>> architecture.
>>>
>>
>> My idea here is to differentiate between code that interacts with hypercalls
>> and code that uses the abstractions provided on top of those hypercalls.
>> include/asm-generic/gunyah.h contains architecture-independent definitions
>> for hypercalls. Hypercalls are architecture-specific.
>>
>> For instance, I wanted to avoid a header file that mixes the definitions for
>> the message-queue mailbox with the hypercall definitions that the
>> message-queue mailbox driver itself uses.
>>
>> I can put it all in include/linux/gunyah.h and delineate with some clear
>> comments, but I initially felt it would be better to have separate header
>> file.
> 
> Please put it all in one place, this is just one tiny driver and should
> not abuse the asm-generic location at all, no one is only going to want
> just this one file, they are going to need the whole thing or nothing.
> 

Let's say when we do the RISC-V port for Gunyah, we may need to move it 
back to asm-generic then?

---Trilok Soni