From: Mike Travis <mike.travis@hpe.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Borislav Petkov <bp@alien8.de>,
Dimitri Sivanich <dimitri.sivanich@hpe.com>,
Russ Anderson <russ.anderson@hpe.com>,
Hedi Berriche <hedi.berriche@hpe.com>,
Steve Wahl <steve.wahl@hpe.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub Ops
Date: Tue, 3 Sep 2019 12:03:14 -0700 [thread overview]
Message-ID: <5274bb4e-f063-4a13-72aa-9231da2f7092@hpe.com> (raw)
In-Reply-To: <98e34464-f9b7-6e78-6528-96b83f094282@hpe.com>
On 9/3/2019 11:58 AM, Mike Travis wrote:
>
>
> On 9/3/2019 9:19 AM, Christoph Hellwig wrote:
>> On Mon, Sep 02, 2019 at 07:18:23PM -0500, Mike Travis wrote:
>>> +#ifdef UV1_HUB_IS_SUPPORTED
>>
>> All these ifdefs are dead code, please just remove them.
>
> Those ifdefs are not dead code and are being actively used. Plus UV1
> support is dead and I think the last running system died about a year
> ago and no support or parts are available. So undef'ing these macros
> will simplify and reduce the size of the object code.
I forgot to add that if we do undef one of those "is supported" the code
will eventually be removed, thus simplifying the source even more. So
including the ifdef's in the source make that code easier to find.
>
>> Also it seems like at least the various mmr macros just check
>> for a specific version, I think you are much better off just
>> using a switch statement for the possible revisions there.
>>
>>> + return (uv_hub_info->hub_revision == UV4A_HUB_REVISION_BASE);
>
> The problem is those revision bases can change if a UV HUB revision
> changes. That is why there are ranges and why I'm converting them to
> "uv_type". Some UV kernel source code still needs to know the exact HUB
> revision, like (again) hwperf.
>
>>
>> And none of these braces are required.
>>
>
> Sure, I can take those out now, but usually I then get bit by
> checkpatches which then says "parenthesis's are required".
next prev parent reply other threads:[~2019-09-03 19:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 0:18 [PATCH 0/8] x86/platform/UV: Update UV Hubless System Support Mike Travis
2019-09-03 0:18 ` [PATCH 1/8] x86/platform/uv: Save OEM_ID from ACPI MADT probe Mike Travis
2019-09-03 0:18 ` [PATCH 2/8] x86/platform/uv: Return UV Hubless System Type Mike Travis
2019-09-03 6:49 ` Christoph Hellwig
2019-09-03 14:12 ` Mike Travis
2019-09-03 15:41 ` Christoph Hellwig
2019-09-03 18:49 ` Mike Travis
2019-09-04 6:50 ` Christoph Hellwig
2019-09-03 0:18 ` [PATCH 3/8] x86/platform/uv: Add return code to UV BIOS Init function Mike Travis
2019-09-03 0:18 ` [PATCH 4/8] x86/platform/uv: Setup UV functions for Hubless UV Systems Mike Travis
2019-09-03 0:18 ` [PATCH 5/8] x86/platform/uv: Add UV Hubbed/Hubless Proc FS Files Mike Travis
2019-09-03 6:50 ` Christoph Hellwig
2019-09-03 0:18 ` [PATCH 6/8] x86/platform/uv: Decode UVsystab Info Mike Travis
2019-09-03 6:22 ` Greg KH
2019-09-03 0:18 ` [PATCH 7/8] x86/platform/uv: Check EFI Boot to set reboot type Mike Travis
2019-09-03 0:18 ` [PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub Ops Mike Travis
2019-09-03 16:19 ` Christoph Hellwig
2019-09-03 18:58 ` Mike Travis
2019-09-03 19:03 ` Mike Travis [this message]
2019-09-04 6:52 ` Christoph Hellwig
2019-09-04 10:18 ` Mike Travis
2019-09-03 7:47 ` [PATCH 0/8] x86/platform/UV: Update UV Hubless System Support Ingo Molnar
2019-09-03 14:17 ` Mike Travis
2019-09-05 8:19 ` Ingo Molnar
2019-09-05 13:02 Mike Travis
2019-09-05 13:03 ` [PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub Ops Mike Travis
2019-09-05 18:47 [PATCH 0/8] x86/platform/UV: Update UV Hubless System Support Mike Travis
2019-09-05 18:47 ` [PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub Ops Mike Travis
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=5274bb4e-f063-4a13-72aa-9231da2f7092@hpe.com \
--to=mike.travis@hpe.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dimitri.sivanich@hpe.com \
--cc=hch@infradead.org \
--cc=hedi.berriche@hpe.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=russ.anderson@hpe.com \
--cc=stable@vger.kernel.org \
--cc=steve.wahl@hpe.com \
--cc=tglx@linutronix.de \
--cc=x86@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).