On 15 March 2017 at 10:36, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > On Wed, Mar 15, 2017 at 10:06:11AM +0000, Dave Stevenson wrote: >> On 15 March 2017 at 05:08, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Tue, Mar 14, 2017 at 03:32:43PM +0000, Dave Stevenson wrote: >> >> NACK. >> >> Phil asked for a couple of changes, although functionally identical. >> >> I'll send a patch when I get a chance. >> > >> > What do you mean, "when I get a chance"? What's wrong with this one? >> >> I was intending on doing it today. >> Michael had noticed a variant of this patch in the downstream kernel >> and asked me if I was intending to submit upstream, in particular >> asking for it to come from raspberrypi becasue it was an API subtlety. > > This description is too vague... > > Your previous email was like "This patch is correct but there is an > unspecified problem that I'm going to fix at an unspecified time." and > now you're like "If you guys like applying patches with problems that's > fine with me but there is an unspecified problem with this one." I > guess we'll wait until later today to see what the issue is. :P OK, part of this is me being annoyed at Michael for asking for assistance and then jumping the gun sending this upstream. Full description: mmal_vchiq is reimplementing parts of the userside MMAL library in kernel space. The expected behaviour of port_parameter_get is that it takes the size of storage for the parameter value, and returns the amount actually used. If the storage is too small, it returns error and the size required. Before this patch it wasn't updating size on success and was returning required size+8 on error. Double whammy. With this patch it is still not updating size on success, but is returning the required size correctly on error. The full fix for both paths obsoletes this patch, and came out of Michael asking for me to get the change reviewed internally. You've got a reason. It's GPLv2 licenced code so I have no control over what happens to it. Everywhere I have worked, when a patch has issues it is better to "-1" to stop/delay the merge even (or particularly) on your own patches, but this is your playground so your rules. Anyway, I'll go back to working with the downstream tree (pull request for the full fix there) and stop bothering you. Dave _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
