On Tue, 2019-05-21 at 21:47 -0700, Paul Walmsley wrote: > On Tue, 21 May 2019, Andrew Morton wrote: > > > On Sun, 19 May 2019 11:24:22 -0700 (PDT) Paul Walmsley > > <paul.walms...@sifive.com> wrote: > > > > > On Sat, 18 May 2019, Joe Perches wrote: > > > > > > > On Sat, 2019-05-18 at 14:00 -0700, Paul Walmsley wrote: > > > > > The RISC-V architecture has a register named the "Supervisor Exception > > > > > Program Counter", or "sepc". This abbreviation triggers > > > > > checkpatch.pl's misspelling detector, resulting in noise in the > > > > > checkpatch output. The risk that this noise could cause more useful > > > > > warnings to be missed seems to outweigh the harm of an occasional > > > > > misspelling of "spec". Thus drop the "sepc" entry from the > > > > > misspelling list. > > > > > > > > I would agree if you first fixed the existing sepc/spec > > > > and sepcific/specific typos. > > > > > > > > arch/powerpc/kvm/book3s_xics.c: * a pending interrupt, this is a SW > > > > error and PAPR sepcifies > > > > arch/unicore32/include/mach/regs-gpio.h: * Sepcial Voltage Detect Reg > > > > GPIO_GPIR. > > > > drivers/scsi/lpfc/lpfc_init.c: /* Stop any OneConnect device > > > > sepcific driver timers */ > > > > drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c:* OverView: Read > > > > "sepcific bits" from BB register > > > > drivers/net/wireless/realtek/rtlwifi/wifi.h:/* Ref: 802.11i sepc D10.0 > > > > 7.3.2.25.1 > > > > > > Your agreement shouldn't be needed for the patch I sent. > > > > I always find Joe's input to be very useful. > > > > Here: > > > > From: Andrew Morton <a...@linux-foundation.org> > > Subject: scripts-spellingtxt-drop-sepc-from-the-misspelling-list-fix > > > > fix existing "sepc" instances, per Joe > > > > Cc: Joe Perches <j...@perches.com> > > Cc: Paul Walmsley <paul.walms...@sifive.com> > > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > > Thanks Andrew. Sorry that you had to do it. > > Reviewed-by: Paul Walmsley <paul.walms...@sifive.com> > > What troubled me about Joe's message is that it seems like poor kernel > developer precedent to block a fix for static analysis false positives to > fix comment spelling errors -- particularly considering that four out of > five of them were unrelated to the actual patch in question. While > comment spelling fixes are worthwhile, I think we should make sure that > the "tail doesn't wag the dog" by prioritizing code fixes first.
I don't believe there is any tail wagging occurring here. There is no code 'fix' in the original proposed patch. It is, as described, effectively a subsystem specific static analysis false positive avoidance patch. And the static analysis tool's false positive report is not active by default. Any scripts/spelling.txt change like a sepc removal could be overridden by using checkpatch's --codespell option. btw: I don't generally add acked-by or reviewed-by to patches as I rather agree with Ted's position on these headers. https://lore.kernel.org/lkml/20190521171618.gd2...@mit.edu/ > I will try to do better next time, Thanks.