From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Josh Boyer <jwboyer@redhat.com>
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix sb_edac compilation with 32 bits kernels
Date: Mon, 07 Nov 2011 19:54:15 -0200 [thread overview]
Message-ID: <4EB85387.2050008@redhat.com> (raw)
In-Reply-To: <20111107213730.GD14216@zod.bos.redhat.com>
Em 07-11-2011 19:37, Josh Boyer escreveu:
> On Mon, Nov 07, 2011 at 07:29:45PM -0200, Mauro Carvalho Chehab wrote:
>> @@ -670,6 +671,7 @@ static void get_memory_layout(const struct mem_ctl_info *mci)
>> u32 reg;
>> u64 limit, prv = 0;
>> u64 tmp_mb;
>> + u32 mb, kb;
>> u32 rir_way;
>>
>> /*
>> @@ -682,8 +684,9 @@ static void get_memory_layout(const struct mem_ctl_info *mci)
>> pvt->tolm = GET_TOLM(reg);
>> tmp_mb = (1 + pvt->tolm) >> 20;
>>
>> - debugf0("TOLM: %Lu.%03Lu GB (0x%016Lx)\n",
>> - tmp_mb / 1000, tmp_mb % 1000, (u64)pvt->tolm);
>> + mb = div_u64_rem(tmp_mb, 1000, &kb);
>> + debugf0("TOLM: %u.%03u GB (0x%016Lx)\n",
>> + mb, kb, (u64)pvt->tolm);
>
> So I realize you said that EDAC_DEBUG should (for now) always be enabled
> when this driver is built, but you just added a bunch of 64-bit divides
> outside of the debugfX stuff. Doesn't that mean you'll be doing those
> divides in the non-debug case as well, and then most likely getting an
> unused varible warning when you turn EDAC_DEBUG off?
You're right. Some additional logic is needed to remove the warnings and
unneeded calculus when debug is disabled. I may eventually work on it when
I have time. In any case, we gave a fix already for kernel 3.2, and this
patch is an alternative for those brave enough to test this driver with a 32 bits PAE
kernel.
>
>> @@ -858,7 +868,7 @@ static int get_memory_error_data(struct mem_ctl_info *mci,
>> * range (e. g. VGA addresses). It is unlikely, however, that the
>> * memory controller would generate an error on that range.
>> */
>> - if ((addr > (u64) pvt->tolm) && (addr < (1L << 32))) {
>> + if ((addr > (u64) pvt->tolm) && (addr < (1LL << 32))) {
>> sprintf(msg, "Error at TOLM area, on addr 0x%08Lx", addr);
>> edac_mc_handle_ce_no_info(mci, msg);
>> return -EINVAL;
>> @@ -1053,7 +1063,7 @@ static int get_memory_error_data(struct mem_ctl_info *mci,
>> ch_addr = addr & 0x7f;
>> /* Remove socket wayness and remove 6 bits */
>> addr >>= 6;
>> - addr /= sck_xch;
>> + addr = div_u64(addr, sck_xch);
>> #if 0
>> /* Divide by channel way */
>> addr = addr / ch_way;
>
> Those two parts look ok.
>
> josh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-11-07 21:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 14:07 sb_edac 32-bit compile fail due to 64-bit divide Josh Boyer
2011-11-03 14:32 ` Mauro Carvalho Chehab
2011-11-03 14:43 ` Josh Boyer
2011-11-03 16:31 ` Luck, Tony
2011-11-03 17:41 ` Mauro Carvalho Chehab
2011-11-03 17:48 ` Josh Boyer
2011-11-03 17:51 ` Mauro Carvalho Chehab
2011-11-03 17:20 ` Mauro Carvalho Chehab
2011-11-07 21:29 ` [PATCH] Fix sb_edac compilation with 32 bits kernels Mauro Carvalho Chehab
2011-11-07 21:37 ` Josh Boyer
2011-11-07 21:54 ` Mauro Carvalho Chehab [this message]
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=4EB85387.2050008@redhat.com \
--to=mchehab@redhat.com \
--cc=jwboyer@redhat.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@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 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.