[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1512041857160.13680@nippy.intranet>
Date: Fri, 4 Dec 2015 19:38:03 +1100 (AEDT)
From: Finn Thain <fthain@...egraphics.com.au>
To: Julian Calaby <julian.calaby@...il.com>
cc: Ondrej Zary <linux@...nbow-software.org>,
Michael Schmitz <schmitzmic@...il.com>,
linux-m68k@...r.kernel.org,
linux-scsi <linux-scsi@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips
On Fri, 4 Dec 2015, Julian Calaby wrote:
> > - if (overrides[current_override].board == BOARD_NCR53C400A) {
> > + if (overrides[current_override].board == BOARD_NCR53C400A ||
> > + overrides[current_override].board == BOARD_DTC3181E) {
>
> These if statements are starting to get a bit long, would it make
> sense to replace them with a flag or equivalent?
To what end? Shorter lines? As in,
if (board_is_ncr53c400a || board_is_dtc3181e) {
/* ... */
}
I suppose that could be an improvement if new flags would entirely replace
the override.board struct member and the existing switch statement,
switch (overrides[current_override].board) {
/* ... */
}
Or maybe you meant testing a new flag something like this,
if (hostdata->ncr53c400_compatible) {
/* ... */
}
If your concern is the Don't Repeat Yourself rule, I'm not sure that new
flag would get tested more than once (?) And it would still have to be
assigned using an "objectionably" long expression, e.g.
hostdata->ncr53c400_compatible =
overrides[current_override].board == BOARD_NCR53C400 ||
overrides[current_override].board == BOARD_NCR53C400A ||
overrides[current_override].board == BOARD_DTC3181E;
Rather than add new flags, perhaps a 'switch' statement instead of an 'if'
statement would be shorter (if the size of the expression is the problem).
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists