On Wed, Aug 06, 2014 at 11:30:55PM +0200, Pavel Machek wrote: > On Wed 2014-08-06 13:56:33, Marcel Holtmann wrote: > > Hi Greg, > > > > >>>>>>> Creating this patch for the Eudyptula Challenge. > > >>>>>>> Replaced msleep() for a delay < 20ms with a > > >>>>>>> usleep_range() between 10000us and 15000us. Also > > >>>>>>> inserted a blank line after adeclaration. > > >>>>>> > > >>>>>> So you are changing timings without testing. Plus, > > >>>>>> burning CPU power instead of sleeping. > > >>>>>> > > >>>>>> Seems you'll need another patch for the challenge :-). > > >>>>> > > >>>>> I actually wonder if anybody is seriously working on this > > >>>>> driver. My concern with the staging drivers has always > > >>>>> been that we are quick with merging them when the work on > > >>>>> getting them into upstream shape is actually hard. > > >>>>> However reality is once they are in staging nobody is > > >>>>> doing the work to clean them up and fix the issues. > > >>>> > > >>>> There is active work on merging n900 changes. > > >>> > > >>> Really? Where? > > >>> > > >> > > >> You can look at elinux wiki where is table how process is going: > > >> http://elinux.org/N900 > > >> > > >> Also look at planed future list and its progress: > > >> http://elinux.org/N900/Changelog > > >> > > >> You can see that drivers are including step by step. > > > > > > I'm not going to dig through random web pages, sorry. If patches aren't > > > sent to me for a driver, I consider it dead, that's only fair for me > > > given my workload, don't you think? > > > > > >>>> And no, it does not progress as quickly as I'd like, but > > >>>> we'll get there. It is also requirement for n900 FM radio > > >>>> receiving... > > >>>> > > >>>>> Greg, instead of wasting our time with this, can we just > > >>>>> remove this driver from staging. > > >>>> > > >>>> Please don't. > > >>> > > >>> As there has not been any real work on it since it has been > > >>> merged, I don't see why I shouldn't remove it. If you do get > > >>> some work done on it, you can always revert the removal and > > >>> continue on. But the existance of code in staging that is > > >>> not progressing forward at all is something that I don't like > > >>> at all, and will be doing a large sweep of soon to remove. > > >>> > > >>> thanks, > > >>> > > >>> greg k-h > > >> > > >> Just look how much time took to include my patch for radio- > > >> bcm2048 (fm radio part of this chip) which fixing wrong overflow > > >> check. I sent it at the end of December and... yes it is still > > >> not included in linus tree. Now it is somethere in media tree and > > >> probably will be pulled in next merge window. > > >> > > >> This means that it takes about half of year to include patches > > >> for these drivers. > > > > > > Just because the media drivers take a long time to get fixes merged, > > > don't use that as an excuse to not fix up the staging drivers. > > > > > > In fact, it sounds like you have lots of time while that patch is > > > getting merged, why not work on fixing up the staging driver? :) > > > > and 2 month later, we still have nothing accomplished with this driver. > > > > So this driver is 6 month in staging and not a single commit to address > > anything in the TODO file. I only see pointless coding style change. > > > > There is a reason why I dislike staging drivers. And this is exactly it. It > > gets treated as dumping ground. So can we please remove this driver now. > > Maybe someone finally wakes up and does their promised job. > > > > Yeah, so I clearly make a mistake of cleaning the driver up _before_ > merging it into staging.
No, the mistake was that you didn't ever follow it up with any real work, not that it was "cleaned up" at all. > And yes, I'm currently trying to get 3.16 working in the qemu, which > is prerequisite for any useful n900 work. So I guess I'll queue up a patch to delete this for 3.17-rc2. Pavel, if you get the device working properly, we can easily revert the deletion and you can send follow-on patches to fix things up properly. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
