All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: "Chris Rorvick" <chris@rorvick.com>,
	"Alexey Khoroshilov" <khoroshilov@ispras.ru>,
	"Davide Berardi" <berardi.dav@gmail.com>,
	devel@driverdev.osuosl.org,
	"Fabian Mewes" <architekt@coding4coffee.org>,
	"Gulsah Kose" <gulsah.1004@gmail.com>,
	"Himangi Saraogi" <himangi774@gmail.com>,
	"Jerry Snitselaar" <dev@snitselaar.org>,
	"L. Alberto Giménez" <agimenez@sysvalve.es>,
	linux-kernel@vger.kernel.org,
	"Mikhail Boiko" <mm.boiko@yandex.ru>,
	"Monam Agarwal" <monamagarwal123@gmail.com>,
	"Peter P Waskiewicz Jr" <peter.p.waskiewicz.jr@intel.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>
Subject: Re: [PATCH 00/25] line6usb cleanup
Date: Mon, 12 Jan 2015 11:52:27 -0800	[thread overview]
Message-ID: <20150112195227.GA5452@kroah.com> (raw)
In-Reply-To: <s5hh9vwj6tm.wl-tiwai@suse.de>

On Mon, Jan 12, 2015 at 05:35:01PM +0100, Takashi Iwai wrote:
> At Sun, 11 Jan 2015 15:04:55 -0600,
> Chris Rorvick wrote:
> > 
> > > At Fri,  9 Jan 2015 23:35:46 -0600,
> > > Chris Rorvick wrote:
> > >>
> > >> I have a TonePort UX2 that I've used for testing, meaning that some of
> > >> this is really only compile-tested.
> > >
> > > If anyone is responsible for testing with real hardware, I'll happily
> > > review.
> > 
> > To be clear, the TonePort UX2 is real hardware.  But this driver
> > basically supports four classes of Line 6 devices and I'm only covering
> > one of them.
> > 
> > So this series is a first step in trying to address this.  Having this
> > as a single driver probably made sense when it was a separate project,
> > but now that it is in-tree it seems like the POD, PODHD, TonePort, and
> > Variax pieces should each be separate drivers that each depend on a core
> > Line 6 driver.  I think the cleanup in this series will make that
> > easier.  None of this is my area of expertise, though, so advice and
> > feedback is very welcome.
> > 
> > > are there any active developers for this driver?
> > 
> > I intended to do further work.  I know there is quite a bit of mundane
> > checkpatch cleanup that would need to get done before this could get
> > promoted, and I believe I read that it's using sysfs for stuff that
> > would normally be done via an ALSA interface, and the sysfs interface
> > has not been documented nor has it been justified.  All stuff I thought
> > I might look into.
> > 
> > But I'm just doing this for fun so I can't promise anything.  :-)
> 
> OK, so the situation looks fairly good, we have a few active
> developers and/or testers.  And the current code doesn't look so
> terrible despite of it being in staging directory.  That said, I think
> we can promote this stuff into sound/usb/line6 directory, then apply
> Chris' cleanup patches, and work on it further.
> 
> Does it sound OK for you guys?  Greg?
> 
> Once when I get approval, I'll start a new clean branch on sound.git
> tree so that you guys can work on it further for 3.20 kernel.

That sounds fine with me.  I have 4 other patches in my "to-apply" queue
other than these 25 for this driver that I'll forward on to you for
inclusion in your tree.

thanks,

greg k-h

  parent reply	other threads:[~2015-01-12 19:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-10  5:35 [PATCH 00/25] line6usb cleanup Chris Rorvick
2015-01-10  5:35 ` [PATCH 01/25] staging: line6: Remove `device_bit' from properties Chris Rorvick
2015-01-10  5:35 ` [PATCH 02/25] staging: line6: Remove line6_pod_transmit_paramter() Chris Rorvick
2015-01-10  5:35 ` [PATCH 03/25] staging: line6: Remove unsupported X3 devices Chris Rorvick
2015-01-10  5:35 ` [PATCH 04/25] staging: line6: Cleanup device table Chris Rorvick
2015-01-10  5:35 ` [PATCH 05/25] staging: line6: Define a device type enum Chris Rorvick
2015-01-10  5:35 ` [PATCH 06/25] staging: line6: Index properties array with device type Chris Rorvick
2015-01-10  5:35 ` [PATCH 07/25] staging: line6: Key off of " Chris Rorvick
2015-01-10  5:35 ` [PATCH 08/25] staging: line6: Remove idVendor and idProduct macros Chris Rorvick
2015-01-10  5:35 ` [PATCH 09/25] staging: line6: Remove useless comments Chris Rorvick
2015-01-10  5:35 ` [PATCH 10/25] staging: line6: Rename capability macros Chris Rorvick
2015-01-10  5:35 ` [PATCH 11/25] staging: line6: Use explicit indexes when defining properties Chris Rorvick
2015-01-10  5:35 ` [PATCH 12/25] staging: line6: List out capabilities individually Chris Rorvick
2015-01-10  5:35 ` [PATCH 13/25] staging: line6: Split out PODxt Live interfaces Chris Rorvick
2015-01-10  5:36 ` [PATCH 14/25] staging: line6: Split out POD HD500 interfaces Chris Rorvick
2015-01-10  5:36 ` [PATCH 15/25] staging: line6: Filter on Pocket POD interface Chris Rorvick
2015-01-10  5:36 ` [PATCH 16/25] staging: line6: Filter on UX2 interfaces Chris Rorvick
2015-01-10  5:36 ` [PATCH 17/25] staging: line6: Move altsetting to properties Chris Rorvick
2015-01-10  5:36 ` [PATCH 18/25] staging: line6: Move control endpoints " Chris Rorvick
2015-01-10  5:36 ` [PATCH 19/25] staging: line6: Remove stale Pocket POD PCM endpoints Chris Rorvick
2015-01-10  5:36 ` [PATCH 20/25] staging: line6: Move audio endpoints to properties Chris Rorvick
2015-01-10  5:36 ` [PATCH 21/25] staging: line6: Pass *_init() `usb_line6' pointers Chris Rorvick
2015-01-10  5:36 ` [PATCH 22/25] staging: line6: Pass *_process_message() " Chris Rorvick
2015-01-10  5:36 ` [PATCH 23/25] staging: line6: Call *_process_message() via pointer Chris Rorvick
2015-01-10  5:36 ` [PATCH 24/25] staging: line6: Call *_disconnect() " Chris Rorvick
2015-01-10  5:36 ` [PATCH 25/25] staging: line6: Make *_disconnect() functions static Chris Rorvick
2015-01-10  8:48 ` [PATCH 00/25] line6usb cleanup Stefan Hajnoczi
     [not found] ` <s5h8uh94nce.wl-tiwai@suse.de>
2015-01-11 11:26   ` Stefan Hajnoczi
2015-01-11 21:04   ` Chris Rorvick
     [not found]     ` <s5hh9vwj6tm.wl-tiwai@suse.de>
2015-01-12 19:52       ` Greg Kroah-Hartman [this message]
2015-01-12 22:07       ` Takashi Iwai
2015-01-12  9:23 ` Dan Carpenter

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=20150112195227.GA5452@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=agimenez@sysvalve.es \
    --cc=architekt@coding4coffee.org \
    --cc=berardi.dav@gmail.com \
    --cc=chris@rorvick.com \
    --cc=dev@snitselaar.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gulsah.1004@gmail.com \
    --cc=himangi774@gmail.com \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm.boiko@yandex.ru \
    --cc=monamagarwal123@gmail.com \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=stefanha@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.