All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eliav Farber <farbere@amazon.com>
To: <bp@alien8.de>
Cc: <mchehab@kernel.org>, <linux-edac@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <ronenk@amazon.com>,
	<talel@amazon.com>, <hhhawa@amazon.com>, <jonnyc@amazon.com>,
	<hanochu@amazon.com>, <farbere@amazon.com>
Subject: [PATCH 3/4] EDAC: Refactor edac_align_ptr() to use u8/u16/u32/u64 data types
Date: Thu, 13 Jan 2022 10:06:21 +0000	[thread overview]
Message-ID: <20220113100622.12783-4-farbere@amazon.com> (raw)
In-Reply-To: <20220113100622.12783-1-farbere@amazon.com>

Prefer well defined size variables, that are same in size across all
systems.

Signed-off-by: Eliav Farber <farbere@amazon.com>
---
 drivers/edac/edac_mc.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index 8b9b86a7720a..3367bf997b73 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -250,18 +250,13 @@ void *edac_align_ptr(void **p, unsigned size, int n_elems)
 	 * 'size'.  Adjust 'p' so that its alignment is at least as
 	 * stringent as what the compiler would provide for X and return
 	 * the aligned result.
-	 * Here we assume that the alignment of a "long long" is the most
-	 * stringent alignment that the compiler will ever provide by default.
-	 * As far as I know, this is a reasonable assumption.
 	 */
-	if (size > sizeof(long))
-		align = sizeof(long long);
-	else if (size > sizeof(int))
-		align = sizeof(long);
-	else if (size > sizeof(short))
-		align = sizeof(int);
-	else if (size > sizeof(char))
-		align = sizeof(short);
+	if (size > sizeof(u32))
+		align = sizeof(u64);
+	else if (size > sizeof(u16))
+		align = sizeof(u32);
+	else if (size > sizeof(u8))
+		align = sizeof(u16);
 	else
 		return ptr;
 
-- 
2.32.0


  parent reply	other threads:[~2022-01-13 10:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 10:06 [PATCH 0/4] edac_align_ptr() bug fix and refactoring Eliav Farber
2022-01-13 10:06 ` [PATCH 1/4] EDAC: Fix calculation of returned address and next offset in edac_align_ptr() Eliav Farber
2022-01-25 14:37   ` Borislav Petkov
2022-01-27  9:58     ` Farber, Eliav
2022-02-15 12:34       ` Borislav Petkov
2022-02-15 13:06         ` Farber, Eliav
2022-01-13 10:06 ` [PATCH 2/4] EDAC: Remove unnecessary cast to char* in edac_align_ptr() function Eliav Farber
2022-01-26 18:46   ` Borislav Petkov
2022-01-13 10:06 ` Eliav Farber [this message]
2022-02-15 16:55   ` [PATCH 3/4] EDAC: Refactor edac_align_ptr() to use u8/u16/u32/u64 data types Borislav Petkov
2022-01-13 10:06 ` [PATCH 4/4] EDAC: Refactor edac_align_ptr() flow Eliav Farber
2022-02-15 17:08   ` Borislav Petkov

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=20220113100622.12783-4-farbere@amazon.com \
    --to=farbere@amazon.com \
    --cc=bp@alien8.de \
    --cc=hanochu@amazon.com \
    --cc=hhhawa@amazon.com \
    --cc=jonnyc@amazon.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ronenk@amazon.com \
    --cc=talel@amazon.com \
    /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.