All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Yehuda Yitschak <yehuday@marvell.com>,
	Jason Cooper <jason@lakedaemon.net>,
	netdev@vger.kernel.org, Hanna Hawa <hannah@marvell.com>,
	Nadav Haklai <nadavh@marvell.com>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Stefan Chulski <stefanc@marvell.com>,
	Marcin Wojtas <mw@semihalf.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCHv2 net-next 09/11] net: mvpp2: simplify MVPP2_PRS_RI_* definitions
Date: Fri, 6 Jan 2017 13:07:27 +0000	[thread overview]
Message-ID: <20170106130727.GB14217@n2100.armlinux.org.uk> (raw)
In-Reply-To: <1482943567-12483-10-git-send-email-thomas.petazzoni@free-electrons.com>

On Wed, Dec 28, 2016 at 05:46:05PM +0100, Thomas Petazzoni wrote:
> Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
> doesn't compile nicely on 64-bit. Moreover, those definitions are in
> fact unneeded, since they are always used in combination with a bit
> mask that ensures only the appropriate bits are modified.
> 
> Therefore, such definitions should just be set to 0x0. For example:
> 
>  #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
>  #define MVPP2_PRS_RI_L2_UCAST                  ~(BIT(9) | BIT(10))
>  #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
>  #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)
> 
> becomes
> 
>  #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
>  #define MVPP2_PRS_RI_L2_UCAST                  0x0
>  #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
>  #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)

So this is a two-bit field in a register with three defined states - I'm
not sure that using BIT() here is really a good idea.  BIT() is fine for
single-bit controls, but I think it adds an additional level of confusion
for multi-bit controls.

Also, the combination of the mask being defined as hex and the controls
using BIT() is particularly not nice.  I think either use one style or
the other, don't mix them.  So either:

  #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
  #define MVPP2_PRS_RI_L2_UCAST                  0x000
  #define MVPP2_PRS_RI_L2_MCAST                  0x200
  #define MVPP2_PRS_RI_L2_BCAST                  0x400

or:

  #define MVPP2_PRS_RI_L2_CAST_MASK              (BIT(10) | BIT(9))
  #define MVPP2_PRS_RI_L2_UCAST                  0
  #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
  #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)

It then becomes obvious that the mask and the settings are changing the
same bits.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 net-next 09/11] net: mvpp2: simplify MVPP2_PRS_RI_* definitions
Date: Fri, 6 Jan 2017 13:07:27 +0000	[thread overview]
Message-ID: <20170106130727.GB14217@n2100.armlinux.org.uk> (raw)
In-Reply-To: <1482943567-12483-10-git-send-email-thomas.petazzoni@free-electrons.com>

On Wed, Dec 28, 2016 at 05:46:05PM +0100, Thomas Petazzoni wrote:
> Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
> doesn't compile nicely on 64-bit. Moreover, those definitions are in
> fact unneeded, since they are always used in combination with a bit
> mask that ensures only the appropriate bits are modified.
> 
> Therefore, such definitions should just be set to 0x0. For example:
> 
>  #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
>  #define MVPP2_PRS_RI_L2_UCAST                  ~(BIT(9) | BIT(10))
>  #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
>  #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)
> 
> becomes
> 
>  #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
>  #define MVPP2_PRS_RI_L2_UCAST                  0x0
>  #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
>  #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)

So this is a two-bit field in a register with three defined states - I'm
not sure that using BIT() here is really a good idea.  BIT() is fine for
single-bit controls, but I think it adds an additional level of confusion
for multi-bit controls.

Also, the combination of the mask being defined as hex and the controls
using BIT() is particularly not nice.  I think either use one style or
the other, don't mix them.  So either:

  #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
  #define MVPP2_PRS_RI_L2_UCAST                  0x000
  #define MVPP2_PRS_RI_L2_MCAST                  0x200
  #define MVPP2_PRS_RI_L2_BCAST                  0x400

or:

  #define MVPP2_PRS_RI_L2_CAST_MASK              (BIT(10) | BIT(9))
  #define MVPP2_PRS_RI_L2_UCAST                  0
  #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
  #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)

It then becomes obvious that the mask and the settings are changing the
same bits.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2017-01-06 13:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-28 16:45 [PATCHv2 net-next 00/11] net: mvpp2: misc improvements and preparation patches Thomas Petazzoni
2016-12-28 16:45 ` Thomas Petazzoni
2016-12-28 16:45 ` [PATCHv2 net-next 01/11] net: mvpp2: handle too large value handling in mvpp2_rx_pkts_coal_set() Thomas Petazzoni
2016-12-28 16:45   ` Thomas Petazzoni
2016-12-28 16:45 ` [PATCHv2 net-next 02/11] net: mvpp2: handle too large value in mvpp2_rx_time_coal_set() Thomas Petazzoni
2016-12-28 16:45   ` Thomas Petazzoni
2017-01-06 12:59   ` Russell King - ARM Linux
2017-01-06 12:59     ` Russell King - ARM Linux
2017-02-02 16:11     ` Thomas Petazzoni
2017-02-02 16:11       ` Thomas Petazzoni
2016-12-28 16:45 ` [PATCHv2 net-next 03/11] net: mvpp2: release reference to txq_cpu[] entry after unmapping Thomas Petazzoni
2016-12-28 16:45   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 04/11] net: mvpp2: remove unused 'tx_skb' field of 'struct mvpp2_tx_queue' Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 05/11] net: mvpp2: drop useless fields in mvpp2_bm_pool and related code Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 06/11] net: mvpp2: simplify mvpp2_bm_bufs_add() Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 07/11] net: mvpp2: remove unused register definitions Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 08/11] net: mvpp2: fix indentation of MVPP2_EXT_GLOBAL_CTRL_DEFAULT Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 09/11] net: mvpp2: simplify MVPP2_PRS_RI_* definitions Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2017-01-06 13:07   ` Russell King - ARM Linux [this message]
2017-01-06 13:07     ` Russell King - ARM Linux
2017-02-02 16:11     ` Thomas Petazzoni
2017-02-02 16:11       ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 10/11] net: mvpp2: switch to build_skb() in the RX path Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-28 16:46 ` [PATCHv2 net-next 11/11] net: mvpp2: enable building on 64-bit platforms Thomas Petazzoni
2016-12-28 16:46   ` Thomas Petazzoni
2016-12-29 17:03 ` [PATCHv2 net-next 00/11] net: mvpp2: misc improvements and preparation patches David Miller
2016-12-29 17:03   ` David Miller
2017-02-02 16:12   ` Thomas Petazzoni
2017-02-02 16:12     ` Thomas Petazzoni

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=20170106130727.GB14217@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=gregory.clement@free-electrons.com \
    --cc=hannah@marvell.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mw@semihalf.com \
    --cc=nadavh@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=stefanc@marvell.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=yehuday@marvell.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.