linux-kernel - Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140807002532.GB23406@kroah.com>
Date:	Wed, 6 Aug 2014 17:25:32 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Pavel Machek <pavel@....cz>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	Pali Rohár <pali.rohar@...il.com>,
	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()

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 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/