diff mbox

[V1,1/3] IB/core: Align coding style of ib_device_cap_flags structure

Message ID 1450606571-15877-2-git-send-email-leon@leon.nu (mailing list archive)
State Accepted
Headers show

Commit Message

Leon Romanovsky Dec. 20, 2015, 10:16 a.m. UTC 
From: Leon Romanovsky <leonro@mellanox.com>

Modify enum ib_device_cap_flags such that other patches which add new
enum values pass strict checkpatch.pl checks.

Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
 include/rdma/ib_verbs.h | 60 ++++++++++++++++++++++++-------------------------
 1 file changed, 30 insertions(+), 30 deletions(-)

Comments

Ira Weiny Dec. 21, 2015, 6:22 a.m. UTC | #1 
On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
> 
> Modify enum ib_device_cap_flags such that other patches which add new
> enum values pass strict checkpatch.pl checks.
> 
> Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
>  include/rdma/ib_verbs.h | 60 ++++++++++++++++++++++++-------------------------
>  1 file changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 9a68a19..bcf40ad 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -105,24 +105,24 @@ enum rdma_link_layer {
>  };
>  
>  enum ib_device_cap_flags {
> -	IB_DEVICE_RESIZE_MAX_WR		= 1,
> -	IB_DEVICE_BAD_PKEY_CNTR		= (1<<1),
> -	IB_DEVICE_BAD_QKEY_CNTR		= (1<<2),
> -	IB_DEVICE_RAW_MULTI		= (1<<3),
> -	IB_DEVICE_AUTO_PATH_MIG		= (1<<4),
> -	IB_DEVICE_CHANGE_PHY_PORT	= (1<<5),
> -	IB_DEVICE_UD_AV_PORT_ENFORCE	= (1<<6),
> -	IB_DEVICE_CURR_QP_STATE_MOD	= (1<<7),
> -	IB_DEVICE_SHUTDOWN_PORT		= (1<<8),
> -	IB_DEVICE_INIT_TYPE		= (1<<9),
> -	IB_DEVICE_PORT_ACTIVE_EVENT	= (1<<10),
> -	IB_DEVICE_SYS_IMAGE_GUID	= (1<<11),
> -	IB_DEVICE_RC_RNR_NAK_GEN	= (1<<12),
> -	IB_DEVICE_SRQ_RESIZE		= (1<<13),
> -	IB_DEVICE_N_NOTIFY_CQ		= (1<<14),
> -	IB_DEVICE_LOCAL_DMA_LKEY	= (1<<15),
> -	IB_DEVICE_RESERVED		= (1<<16), /* old SEND_W_INV */
> -	IB_DEVICE_MEM_WINDOW		= (1<<17),
> +	IB_DEVICE_RESIZE_MAX_WR		= (1 << 0),

NIT: Shouldn't we just use the BIT macro?

	IB_DEVICE_RESIZE_MAX_WR		= BIT(0),

Ira

> +	IB_DEVICE_BAD_PKEY_CNTR		= (1 << 1),
> +	IB_DEVICE_BAD_QKEY_CNTR		= (1 << 2),
> +	IB_DEVICE_RAW_MULTI		= (1 << 3),
> +	IB_DEVICE_AUTO_PATH_MIG		= (1 << 4),
> +	IB_DEVICE_CHANGE_PHY_PORT	= (1 << 5),
> +	IB_DEVICE_UD_AV_PORT_ENFORCE	= (1 << 6),
> +	IB_DEVICE_CURR_QP_STATE_MOD	= (1 << 7),
> +	IB_DEVICE_SHUTDOWN_PORT		= (1 << 8),
> +	IB_DEVICE_INIT_TYPE		= (1 << 9),
> +	IB_DEVICE_PORT_ACTIVE_EVENT	= (1 << 10),
> +	IB_DEVICE_SYS_IMAGE_GUID	= (1 << 11),
> +	IB_DEVICE_RC_RNR_NAK_GEN	= (1 << 12),
> +	IB_DEVICE_SRQ_RESIZE		= (1 << 13),
> +	IB_DEVICE_N_NOTIFY_CQ		= (1 << 14),
> +	IB_DEVICE_LOCAL_DMA_LKEY	= (1 << 15),
> +	IB_DEVICE_RESERVED		= (1 << 16), /* old SEND_W_INV */
> +	IB_DEVICE_MEM_WINDOW		= (1 << 17),
>  	/*
>  	 * Devices should set IB_DEVICE_UD_IP_SUM if they support
>  	 * insertion of UDP and TCP checksum on outgoing UD IPoIB
> @@ -130,18 +130,18 @@ enum ib_device_cap_flags {
>  	 * incoming messages.  Setting this flag implies that the
>  	 * IPoIB driver may set NETIF_F_IP_CSUM for datagram mode.
>  	 */
> -	IB_DEVICE_UD_IP_CSUM		= (1<<18),
> -	IB_DEVICE_UD_TSO		= (1<<19),
> -	IB_DEVICE_XRC			= (1<<20),
> -	IB_DEVICE_MEM_MGT_EXTENSIONS	= (1<<21),
> -	IB_DEVICE_BLOCK_MULTICAST_LOOPBACK = (1<<22),
> -	IB_DEVICE_MEM_WINDOW_TYPE_2A	= (1<<23),
> -	IB_DEVICE_MEM_WINDOW_TYPE_2B	= (1<<24),
> -	IB_DEVICE_RC_IP_CSUM		= (1<<25),
> -	IB_DEVICE_RAW_IP_CSUM		= (1<<26),
> -	IB_DEVICE_MANAGED_FLOW_STEERING = (1<<29),
> -	IB_DEVICE_SIGNATURE_HANDOVER	= (1<<30),
> -	IB_DEVICE_ON_DEMAND_PAGING	= (1<<31),
> +	IB_DEVICE_UD_IP_CSUM		= (1 << 18),
> +	IB_DEVICE_UD_TSO		= (1 << 19),
> +	IB_DEVICE_XRC			= (1 << 20),
> +	IB_DEVICE_MEM_MGT_EXTENSIONS	= (1 << 21),
> +	IB_DEVICE_BLOCK_MULTICAST_LOOPBACK = (1 << 22),
> +	IB_DEVICE_MEM_WINDOW_TYPE_2A	= (1 << 23),
> +	IB_DEVICE_MEM_WINDOW_TYPE_2B	= (1 << 24),
> +	IB_DEVICE_RC_IP_CSUM		= (1 << 25),
> +	IB_DEVICE_RAW_IP_CSUM		= (1 << 26),
> +	IB_DEVICE_MANAGED_FLOW_STEERING = (1 << 29),
> +	IB_DEVICE_SIGNATURE_HANDOVER	= (1 << 30),
> +	IB_DEVICE_ON_DEMAND_PAGING	= (1 << 31),
>  };
>  
>  enum ib_signature_prot_cap {
> -- 
> 1.7.12.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky Dec. 21, 2015, 6:37 a.m. UTC | #2 
On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@intel.com> wrote:
> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
>> From: Leon Romanovsky <leonro@mellanox.com>
>>
>> Modify enum ib_device_cap_flags such that other patches which add new
>> enum values pass strict checkpatch.pl checks.
>>
....
>> -     IB_DEVICE_RESERVED              = (1<<16), /* old SEND_W_INV */
>> -     IB_DEVICE_MEM_WINDOW            = (1<<17),
>> +     IB_DEVICE_RESIZE_MAX_WR         = (1 << 0),
>
> NIT: Shouldn't we just use the BIT macro?
>
>         IB_DEVICE_RESIZE_MAX_WR         = BIT(0),
You are right and it is a preferred way for me too, however the
downside of such change will be one of two:
1. Change this structure only => we will have style mix of BITs and
shifts in the same file. IMHO it looks awful.
2. Change the whole file => the work with "git blame" will be less
straightforward.

I will do the change across whole file, If Doug accepts such change.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Or Gerlitz Dec. 21, 2015, 6:52 a.m. UTC | #3 
On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <leon@leon.nu> wrote:
> On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@intel.com> wrote:
>> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@mellanox.com>

>>> Modify enum ib_device_cap_flags such that other patches which add new
>>> enum values pass strict checkpatch.pl checks.

>>> -     IB_DEVICE_RESERVED              = (1<<16), /* old SEND_W_INV */
>>> -     IB_DEVICE_MEM_WINDOW            = (1<<17),
>>> +     IB_DEVICE_RESIZE_MAX_WR         = (1 << 0),

> 2. Change the whole file => the work with "git blame" will be less
> straightforward.

Agree.

Leon, I don't think we need to take checkpatch-ing of things to that level.

Indeed, we should make sure that whole new enums and such are done right --
but avoid touching core structs/enums in a manner that disallows
simple git blaming of things, which is very useful for new comers and
old suffers.

For example, the networking community keeps adding IFF_YYY values to
include/linux/netdevice.h :: enum netdev_priv_flags without fixing
checkpatch complaint on missing spaces before/after the << shift sign.

> I will do the change across whole file, If Doug accepts such change.

Please don't... simple git blame is very powerful tool for kernel
developers everyday work.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky Dec. 21, 2015, 7:27 a.m. UTC | #4 
On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <leon@leon.nu> wrote:
>> On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@intel.com> wrote:
>>> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
>>>> From: Leon Romanovsky <leonro@mellanox.com>
>
>>>> Modify enum ib_device_cap_flags such that other patches which add new
>>>> enum values pass strict checkpatch.pl checks.
>
>>>> -     IB_DEVICE_RESERVED              = (1<<16), /* old SEND_W_INV */
>>>> -     IB_DEVICE_MEM_WINDOW            = (1<<17),
>>>> +     IB_DEVICE_RESIZE_MAX_WR         = (1 << 0),
>
>> 2. Change the whole file => the work with "git blame" will be less
>> straightforward.
>
> Agree.
>
> Leon, I don't think we need to take checkpatch-ing of things to that level.
>
> Indeed, we should make sure that whole new enums and such are done right --
> but avoid touching core structs/enums in a manner that disallows
> simple git blaming of things, which is very useful for new comers and
> old suffers.
There are no doubts that standalone fixing checkpatch errors is more
suitable to staging subsystem.
In our case, it is part of coming changes in that structure. such
change serves specific goal to minimize
the possibility of error by seeing clean output from static analyser tool.

For the new comers and old suffers checkpatch tool is extremely useful too.

>
>> I will do the change across whole file, If Doug accepts such change.
>
> Please don't... simple git blame is very powerful tool for kernel
> developers everyday work.
It is an open question what we prefer more: history with chance to
sneak a mistake or less history with less chances to make a mistake.

>
> Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Or Gerlitz Dec. 21, 2015, 7:40 a.m. UTC | #5 
On Mon, Dec 21, 2015 at 9:27 AM, Leon Romanovsky <leon@leon.nu> wrote:
> On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <leon@leon.nu> wrote:
>>> On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@intel.com> wrote:
>>>> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
>>>>> From: Leon Romanovsky <leonro@mellanox.com>
>>
>>>>> Modify enum ib_device_cap_flags such that other patches which add new
>>>>> enum values pass strict checkpatch.pl checks.
>>
>>>>> -     IB_DEVICE_RESERVED              = (1<<16), /* old SEND_W_INV */
>>>>> -     IB_DEVICE_MEM_WINDOW            = (1<<17),
>>>>> +     IB_DEVICE_RESIZE_MAX_WR         = (1 << 0),
>>
>>> 2. Change the whole file => the work with "git blame" will be less
>>> straightforward.
>>
>> Agree.
>>
>> Leon, I don't think we need to take checkpatch-ing of things to that level.
>>
>> Indeed, we should make sure that whole new enums and such are done right --
>> but avoid touching core structs/enums in a manner that disallows
>> simple git blaming of things, which is very useful for new comers and
>> old suffers.

> There are no doubts that standalone fixing checkpatch errors is more
> suitable to staging subsystem.

Agree

> In our case, it is part of coming changes in that structure. such
> change serves specific goal to minimize the possibility of error
> by seeing clean output from static analyser tool.

Disagree.

What future bugs are you envisioning by let this 10y old header file
keep having some checkpatch issues on few of the major enums?!

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky Dec. 21, 2015, 7:53 a.m. UTC | #6 
On Mon, Dec 21, 2015 at 9:40 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Mon, Dec 21, 2015 at 9:27 AM, Leon Romanovsky <leon@leon.nu> wrote:
>> On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>> On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <leon@leon.nu> wrote:
>>>> On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@intel.com> wrote:
>>>>> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
>>>>>> From: Leon Romanovsky <leonro@mellanox.com>
>>>
>>>>>> Modify enum ib_device_cap_flags such that other patches which add new
>>>>>> enum values pass strict checkpatch.pl checks.
>>>
>>>>>> -     IB_DEVICE_RESERVED              = (1<<16), /* old SEND_W_INV */
>>>>>> -     IB_DEVICE_MEM_WINDOW            = (1<<17),
>>>>>> +     IB_DEVICE_RESIZE_MAX_WR         = (1 << 0),
>>>
>>>> 2. Change the whole file => the work with "git blame" will be less
>>>> straightforward.
>>>
>>> Agree.
>>>
>>> Leon, I don't think we need to take checkpatch-ing of things to that level.
>>>
>>> Indeed, we should make sure that whole new enums and such are done right --
>>> but avoid touching core structs/enums in a manner that disallows
>>> simple git blaming of things, which is very useful for new comers and
>>> old suffers.
>
>> There are no doubts that standalone fixing checkpatch errors is more
>> suitable to staging subsystem.
>
> Agree
>
>> In our case, it is part of coming changes in that structure. such
>> change serves specific goal to minimize the possibility of error
>> by seeing clean output from static analyser tool.
>
> Disagree.
>
> What future bugs are you envisioning by let this 10y old header file
> keep having some checkpatch issues on few of the major enums?!
If I knew the future, I would be able to answer.

I think that you expressed your opinion very clearly, let's wait for
Doug's response on such changes.

>
> Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Christoph Hellwig Dec. 21, 2015, 8:03 a.m. UTC | #7 
On Mon, Dec 21, 2015 at 08:37:26AM +0200, Leon Romanovsky wrote:
> You are right and it is a preferred way for me too, however the
> downside of such change will be one of two:
> 1. Change this structure only => we will have style mix of BITs and
> shifts in the same file. IMHO it looks awful.
> 2. Change the whole file => the work with "git blame" will be less
> straightforward.

Honestly, the BIT macros are horribly, and anyone who thinks it's useful
really should read a book on computer architectured and one on C.

Also the capabilities are used by userspace, so they will need to move
to a uapi heder sooner or later, where this stupid macro isn't even
available.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ira Weiny Dec. 21, 2015, 4:36 p.m. UTC | #8 
On Mon, Dec 21, 2015 at 12:03:46AM -0800, Christoph Hellwig wrote:
> On Mon, Dec 21, 2015 at 08:37:26AM +0200, Leon Romanovsky wrote:
> > You are right and it is a preferred way for me too, however the
> > downside of such change will be one of two:
> > 1. Change this structure only => we will have style mix of BITs and
> > shifts in the same file. IMHO it looks awful.
> > 2. Change the whole file => the work with "git blame" will be less
> > straightforward.
> 
> Honestly, the BIT macros are horribly, and anyone who thinks it's useful
> really should read a book on computer architectured and one on C.

It would be nice if we were not having to do this for staging then.  Also
perhaps it should be removed from checkpatch --strict?

I'm not a big fan of everything checkpatch does, this being one of them, but
Leon was trying to do the right thing here.

Where are the guidelines for when one can ignore checkpatch and when they can
not?  It would be nice to know when we can "be developers" vs "being robots to
some tool".

I await Dougs guidance.

Ira

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Christoph Hellwig Dec. 21, 2015, 8:20 p.m. UTC | #9 
On Mon, Dec 21, 2015 at 11:36:03AM -0500, ira.weiny wrote:
> It would be nice if we were not having to do this for staging then.  Also
> perhaps it should be removed from checkpatch --strict?

Don't use checkpatch --strict ever.  It's full of weird items that
defintively don't apply to the majority of the kernel code base.

> Where are the guidelines for when one can ignore checkpatch and when they can
> not?  It would be nice to know when we can "be developers" vs "being robots to
> some tool".

I think checkpatch is generally useful, and the errors without
--strict are something we I haven't found any false positives.

The warnings are about 90% useful but something are just weird.  For
--strict all bets are off.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky Dec. 23, 2015, 10:23 a.m. UTC | #10 
On Wed, Dec 23, 2015 at 12:00:41PM +0200, Or Gerlitz wrote:
> On 12/21/2015 9:53 AM, Leon Romanovsky wrote:
> >On Mon, Dec 21, 2015 at 9:40 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> >>On Mon, Dec 21, 2015 at 9:27 AM, Leon Romanovsky <leon@leon.nu> wrote:
> >>>On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> >>>>On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <leon@leon.nu> wrote:
> >>>>>On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@intel.com> wrote:
> >>>>>>On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote:
> >>>>>>>From: Leon Romanovsky <leonro@mellanox.com>
> >>>>>>>Modify enum ib_device_cap_flags such that other patches which add new
> >>>>>>>enum values pass strict checkpatch.pl checks.
> >>>>>>>-     IB_DEVICE_RESERVED              = (1<<16), /* old SEND_W_INV */
> >>>>>>>-     IB_DEVICE_MEM_WINDOW            = (1<<17),
> >>>>>>>+     IB_DEVICE_RESIZE_MAX_WR         = (1 << 0),
> >>>>>2. Change the whole file => the work with "git blame" will be less
> >>>>>straightforward.
> >>>>Agree.
> >>>>
> >>>>Leon, I don't think we need to take checkpatch-ing of things to that level.
> >>>>
> >>>>Indeed, we should make sure that whole new enums and such are done right --
> >>>>but avoid touching core structs/enums in a manner that disallows
> >>>>simple git blaming of things, which is very useful for new comers and
> >>>>old suffers.
> >>>There are no doubts that standalone fixing checkpatch errors is more
> >>>suitable to staging subsystem.
> >>Agree
> >>
> >>>In our case, it is part of coming changes in that structure. such
> >>>change serves specific goal to minimize the possibility of error
> >>>by seeing clean output from static analyser tool.
> >>Disagree.
> >>
> >>What future bugs are you envisioning by let this 10y old header file
> >>keep having some checkpatch issues on few of the major enums?!
> >If I knew the future, I would be able to answer.
> 
> Use your common-sense and experience and maybe even some credit that you can
> give to the 10x larger and super active networking community, you should be
> able to provide some answer if you believe this is the  right way to go.
My common-sense and experience suggest me that the proposed patch
doesn't worth investing so much time. I'll drop it in the next version
of this patchset.

> 
> >I think that you expressed your opinion very clearly, let's wait for Doug's response on such changes.
> >
> 
> I expressed my opinion and I ask you Qs. Christoph also made more comments,
> if you think this is the way to go, respond.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Doug Ledford Dec. 24, 2015, 3:31 a.m. UTC | #11 
On 12/21/2015 11:36 AM, ira.weiny wrote:
> On Mon, Dec 21, 2015 at 12:03:46AM -0800, Christoph Hellwig wrote:
>> On Mon, Dec 21, 2015 at 08:37:26AM +0200, Leon Romanovsky wrote:
>>> You are right and it is a preferred way for me too, however the
>>> downside of such change will be one of two:
>>> 1. Change this structure only => we will have style mix of BITs and
>>> shifts in the same file. IMHO it looks awful.
>>> 2. Change the whole file => the work with "git blame" will be less
>>> straightforward.
>>
>> Honestly, the BIT macros are horribly, and anyone who thinks it's useful
>> really should read a book on computer architectured and one on C.
> 
> It would be nice if we were not having to do this for staging then.  Also
> perhaps it should be removed from checkpatch --strict?
>
> I'm not a big fan of everything checkpatch does, this being one of them, but
> Leon was trying to do the right thing here.
> 
> Where are the guidelines for when one can ignore checkpatch and when they can
> not?  It would be nice to know when we can "be developers" vs "being robots to
> some tool".
> 
> I await Dougs guidance.

Checkpatch?  What is this thing you speak of?  ;-)

I use it, but not even all the time, and certainly not religiously.  And
I've never used strict mode.  Even in non-strict mode it flags stuff
that I ignore.

As for the BIT macros, I haven't looked at their implementation.  If
Christoph thinks they are crap, then absent my own opinion on the issue,
which I'm not inclined to go form at 10:30pm on Dec. 23rd, I'll trust
his judgment ;-)
diff mbox

Patch

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 9a68a19..bcf40ad 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -105,24 +105,24 @@  enum rdma_link_layer {
 };
 
 enum ib_device_cap_flags {
-	IB_DEVICE_RESIZE_MAX_WR		= 1,
-	IB_DEVICE_BAD_PKEY_CNTR		= (1<<1),
-	IB_DEVICE_BAD_QKEY_CNTR		= (1<<2),
-	IB_DEVICE_RAW_MULTI		= (1<<3),
-	IB_DEVICE_AUTO_PATH_MIG		= (1<<4),
-	IB_DEVICE_CHANGE_PHY_PORT	= (1<<5),
-	IB_DEVICE_UD_AV_PORT_ENFORCE	= (1<<6),
-	IB_DEVICE_CURR_QP_STATE_MOD	= (1<<7),
-	IB_DEVICE_SHUTDOWN_PORT		= (1<<8),
-	IB_DEVICE_INIT_TYPE		= (1<<9),
-	IB_DEVICE_PORT_ACTIVE_EVENT	= (1<<10),
-	IB_DEVICE_SYS_IMAGE_GUID	= (1<<11),
-	IB_DEVICE_RC_RNR_NAK_GEN	= (1<<12),
-	IB_DEVICE_SRQ_RESIZE		= (1<<13),
-	IB_DEVICE_N_NOTIFY_CQ		= (1<<14),
-	IB_DEVICE_LOCAL_DMA_LKEY	= (1<<15),
-	IB_DEVICE_RESERVED		= (1<<16), /* old SEND_W_INV */
-	IB_DEVICE_MEM_WINDOW		= (1<<17),
+	IB_DEVICE_RESIZE_MAX_WR		= (1 << 0),
+	IB_DEVICE_BAD_PKEY_CNTR		= (1 << 1),
+	IB_DEVICE_BAD_QKEY_CNTR		= (1 << 2),
+	IB_DEVICE_RAW_MULTI		= (1 << 3),
+	IB_DEVICE_AUTO_PATH_MIG		= (1 << 4),
+	IB_DEVICE_CHANGE_PHY_PORT	= (1 << 5),
+	IB_DEVICE_UD_AV_PORT_ENFORCE	= (1 << 6),
+	IB_DEVICE_CURR_QP_STATE_MOD	= (1 << 7),
+	IB_DEVICE_SHUTDOWN_PORT		= (1 << 8),
+	IB_DEVICE_INIT_TYPE		= (1 << 9),
+	IB_DEVICE_PORT_ACTIVE_EVENT	= (1 << 10),
+	IB_DEVICE_SYS_IMAGE_GUID	= (1 << 11),
+	IB_DEVICE_RC_RNR_NAK_GEN	= (1 << 12),
+	IB_DEVICE_SRQ_RESIZE		= (1 << 13),
+	IB_DEVICE_N_NOTIFY_CQ		= (1 << 14),
+	IB_DEVICE_LOCAL_DMA_LKEY	= (1 << 15),
+	IB_DEVICE_RESERVED		= (1 << 16), /* old SEND_W_INV */
+	IB_DEVICE_MEM_WINDOW		= (1 << 17),
 	/*
 	 * Devices should set IB_DEVICE_UD_IP_SUM if they support
 	 * insertion of UDP and TCP checksum on outgoing UD IPoIB
@@ -130,18 +130,18 @@  enum ib_device_cap_flags {
 	 * incoming messages.  Setting this flag implies that the
 	 * IPoIB driver may set NETIF_F_IP_CSUM for datagram mode.
 	 */
-	IB_DEVICE_UD_IP_CSUM		= (1<<18),
-	IB_DEVICE_UD_TSO		= (1<<19),
-	IB_DEVICE_XRC			= (1<<20),
-	IB_DEVICE_MEM_MGT_EXTENSIONS	= (1<<21),
-	IB_DEVICE_BLOCK_MULTICAST_LOOPBACK = (1<<22),
-	IB_DEVICE_MEM_WINDOW_TYPE_2A	= (1<<23),
-	IB_DEVICE_MEM_WINDOW_TYPE_2B	= (1<<24),
-	IB_DEVICE_RC_IP_CSUM		= (1<<25),
-	IB_DEVICE_RAW_IP_CSUM		= (1<<26),
-	IB_DEVICE_MANAGED_FLOW_STEERING = (1<<29),
-	IB_DEVICE_SIGNATURE_HANDOVER	= (1<<30),
-	IB_DEVICE_ON_DEMAND_PAGING	= (1<<31),
+	IB_DEVICE_UD_IP_CSUM		= (1 << 18),
+	IB_DEVICE_UD_TSO		= (1 << 19),
+	IB_DEVICE_XRC			= (1 << 20),
+	IB_DEVICE_MEM_MGT_EXTENSIONS	= (1 << 21),
+	IB_DEVICE_BLOCK_MULTICAST_LOOPBACK = (1 << 22),
+	IB_DEVICE_MEM_WINDOW_TYPE_2A	= (1 << 23),
+	IB_DEVICE_MEM_WINDOW_TYPE_2B	= (1 << 24),
+	IB_DEVICE_RC_IP_CSUM		= (1 << 25),
+	IB_DEVICE_RAW_IP_CSUM		= (1 << 26),
+	IB_DEVICE_MANAGED_FLOW_STEERING = (1 << 29),
+	IB_DEVICE_SIGNATURE_HANDOVER	= (1 << 30),
+	IB_DEVICE_ON_DEMAND_PAGING	= (1 << 31),
 };
 
 enum ib_signature_prot_cap {