On Wed, Feb 12, 2014 at 07:43:42AM +0100, Dmitry Torokhov wrote: > On Tue, Feb 11, 2014 at 08:54:53PM -0800, Courtney Cavin wrote: > > On Wed, Feb 12, 2014 at 04:17:59AM +0100, Christopher Heiny wrote: > > > On 02/11/2014 06:49 PM, Courtney Cavin wrote: > > > > On Wed, Feb 12, 2014 at 03:17:57AM +0100, Christopher Heiny wrote: > > > >> On 02/11/2014 05:59 PM, Courtney Cavin wrote: > > > >>> On Wed, Feb 12, 2014 at 12:13:30AM +0100, Christopher Heiny wrote: > > > >>>> For rmi_sensor and rmi_function device_types, use put_device() and > > > >>>> the assocated device_type.release() function to clean up related > > > >>>> structures and storage in the correct and safe order. > > > >>>> > > > >>>> Signed-off-by: Christopher Heiny <cheiny@xxxxxxxxxxxxx> > > > >>>> Cc: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > > >>>> Cc: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> > > > >>>> Cc: Linux Walleij <linus.walleij@xxxxxxxxxx> > > > >>>> Cc: David Herrmann <dh.herrmann@xxxxxxxxx> > > > >>>> Cc: Jiri Kosina <jkosina@xxxxxxx> > > > >>>> Cc: Courtney Cavin <courtney.cavin@xxxxxxxxxxxxxx> > > > >>> > > > >>> I'm not a huge fan of you taking my patches, re-formatting them and > > > >>> sending them as your own. More out of principle then actually caring > > > >>> about ownership. You at least cc'd me on this one.... > > > >> > > > >> Sorry - no slight was intended at all! I wasn't sure what the protocol > > > >> was for picking up an idea from someone else's patch and building on > > > >> that idea, so I just went with the CC. I definitely prefer to attribute > > > >> sources correctly - if you could clarify what should be done (beyond the > > > >> CC) to acknowledge the author of the original patch, I'd appreciate it. > > > > > > > > Sure. In short, follow Documentation/SubmittingPatches , esp. section > > > > 12) Sign your work. > > > > > > > > Generally the patch should read something like the following: > > > > > > > > From: Original Author <original.author@xxxxxxxxxxx> > > > > > > > > *BLURB* > > > > > > > > Signed-off-by: Original Author <original.author@xxxxxxxxxxx> > > > > [additional.author@xxxxxxxxxxx: changed x and y] > > > > Signed-off-by: Additional Author <additional.author@xxxxxxxxxxx> > > > > > > > > Assuming the original author actually signed-off the patch in the first > > > > place, of course. The square bracket part is optional, but can be > > > > helpful for reviewers. > > > > > > > > I'm somewhat surprised that you are not aware of this procedure, as this > > > > is how Dmitry has replied to some of your patches in the past.' > > > > > > Thanks very much. > > > > > > I was actually aware of that, but thought the work was sufficiently > > > different from your original patch that applying your Signed-off-by: to > > > it wouldn't be appropriate (I dislike being signed off on things I don't > > > necessarily agree with as much as lack of attribution). I'll be less > > > paranoid about that in the future. > > > > I don't see how they were different enough, when clearly these two > > patches attempt to fix the same bugs, using the same methods with > > slightly modified flow. Perhaps the patches may be small enough > > to be interpreted either way, but at the very least reported-by (since > > this is a bug-fix) or suggested-by is more appropriate than Cc. This is > > a public list, so I'm sure someone will tell you when you are wrong, if > > nothing else. > > > > Along the same topic, I guess I should also mention that it is typically > > frowned upon to takeover someone else's patches without giving them > > due-time to fix any outstanding review comments. > > > > In both of these cases, you neither asked for me to submit the patches > > separately, outside of my DT-series, nor to make any specific changes. > > I was under the impression that you were still participating in the > > discussion for that series. > > > > While it is apparent that we have differing views on how this particular > > driver development should proceed, and we should definitely discuss > > them, please do not think that I'm not willing to apply my patches > > individually to what's in tree now. > > > > My main concern here is that I cannot actually properly test this driver > > without DT, non-gpio irq, and regulator support. Likewise, pre-3.7 is > > ancient, and would require back-porting hundreds of changes. > > I can rebase to something more recent; I just did not want to cause > additional work for Chris. Once he finishes pushing his code I was going > to rebase anyway. That would be great! Thanks. -Courtney -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
