From: Borislav Petkov <bp@amd64.org>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/30] amd64_edac: Cleanup chipselect handling
Date: Tue, 29 Mar 2011 18:02:11 +0200 [thread overview]
Message-ID: <20110329160211.GC22419@aftab> (raw)
In-Reply-To: <4D91FD1D.4070508@redhat.com>
On Tue, Mar 29, 2011 at 11:39:09AM -0400, Mauro Carvalho Chehab wrote:
> >>> + * Create a contiguous bitmask starting at bit position @lo and ending at
> >>> + * position @hi. For example
> >>> + *
> >>> + * GENMASK(21, 39) gives us the 64bit vector 0x000000ffffe00000.
> >>> + */
> >>> +#define GENMASK(lo, hi) (((1ULL << ((hi) - (lo) + 1)) - 1) << (lo))
> >>> +
> >>
> >> This is a nice macro that could be useful outside amd64. It is probably a good
> >> idea to move it to include/linux/bitops.h.
> >
> > I'd suggest rather <drivers/edac/edac_core.h> if you want to use it in
> > EDAC. But if we have more users, I don't have a problem with putting
> > it there (or somewhere else generic enough if people have a better
> > suggestion).
>
> Yeah, other edac drivers could benefit of using it, and also could benefit on a
> variant that would do an AND operation and shift it, something like (untested):
>
> /*
> * Create a contiguous bitmask starting at bit position @lo and ending at
> * position @hi. For example
> *
> * APPLY_BITMASK(v, 21, 39) will return the result of:
> * (v & 0x000000ffffe00000) >> 21
> */
> #define APPLY_BITMASK(v, lo, hi) (((v) & ((1ULL << ((hi) - (lo) + 1)) - 1) << (lo)) >> (lo))
The macro definition doesn't match the comment. In the comment you do a bitwise
AND first and shift the result then. The way you've written it, it does
((v & 0x000000000007ffff << 21) >> 21)
you need to fixup the brackets:
#define APPLY_BITMASK(v, lo, hi) (((v) & (((1ULL << ((hi) - (lo) + 1)) - 1) << (lo))) >> (lo))
Also, this doesn't only apply it but shifts too, so it should be
#define APPLY_BITMASK_AND_SHIFT(...)
But this macro gets too special to put it in shared code.
> Almost all edac drivers do something like the above, for example, to get DIMM rows/cols/banks, etc.
>
> Probably, the most complex part is to find a nice name for it ;)
>
> Yet, I think non-edac drivers could also benefit of such macro, and, as this is not
> edac-specific, I think it would be better to add it at bitops.h.
No, this should go into generic code only if it has users - "it might
benefit" is not strong-enough an argument for polluting generic code.
I'd leave it in edac_core.h and push it somewhere more generic only when
I need it in other subsystems.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2011-03-29 16:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-10 17:15 [PATCH 00/30] amd64_edac: Add Bulldozer support Borislav Petkov
2011-02-10 17:15 ` [PATCH 01/30] EDAC: Shut up sysfs registration debug code Borislav Petkov
2011-02-10 17:15 ` [PATCH 02/30] amd64_edac: Add support for F15h DCT PCI config accesses Borislav Petkov
2011-02-10 17:15 ` [PATCH 03/30] amd64_edac: Remove DRAM base/limit subfields caching Borislav Petkov
2011-02-10 17:15 ` [PATCH 04/30] amd64_edac: Cleanup DHAR handling Borislav Petkov
2011-02-10 17:15 ` [PATCH 05/30] amd64_edac: Cleanup chipselect handling Borislav Petkov
2011-03-29 14:56 ` Mauro Carvalho Chehab
2011-03-29 15:16 ` Borislav Petkov
2011-03-29 15:39 ` Mauro Carvalho Chehab
2011-03-29 16:02 ` Borislav Petkov [this message]
2011-03-29 17:32 ` Mauro Carvalho Chehab
2011-02-10 17:15 ` [PATCH 06/30] amd64_edac: Sanitize channel extraction Borislav Petkov
2011-02-10 17:15 ` [PATCH 07/30] amd64_edac: Sanitize f10_get_base_addr_offset Borislav Petkov
2011-02-10 17:15 ` [PATCH 08/30] amd64_edac: Replace huge bitmasks with a macro Borislav Petkov
2011-02-10 17:15 ` [PATCH 09/30] amd64_edac: Cleanup DBAM handling Borislav Petkov
2011-02-10 17:15 ` [PATCH 10/30] amd64_edac: Cleanup Dram Configuration registers handling Borislav Petkov
2011-02-10 17:15 ` [PATCH 11/30] amd64_edac: Cleanup DCT Select Low/High code Borislav Petkov
2011-02-10 17:15 ` [PATCH 12/30] amd64_edac: Cleanup NBCTL code Borislav Petkov
2011-02-10 17:15 ` [PATCH 13/30] amd64_edac: Cleanup NBCFG handling Borislav Petkov
2011-02-10 17:15 ` [PATCH 14/30] amd64_edac: Cleanup NBSH cruft Borislav Petkov
2011-02-10 17:15 ` [PATCH 15/30] amd64_edac: Cleanup old defines cruft Borislav Petkov
2011-02-10 17:15 ` [PATCH 16/30] amd64_edac: Adjust channel counting to F15h Borislav Petkov
2011-02-10 17:15 ` [PATCH 17/30] amd64_edac: Simplify decoding path Borislav Petkov
2011-02-10 17:15 ` [PATCH 18/30] amd64_edac: Unify get_error_address Borislav Petkov
2011-02-10 17:15 ` [PATCH 19/30] amd64_edac: Add support for interleaved region swapping Borislav Petkov
2011-02-10 17:15 ` [PATCH 20/30] amd64_edac: Correct node interleaving removal Borislav Petkov
2011-02-10 17:15 ` [PATCH 21/30] amd64_edac: Fix channel interleave removal Borislav Petkov
2011-02-10 17:15 ` [PATCH 22/30] amd64_edac: Revamp online spare handling Borislav Petkov
2011-02-10 17:15 ` [PATCH 23/30] amd64_edac: Beef up early exit reporting Borislav Petkov
2011-02-10 17:15 ` [PATCH 24/30] amd64_edac: Adjust sys_addr to chip select conversion routine to F15h Borislav Petkov
2011-02-10 17:15 ` [PATCH 25/30] amd64_edac: Sanitize ->read_dram_ctl_register Borislav Petkov
2011-02-10 17:15 ` [PATCH 26/30] amd64_edac: Improve DRAM address mapping Borislav Petkov
2011-02-10 17:15 ` [PATCH 27/30] PCI: Rename CPU PCI id define Borislav Petkov
2011-02-10 17:15 ` [PATCH 28/30] amd64_edac: Simplify scrubrate setting Borislav Petkov
2011-02-10 17:15 ` [PATCH 29/30] amd64_edac: Adjust ECC symbol size to F15h Borislav Petkov
2011-02-10 17:15 ` [PATCH 30/30] amd64_edac: Enable driver on F15h Borislav Petkov
2011-02-10 18:56 ` [PATCH 00/30] amd64_edac: Add Bulldozer support Greg KH
2011-02-10 19:20 ` Borislav Petkov
2011-02-10 19:22 ` Jesse Barnes
2011-02-10 21:43 ` 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=20110329160211.GC22419@aftab \
--to=bp@amd64.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.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.