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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).