Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Mar 2022 17:01:21 +0100
From:   Borislav Petkov <bp@alien8.de>
To:     Yazen Ghannam <yazen.ghannam@amd.com>
Cc:     linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
        mchehab@kernel.org, tony.luck@intel.com, james.morse@arm.com,
        rric@kernel.org, Smita.KoralahalliChannabasappa@amd.com
Subject: Re: [PATCH v4 07/24] EDAC/amd64: Define function to dehash address
Message-ID: <Yiog0a3FnZvV6oSh@zn.tnic>
References: <20220127204115.384161-1-yazen.ghannam@amd.com>
 <20220127204115.384161-8-yazen.ghannam@amd.com>
 <Ygbng0RZ0Pu1fOFj@zn.tnic>
 <YikhDoGD+V7OdBq4@yaz-ubuntu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <YikhDoGD+V7OdBq4@yaz-ubuntu>
Precedence: bulk

On Wed, Mar 09, 2022 at 09:50:06PM +0000, Yazen Ghannam wrote:
> But I can do something like you suggest. There will be an unconditional call
> to dehash_addr(). Helper functions will be called for specific interleave
> modes. Otherwise, it'll return 0 if hashing isn't used.

That sounds like proper design to me. A single function which dehashes
an address and that's the only thing it does but it takes care of all
possible cases.

Yap. :-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette