On Tue, Feb 09, 2021 at 02:39:41PM +0100, Hans Verkuil wrote: > On 09/02/2021 14:02, Greg Kroah-Hartman wrote: > > On Tue, Feb 09, 2021 at 01:45:35PM +0100, Dafna Hirschfeld wrote: > >> > >> > >> Am 08.02.21 um 21:46 schrieb Hans Verkuil: > >>> On 08/02/2021 18:57, Sasha Levin wrote: > >>>> From: Dafna Hirschfeld <dafna.hirschf...@collabora.com> > >>>> > >>>> [ Upstream commit 31f190e0ccac8b75d33fdc95a797c526cf9b149e ] > >>>> > >>>> Each entry in the array is a 20 bits value composed of 16 bits unsigned > >>>> integer and 4 bits fractional part. So the type should change to __u32. > >>>> In addition add a documentation of how the measurements are done. > >>> > >>> Dafna, Helen, does it make sense at all to backport these three patches to > >>> when rkisp1 was a staging driver? > >>> > >>> I would be inclined not to backport this. > >> > >> I also don't think it makes sense since this changes the uapi and it is > >> not really a bug fix. > > > > Why was it ok to change the uapi in a newer kernel and not an older one? > > In the older kernels this was a staging driver and the driver API was not > public. > It's debatable whether there is any benefit from trying to backport patches > like > this to a staging driver like that. > > Also, these backports are incomplete, there are other patches that would need > to > be applied to make this work. Applying just these three patches without the > other > three (commits 66d81de7ea9d, fc672d806bd7 and ef357e02b6c4) makes it very > messy > indeed. > > I'd just leave the staging driver in older kernels as-is. Certainly don't just > apply these three patches without the other three commits, that would make it > even worse.
Fair enough, Sasha, can you drop these? thanks, greg k-h _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
