linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 2/8] x86/platform/uv: Return UV Hubless System Type
Date: Tue, 3 Sep 2019 07:12:28 -0700	[thread overview]
Message-ID: <0eee6d96-e4fc-763b-a8b9-52c85ddd5531@hpe.com> (raw)
In-Reply-To: <20190903064914.GA9914@infradead.org>



On 9/2/2019 11:49 PM, Christoph Hellwig wrote:
>>   static inline bool is_early_uv_system(void)
>>   {
>>   	return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
> 
> No need for the inner braces here.
> 
> But woudn't this be nicer as:
> 
> 	return efi.uv_systab != EFI_INVALID_TABLE_ADDR && efi.uv_systab;
> 
> anyway?

Yes, good catch.  It somehow evolved to this but your suggestion is
much more clear.
> 
>> +#define is_uv_hubless _is_uv_hubless
> 
> Why the weird macro indirection?
> 
>> -static inline int is_uv_hubless(void)	{ return 0; }
>> +static inline int _is_uv_hubless(int uv) { return 0; }
>> +#define is_uv_hubless _is_uv_hubless
> 
> And here again.
> 

Sorry, I should have explained this better.  The problem arises because
we have a number of UV specific kernel modules that support multiple
distributions.  And with back porting to earlier distros we cannot
rely on the KERNEL_VERSION macro to define whether the source is being
built for an earlier kernel.  So this allows an ifdef on the function
name to discover if the kernel is before or after these changes.

The primary motivation is to avoid referencing the hub structures
when there aren't any, thus avoiding any NULL dereferences.  (Similar
to patch 8/8.)

  reply	other threads:[~2019-09-03 14:12 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 [this message]
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
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:02 ` [PATCH 2/8] x86/platform/uv: Return UV Hubless System Type 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 2/8] x86/platform/uv: Return UV Hubless System Type 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=0eee6d96-e4fc-763b-a8b9-52c85ddd5531@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).