Message-Id: <DB71A450-EF1D-479F-9111-A36FF8EA89B2@holtmann.org>
Date:	Wed, 6 Aug 2014 13:56:33 -0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Pavel Machek <pavel@....cz>,
	Miguel Oliveira <cmroliv@...il.com>, gulsah.1004@...il.com,
	peter.p.waskiewicz.jr@...el.com, kristina.martsenko@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range() instead of msleep()

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.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists