From: Greg KH <gregkh@linuxfoundation.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Marcel Holtmann" <marcel@holtmann.org>,
"Pali Rohár" <pali.rohar@gmail.com>,
"Miguel Oliveira" <cmroliv@gmail.com>,
gulsah.1004@gmail.com, peter.p.waskiewicz.jr@intel.com,
kristina.martsenko@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range() instead of msleep()
Date: Wed, 6 Aug 2014 17:25:32 -0700 [thread overview]
Message-ID: <20140807002532.GB23406@kroah.com> (raw)
In-Reply-To: <20140806213055.GA26046@amd.pavel.ucw.cz>
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
next prev parent reply other threads:[~2014-08-07 0:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 10:27 [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range() instead of msleep() Miguel Oliveira
2014-05-30 11:34 ` Pavel Machek
2014-05-30 11:52 ` Marcel Holtmann
2014-05-30 12:30 ` Pavel Machek
2014-05-30 15:59 ` Greg KH
2014-05-30 16:15 ` Pali Rohár
2014-05-30 16:36 ` Greg KH
2014-08-06 20:56 ` Marcel Holtmann
2014-08-06 21:30 ` Pavel Machek
2014-08-07 0:25 ` Greg KH [this message]
2014-08-07 8:13 ` [PATCH] staging: nokia_h4: use more consistent name for intermediate object Pavel Machek
2014-08-07 20:24 ` Greg KH
2014-08-09 15:48 ` Pavel Machek
2014-08-10 7:29 ` [PATCH 1/3] staging: nokia_h4: switch to right types and use bdaddr_t Pavel Machek
2014-08-10 7:31 ` [PATCH 2/3] staging: nokia_h4: avoid __uX types Pavel Machek
2014-08-10 7:33 ` [PATCH 3/3] staging: use inlines where it makes sense Pavel Machek
2014-08-10 7:34 ` [PATCH] bluetooth: avoid using __uX types Pavel Machek
2014-08-07 9:07 ` [PATCH] staging: nokia_h4: merge firmware together so that we can reduce ammount of exports Pavel Machek
2014-08-07 9:36 ` Pavel Machek
2014-08-07 14:48 ` Marcel Holtmann
2014-08-09 15:47 ` Pavel Machek
2014-05-30 12:15 ` [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range() instead of msleep() Miguel Oliveira
2014-05-30 12:35 ` Pavel Machek
2014-05-30 12:58 ` Miguel Oliveira
2014-05-30 16:01 ` Greg KH
2014-05-30 16:05 ` Miguel Oliveira
2014-05-30 16:13 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140807002532.GB23406@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=cmroliv@gmail.com \
--cc=gulsah.1004@gmail.com \
--cc=kristina.martsenko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=pali.rohar@gmail.com \
--cc=pavel@ucw.cz \
--cc=peter.p.waskiewicz.jr@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox