On Mon, Dec 21, 2015 at 9:40 AM, Or Gerlitz <gerlitz.or@xxxxxxxxx> wrote: > On Mon, Dec 21, 2015 at 9:27 AM, Leon Romanovsky <leon@xxxxxxx> wrote: >> On Mon, Dec 21, 2015 at 8:52 AM, Or Gerlitz <gerlitz.or@xxxxxxxxx> wrote: >>> On Mon, Dec 21, 2015 at 8:37 AM, Leon Romanovsky <leon@xxxxxxx> wrote: >>>> On Mon, Dec 21, 2015 at 8:22 AM, ira.weiny <ira.weiny@xxxxxxxxx> wrote: >>>>> On Sun, Dec 20, 2015 at 12:16:09PM +0200, Leon Romanovsky wrote: >>>>>> From: Leon Romanovsky <leonro@xxxxxxxxxxxx> >>> >>>>>> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
