Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1283645

Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips

From Finn Thain <fthain@telegraphics.com.au>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips
Date 2015-12-04 09:40 +0100
Message-ID <qBU4j-h7-33@gated-at.bofh.it> (permalink)
References <qw6Bc-vx-5@gated-at.bofh.it> <qBLaF-34j-3@gated-at.bofh.it> <qBMgq-3Ms-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Ondrej Zary <linux@rainbow-software.org> - 2015-12-04 00:10 +0100
  Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Julian Calaby <julian.calaby@gmail.com> - 2015-12-04 01:20 +0100
    Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Finn Thain <fthain@telegraphics.com.au> - 2015-12-04 09:40 +0100
      Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Julian Calaby <julian.calaby@gmail.com> - 2015-12-05 02:40 +0100
        Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Finn Thain <fthain@telegraphics.com.au> - 2015-12-05 03:20 +0100
          Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Julian Calaby <julian.calaby@gmail.com> - 2015-12-05 03:40 +0100
  Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Finn Thain <fthain@telegraphics.com.au> - 2015-12-04 10:10 +0100
    Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Ondrej Zary <linux@rainbow-software.org> - 2015-12-04 10:40 +0100
  Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips Finn Thain <fthain@telegraphics.com.au> - 2015-12-04 10:30 +0100

csiph-web