From: Sven Schnelle <svens@stackframe.org>
To: Helge Deller <deller@gmx.de>
Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>, linux-parisc@vger.kernel.org
Subject: Re: [PATCH 1/2] parisc/firmware: add functions to retrieve TOC data
Date: Tue, 12 Oct 2021 22:33:00 +0200 [thread overview]
Message-ID: <875yu20yrn.fsf@x1.stackframe.org> (raw)
In-Reply-To: <9567f761-5100-b367-32f9-a6b39094d630@gmx.de> (Helge Deller's message of "Mon, 11 Oct 2021 22:13:11 +0200")
Helge Deller <deller@gmx.de> writes:
> On 10/11/21 17:05, Rolf Eike Beer wrote:
>>> --- a/arch/parisc/include/uapi/asm/pdc.h
>>> +++ b/arch/parisc/include/uapi/asm/pdc.h
>>> @@ -689,6 +689,28 @@ struct pdc_hpmc_pim_20 { /* PDC_PIM */
>>> unsigned long long fr[32];
>>> };
>>>
>>> +struct pdc_toc_pim_11 {
>>> + unsigned int gr[32];
>>> + unsigned int cr[32];
>>> + unsigned int sr[8];
>>> + unsigned int iasq_back;
>>> + unsigned int iaoq_back;
>>> + unsigned int check_type;
>>> + unsigned int hversion;
>>> + unsigned int cpu_state;
>>> +};
>>> +
>>> +struct pdc_toc_pim_20 {
>>> + unsigned long long gr[32];
>>> + unsigned long long cr[32];
>>> + unsigned long long sr[8];
>>> + unsigned long long iasq_back;
>>> + unsigned long long iaoq_back;
>>> + unsigned int check_type;
>>> + unsigned int hversion;
>>> + unsigned int cpu_state;
>>> +};
>>> +
>>> #endif /* !defined(__ASSEMBLY__) */
>>
>> Since these are defined by the hardware and have a well defined size I suggest
>> using u32 and u64 to cover this.
>
> You're right.
> But in the whole file we use "unsigned int" for 32bit, and "unsigned long long"
> for 64bit, so this change is consistent with the other contents.
Yes, especially the 'unsigned long long' catched my eye. However, i kept
it that way so it is consistent with the other structs. I'm happy to
change the types with a cleanup patch, but i'm wondering: why is that
all uapi? IMHO this should go to include/asm? Any objections against
moving it? I don't see how userspace could use that given that only the
kernel should be able to call into firmware.
next prev parent reply other threads:[~2021-10-12 20:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 18:38 [PATCH v2 0/2] add TOC support Sven Schnelle
2021-10-10 18:38 ` [PATCH 1/2] parisc/firmware: add functions to retrieve TOC data Sven Schnelle
2021-10-11 15:05 ` Rolf Eike Beer
2021-10-11 20:13 ` Helge Deller
2021-10-12 20:33 ` Sven Schnelle [this message]
2021-10-12 20:52 ` Helge Deller
2021-10-10 18:38 ` [PATCH 2/2] parisc: add support for TOC (transfer of control) Sven Schnelle
2021-10-10 19:31 ` Helge Deller
2021-10-10 19:36 ` Sven Schnelle
2021-10-12 10:03 ` Helge Deller
2021-10-15 16:22 ` Rolf Eike Beer
-- strict thread matches above, loose matches on Subject: below --
2021-10-09 21:38 [PATCH 0/2] add TOC support Sven Schnelle
2021-10-09 21:38 ` [PATCH 1/2] parisc/firmware: add functions to retrieve TOC data Sven Schnelle
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=875yu20yrn.fsf@x1.stackframe.org \
--to=svens@stackframe.org \
--cc=deller@gmx.de \
--cc=eike-kernel@sf-tec.de \
--cc=linux-parisc@vger.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 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.