Re: [PATCH v7 0/3] Firmware Support for USB-HID Devices and CP2112

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux