ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better?
Date: Wed, 5 Sep 2018 16:55:28 +0300	[thread overview]
Message-ID: <20180905135528.ase6evcv7rlwufyr@mwanda> (raw)
In-Reply-To: <s5hbm9ccbie.wl-tiwai@suse.de>

On Wed, Sep 05, 2018 at 03:35:53PM +0200, Takashi Iwai wrote:
> The staging driver is a wonderful process to promote the downstream
> code to the upstream, but I have doubt whether it's working really as
> expected for now.
> 
> - Often the drivers live forever in staging although they should have
>   been moved to the upper, properly maintained, subsystems.

The only one that comes to mind is comedi.  I think those guys know that
everyone is fine with them moving the code.

Do you have another example?

> 
> - Code changes in staging are mostly only scratching surfaces, minor
>   code style cleanups, etc, what checkpatch suggests.

That's probably true for the wireless drivers because converting them
to use mac80211 is complicated.  The other drivers seem to be doing
better.

> 
> - There are little communications with the corresponding subsystem;
>   already a few times I was surprised by casually finding a staging
>   driver code by grepping for preparing API changes.

Which ones are you interested in?  I'd always prefer to hand off staging
drivers to an existing subsystem but it's not always clear who that
should be.

regards,
dan carpenter

  reply	other threads:[~2018-09-05 13:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 13:35 Takashi Iwai
2018-09-05 13:55 ` Dan Carpenter [this message]
2018-09-05 14:03   ` Takashi Iwai
2018-09-05 14:20     ` Greg KH
2018-09-05 14:41       ` Takashi Iwai
2018-09-05 14:59         ` Shuah Khan
2018-09-05 14:51       ` Andrew Lunn
2018-09-05 14:59       ` Joe Perches
2018-09-05 14:08   ` Sean Paul
2018-09-05 14:22     ` Greg KH
2018-09-05 14:29       ` Sean Paul
2018-09-05 15:35         ` Daniel Vetter
2018-09-05 16:21 ` James Bottomley
2018-09-05 16:35   ` Daniel Vetter
2018-09-07 19:44 ` Mauro Carvalho Chehab
2018-09-08  8:45   ` Jonathan Cameron
2018-09-10 18:49     ` Takashi Iwai
2018-09-10 18:52   ` Takashi Iwai
2018-09-10 18:58     ` Laurent Pinchart
2018-09-10 19:22       ` Tim.Bird
2018-09-10 20:51         ` Laurent Pinchart
2018-09-11  0:30         ` Mauro Carvalho Chehab
2018-09-11  9: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=20180905135528.ase6evcv7rlwufyr@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=tiwai@suse.de \
    /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