On Fri, Feb 24, 2023 at 11:48:02AM -0600, Daniel Kaehn wrote: > On Fri, Feb 24, 2023 at 10:43 AM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > On Thu, Feb 23, 2023 at 03:31:44PM -0600, Danny Kaehn wrote: > > > This patchset allows USB-HID devices to have DeviceTree bindings through sharing > > > the USB fwnode with the HID driver, and adds such a binding and driver > > > implementation for the CP2112 USB to SMBus Bridge (which necessitated the > > > USB-HID change). This change allows a CP2112 permanently attached in hardware to > > > be described in DT and interoperate with other drivers. > > > > It's your responsibility to carry the tags you have got in the previous rounds > > of the review. Please, be respectful to the reviewers who spent a lot of time > > on yours, in particular, code. Otherwise why to bother with it (upstreaming) > > at all? > Hello Andy, > > My sincerest apologies on this! I wasn't actually aware that this is > something I could do / am responsible for doing. No disrespect is > intended, though I see how this would be frustrating for reviewers (I > previously thought that maintainers used some sort of automated tool > to keep track of who approved/acked what in previous versions, but > didn't really know how that would work). It's works only in the case if you have no more comments to address. Indeed, `b4` tool may harvest tags from emails. However, if you by your own initiative send a new version, to address or change something, you need to take into account what was done in the previous rounds of review. If you consider that tag can't be applied — too many changes that doesn't match the code to the previous version(s), — you should express why in the cover letter. > If I'm understanding correctly, this means that whenever someone > responds to my patch with a "Reviewed-by", etc.. I should be adding > that tag to the end of the commit message of that patch if a future > revision is needed? Correct and you may use `b4` tool yourself to simplify that. It does not require anything special (permissions, status, access, etc). > I assume this only applies on future revisions > where patches other than the one initially reviewed are changed, and > that any tags I take with should be dropped if that patch is changed? Depends on how big they are. In most cases the changes are not so drastically big, so tags survive them. > Apologies about these questions - - I looked for guidance on this in > the various "submitting patches to the kernel" guides out there, and > wasn't able to find much. Understood. Now we will wait for v8 where you fix the mistakes. Thank you for your patience and contribution! -- With Best Regards, Andy Shevchenko
