On 1/16/2023 1:02 AM, Dan Carpenter wrote:
On Sat, Jan 14, 2023 at 02:49:07PM -0800, Doug Brown wrote:
Hi Dan,
On 1/14/2023 12:01 AM, Dan Carpenter wrote:
Hi Doug,
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Doug-Brown/mmc-sdhci-pxav2-add-initial-support-for-PXA168-V1-controller/20230112-102921
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20230112022416.8474-6-doug%40schmorgal.com
patch subject: [PATCH v4 5/8] mmc: sdhci-pxav2: add optional core clock
config: riscv-randconfig-m041-20230113
compiler: riscv64-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@xxxxxxxxx>
| Reported-by: Dan Carpenter <error27@xxxxxxxxx>
smatch warnings:
drivers/mmc/host/sdhci-pxav2.c:220 sdhci_pxav2_probe() warn: missing error code 'ret'
Thanks for passing this on. I definitely forgot an assignment to ret.
Since this is correcting an error in my patch that hasn't been accepted
yet, is it safe to assume I should omit those Reported-by tags from the
next version of my patch, since they don't apply to the patch itself?
These emails are from the kbuild team and not from me. I just look them
over and hit the forward button. I'm sure it helps the kbuild team in
their marketing when people use the tags... Right now I'm applying to
jobs outside the Linux community so the tags give me a measurable thing
to say I've helped fix thousands of bugs or whatever...
I've always argued that there should be a different Fixes-from: tag for
people who find bugs during review (as opposed to just complaining about
white space which is its own reward and I do that for free). So far I
haven't convinced anyone on this though.
Anyway, there isn't a policy one way or the other. Some people add
them and some don't. Some people add them below the --- cut off line,
but I don't know if that's deliberate or what the story is there. That
seems like it might be a good compromise.
Thanks for all the added context. I knew you had forwarded it from the
kbuild team but I wasn't sure who to ask for clarification. Your idea
for a future Fixes-from: tag for this type of thing makes perfect sense.
For now, it seems that if the git log might be used for obtaining
metrics, I should just go ahead and put the Reported-by: tags in. I
really appreciate that you took the time to explain this to me.
