Staging tree status for the .32 kernel merge

Staging tree status for the .32 kernel merge

[Greg KH]

Hi all,

Here's a summary of the state of the drivers/staging/ tree, basically
what will be coming in the 2.6.32 merge, and what the status of the
different drivers are so far.

First off, drivers/staging/ is NOT a dumping ground for dead code.  If
no one steps up to maintain and work to get the code merged into the
main portion of the kernel, the drivers will be removed.

As proof of that, the EPL (Ethernet Power Link) driver will be removed
in the .32 kernel, as no one is working on it, the upstream developers
never respond to my emails, and no one seems to care about it.

The pata_rdc driver is also going to be removed, as there is a "better"
one being merged through the libata tree for this hardware.

So, taking the drivers in chunks, here's some that have had active
development on for the .32 release:
	- rt* wireless drivers.  Bart has done amazing work merging all
	  of these together into something much better than they
	  originally were.  And even better, they still work!   Great
	  job Bart!

	- rtl* wireless drivers.  Again, Bart has been doing great work
	  here.

	- wlan-ng driver: a bit of work here, but this seems to be
	  dropping off, with the loss of a test platform for the driver.
	  Hopefully someone has a device around and can help out here.

	- comedi drivers had only a bit of work done, lots more is
	  needed here, let's not loose the fact that this is getting
	  closer to a mergable shape.

	- Android drivers have had a bit of work done, but upstream
	  seems to not care at all about what is going on here, as they
	  are working to forward port their code to the 2.6.29! kernel.
	  {sigh}.  If this keeps up, the drivers will be dropped in the
	  2.6.32 kernel release.
	  Note, Pavel has been adding some of the Dream hardware
	  drivers, which are separate from the core Android drivers.  I
	  have no objection to those, but they should work to get merged
	  to their "correct" places in the tree in another release or
	  so.

	- w35und driver.  It's slowly being worked on.

	- echo driver.  This one is now in good enough shape to merge
	  into the main kernel tree.  I'll send out review patches soon
	  for this.

	- eth131x driver. Alan Cox is working on fixing up the issues in
	  this driver.  Hopefully it will get into mergable shape soon.

New drivers that will show up in the .32 kernel release:
	- vt66* wireless drivers.  These VIA drivers are being actively
	  worked on to get into a much better shape.  Nice job.

	- new rt3090, and rtl8192e wireless drivers have been added and
	  worked on cleaning up issues involved in them.

	- Microsoft Hyper-V drivers.  Over 200 patches make up the
	  massive cleanup effort needed to just get this code into a
	  semi-sane kernel coding style (someone owes me a bit bottle of
	  rum for that work!)  Unfortunately the Microsoft developers
	  seem to have disappeared, and no one is answering my emails.
	  If they do not show back up to claim this driver soon, it will
	  be removed in the 2.6.33 release.  So sad...

	- quatech_usb2 driver.  I don't know if it quite works, but
	  someone is developing it, so I'm not complaining :)

	- VME bus drivers.  Yeah!  They are progressing nicely.

	- SEP and RAR drivers.  Alan Cox has been working on cleaning
	  these up a lot.

	- IIO (Industrial I/O), these are new drivers that are being
	  actively worked on.

	- pohmelfs and dst.  It seems that DST is dead, so I think I
	  will remove it in .33.  pohmelfs is under active development
	  outside of the tree, and hopefully patches start moving in
	  here to help out with keeping it up to date.

	- cowloop.  Yes, another COW driver!  :)  Seriously, this does
	  things that DM can't do, so it might be useful.  The upstream
	  developer is interested in getting this merged properly, and
	  is working on cleaning it up.

Drivers not being actively worked on:
	- otus.  This is sitting here until a "real" wireless driver
	  will be merged through the wireless tree.  Hopefully that
	  happens soon.

	- agnx wireless driver.  No one seems to care about it.  If no
	  one steps up soon, it will be removed in .33.

	- altpciechdma.  Upstream developers seem to have disappeared.
	  Again, if no one steps up, it will be removed in .33

	- asus_oled.  This only needs minor cleanups to get merged
	  properly into the main tree.  If someone wants an easy
	  project, this would be it.

	- at76_usb wireless driver.  Again, no one working on it, it
	  will be dropped in .33.

	- b3dfg.  I really do not think anyone cares about this.  again,
	  will be dropped if this is true in .33.

	- cpc-usb.  After the initial flurry of development, everyone
	  seems to have run away.  Was it the fact that I hadn't
	  showered in a few days?  Again, will be removed if no one
	  comes back.  And I am wearing deodorant now...

	- frontier.  A nice driver, again, should not be hard to get
	  merged into the main tree, if someone wants an easy project...

	- go7007.  Ugh.  Unless someone steps up now to take this over,
	  it's going to be removed in .33.  There is no hardware made
	  with this anymore, and no specs around that I know of, and the
	  code isn't the nicest in the world.

	- heci.  A wonderful example of a company throwing code over the
	  wall, watching it get rejected, and then running away as fast
	  as possible, all the while yelling over their shoulder, "it's
	  required on all new systems, you will love it!"  We don't, it
	  sucks, either fix it up, or I am removing it.

	- line6.  Another nice driver that should be simple to get
	  merged.  Please, if you are looking for something to do, this
	  is it.

	- me4000 and meilhaus.  They work on the same hardware, and they
	  duplicate the existing COMEDI drivers.  Someone thinks that
	  custom userspace interfaces are fun and required.  Turns out
	  that being special and unique is not what to do here, use the
	  COMEDI drivers instead.  These will be removed.  Heck, I'll go
	  remove them for .32, there is no reason these should still be
	  around, except to watch the RT guys squirm as they try to
	  figure out the byzantine locking and build logic here (which
	  certainly does count for something, cheap entertainment is
	  always good.)

	- mimio.  Another driver that should be simple to get merged.
	  Someone just step up to do this please, there are users of
	  this hardware out there.

	- p9auth.  While it seemed like a good idea, I don't think that
	  anyone actually uses this.  It will be removed in .33 unless
	  someone comes forward.

	- panel.  Another one that should be simple to merge.  Anyone?

	- phison.  What?  I thought I asked for this to be merged a
	  while ago, sorry about that, no reason it should still be in
	  staging anymore, it's just so small it slipped through the
	  cracks...

	- poch.  A long-suffering company is enduring the slowest
	  developers in the world here.  Hopefully the code will be
	  replaced with a UIO driver, but testing the userspace side
	  seems to be difficult and slow.  I have to give Redrapids
	  major credit for being patient here, they are being amazing.

	- rspiusb.  A weird, very expensive camera, from a company that
	  does not want to release the specs, and wants custom userspace
	  interfaces.  The code hasn't built since the 2.6.20 days.
	  I'll go delete it now from .32, it doesn't deserve to live as
	  no one cares about it, least of all, the original authors of
	  the code :(

	- slicoss and sxg.  These are being developed by a consulting
	  company for the main producer of the chips.  Yet they seem to
	  have disappeared half-way through the job.  Odd.  Hopefully
	  they come back soon.

	- stlc45xx.  Another wireless driver that no one seems to care
	  about.  So sad.  I guess no one will miss it when it goes away
	  in .33.

	- udlfb.  Video over USB, it doesn't get anymore whacked than
	  that.  This is still being developed but the developer doesn't
	  like to do incremental updates for some odd reason.  Hopefully
	  he pops up again with an update.  But for now, it is quite
	  workable for a number of developers.

	- usbip.  USB over IP.  I guess if you ran video over IP to your
	  USB device, that would be more whacked than just video over
	  USB.  This did get one big update during the .32 development
	  cycle, hopefully the developer can come back again when they
	  get some free time to continue working on it.  Rumor has it
	  that some major distros are starting to rely on this code, so
	  it would be nice to get their help to get it working better...

That should cover all of the 600+ patches in the staging tree for the
.32 kernel merge, and the existing drivers/staging/ tree.  If I missed
anything, please let me know.

Any questions?

thanks for making it this far,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

Hi Greg,

> 	- rt* wireless drivers.  Bart has done amazing work merging all
> 	  of these together into something much better than they
> 	  originally were.  And even better, they still work!   Great
> 	  job Bart!

Work on the rt2x00 project has also progressed to a point where the
drivers are getting much closer to being useful, so eventually all this
work will have been in vain.

> 	- vt66* wireless drivers.  These VIA drivers are being actively
> 	  worked on to get into a much better shape.  Nice job.

And do they come with their own wireless stack too?

> 	- otus.  This is sitting here until a "real" wireless driver
> 	  will be merged through the wireless tree.  Hopefully that
> 	  happens soon.

ar9170 has been in for a while now, it's just not quite at feature
parity yet -- however that also means otus will get no work whatsoever
from any of the wireless folks. Draw your own conclusions. Personally, I
would drop it and let the users figure out whether they can live with
ar9170 or need to support work on it.

> 	- agnx wireless driver.  No one seems to care about it.  If no
> 	  one steps up soon, it will be removed in .33.

Never really worked and the reverse engineered (!) hardware specs are
incomplete, with the main developer having given up. I think it's fair
to say that this is a dead end. I suspect the hardware isn't even
manufactured any more, at least I haven't recently seen it.

> 	- at76_usb wireless driver.  Again, no one working on it, it
> 	  will be dropped in .33.

There's at76c...something...-usb now, with a situation similar to the
ar9170/otus one.

> 	- stlc45xx.  Another wireless driver that no one seems to care
> 	  about.  So sad.  I guess no one will miss it when it goes away
> 	  in .33.

p54spi has gotten probably 95% of the functionality of this, so it's
only really useful for looking at the calibration data loading on the
N800/N810 platform...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Staging tree status for the .32 kernel merge

[Stefan Lippers-Hollmann]

Hi

On Thursday 03 September 2009, Johannes Berg wrote:
> Hi Greg,
[...]
> > 	- at76_usb wireless driver.  Again, no one working on it, it
> > 	  will be dropped in .33.
> 
> There's at76c...something...-usb now, with a situation similar to the
> ar9170/otus one.
[...]

at76c50x-usb, the mac80211 port of at76_usb, has been merged mainline in 
2.6.30, it works well on two at76c503a devices for me. 

Performance and features are comparable (there were WPA patches[1] around, 
CCMP for at76c505 devices only, but due to stability issues with the newer 
firmware, they weren't merged in staging or at76c50x-usb); both drivers 
sport an identical device coverage. The 802.11b chipsets themselves are 
no longer in production, but were rather common (also in handhelds) around 
6-9 years ago. In their current state, at76_usb and at76c50x-usb are 
restricted to WEP64/ 128 or unencrypted networks and work equally well 
(at76c50x-usb without the strange quirks that happen with at76_usb).

AT76C503A specification summary:
http://www.atmel.com/dyn/resources/prod_documents/1949S.PDF

AT76C505 specification summary:
http://www.atmel.com/atmel/acrobat/2364s.pdf

[1]	Original WPA patches:
	https://lists.berlios.de/pipermail/at76c503a-develop/2008-May/000240.html

Regards
	Stefan Lippers-Hollmann

Re: Staging tree status for the .32 kernel merge

[Bartlomiej Zolnierkiewicz]

On Thursday 03 September 2009 10:49:46 Johannes Berg wrote:
> Hi Greg,
> 
> > 	- rt* wireless drivers.  Bart has done amazing work merging all
> > 	  of these together into something much better than they
> > 	  originally were.  And even better, they still work!   Great
> > 	  job Bart!
> 
> Work on the rt2x00 project has also progressed to a point where the
> drivers are getting much closer to being useful, so eventually all this
> work will have been in vain.

The end goal of this work has always been having native rt2x00 support
for all those chipsets (as have been explained multiple times).  If this
means that one day we will delete all Ralink drivers in staging in favor
of proper wireless drivers -- fine with me.

In the meantime (before clean and proper support becomes useful) Linux
users are provided with the possibility to use their hardware before it
becomes obsolete.

Re: Staging tree status for the .32 kernel merge

[Christoph Hellwig]

On Thu, Sep 03, 2009 at 10:49:46AM +0200, Johannes Berg wrote:
> > 	- vt66* wireless drivers.  These VIA drivers are being actively
> > 	  worked on to get into a much better shape.  Nice job.
> 
> And do they come with their own wireless stack too?

Please don't put in the vendor vt6656 driver, it will conflict with a
proper mac80211 vt6656 driver a group mentored by me will submit late in
the 2.6.32 cycle.

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Thu, Sep 03, 2009 at 12:17:34PM -0400, Christoph Hellwig wrote:
> On Thu, Sep 03, 2009 at 10:49:46AM +0200, Johannes Berg wrote:
> > > 	- vt66* wireless drivers.  These VIA drivers are being actively
> > > 	  worked on to get into a much better shape.  Nice job.
> > 
> > And do they come with their own wireless stack too?
> 
> Please don't put in the vendor vt6656 driver, it will conflict with a
> proper mac80211 vt6656 driver a group mentored by me will submit late in
> the 2.6.32 cycle.

It's already in the linux-next tree, and is almost merged with the
vt6655 driver from what I can see.  When your driver goes in I will be
glad to disable the device ids that it covers, just let me know.

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Thu, Sep 03, 2009 at 02:48:43PM +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Thursday 03 September 2009, Johannes Berg wrote:
> > Hi Greg,
> [...]
> > > 	- at76_usb wireless driver.  Again, no one working on it, it
> > > 	  will be dropped in .33.
> > 
> > There's at76c...something...-usb now, with a situation similar to the
> > ar9170/otus one.
> [...]
> 
> at76c50x-usb, the mac80211 port of at76_usb, has been merged mainline in 
> 2.6.30, it works well on two at76c503a devices for me. 

So should I drop at76_usb from the tree right now?  It seems to cover
the same exact device ids, sorry for not noticing it yet.

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Kalle Valo]

Greg KH <greg@kroah.com> writes:

>> at76c50x-usb, the mac80211 port of at76_usb, has been merged mainline in 
>> 2.6.30, it works well on two at76c503a devices for me. 
>
> So should I drop at76_usb from the tree right now?  It seems to cover
> the same exact device ids, sorry for not noticing it yet.

Yes, please remove at76_usb from staging. It's not needed anymore now
that at76c50x-usb is in mainline. I know that some people are still
using at76_usb, but they need to convert sooner or later. And better to
force them to do it sooner.

-- 
Kalle Valo

Re: Staging tree status for the .32 kernel merge

[Christoph Hellwig]

On Thu, Sep 03, 2009 at 10:55:11AM -0700, Greg KH wrote:
> On Thu, Sep 03, 2009 at 12:17:34PM -0400, Christoph Hellwig wrote:
> > On Thu, Sep 03, 2009 at 10:49:46AM +0200, Johannes Berg wrote:
> > > > 	- vt66* wireless drivers.  These VIA drivers are being actively
> > > > 	  worked on to get into a much better shape.  Nice job.
> > > 
> > > And do they come with their own wireless stack too?
> > 
> > Please don't put in the vendor vt6656 driver, it will conflict with a
> > proper mac80211 vt6656 driver a group mentored by me will submit late in
> > the 2.6.32 cycle.
> 
> It's already in the linux-next tree, and is almost merged with the
> vt6655 driver from what I can see.  When your driver goes in I will be
> glad to disable the device ids that it covers, just let me know.

vt665_6_ has just one usb device id.  And please make sure to rename the
crap driver to something else than vt6656.ko so that it does not get in
way for the proper driver.

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Thu, Sep 03, 2009 at 02:40:17PM -0400, Christoph Hellwig wrote:
> On Thu, Sep 03, 2009 at 10:55:11AM -0700, Greg KH wrote:
> > On Thu, Sep 03, 2009 at 12:17:34PM -0400, Christoph Hellwig wrote:
> > > On Thu, Sep 03, 2009 at 10:49:46AM +0200, Johannes Berg wrote:
> > > > > 	- vt66* wireless drivers.  These VIA drivers are being actively
> > > > > 	  worked on to get into a much better shape.  Nice job.
> > > > 
> > > > And do they come with their own wireless stack too?
> > > 
> > > Please don't put in the vendor vt6656 driver, it will conflict with a
> > > proper mac80211 vt6656 driver a group mentored by me will submit late in
> > > the 2.6.32 cycle.
> > 
> > It's already in the linux-next tree, and is almost merged with the
> > vt6655 driver from what I can see.  When your driver goes in I will be
> > glad to disable the device ids that it covers, just let me know.
> 
> vt665_6_ has just one usb device id.  And please make sure to rename the
> crap driver to something else than vt6656.ko so that it does not get in
> way for the proper driver.

Ok, does vt6656_crap.ko sound good to you?  :)

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Thu, Sep 03, 2009 at 09:35:23PM +0300, Kalle Valo wrote:
> Greg KH <greg@kroah.com> writes:
> 
> >> at76c50x-usb, the mac80211 port of at76_usb, has been merged mainline in 
> >> 2.6.30, it works well on two at76c503a devices for me. 
> >
> > So should I drop at76_usb from the tree right now?  It seems to cover
> > the same exact device ids, sorry for not noticing it yet.
> 
> Yes, please remove at76_usb from staging. It's not needed anymore now
> that at76c50x-usb is in mainline. I know that some people are still
> using at76_usb, but they need to convert sooner or later. And better to
> force them to do it sooner.

Ok, it's now gone from my tree, and will be deleted in 2.6.32.

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Christoph Hellwig]

On Thu, Sep 03, 2009 at 11:55:46AM -0700, Greg KH wrote:
> Ok, does vt6656_crap.ko sound good to you?  :)

Fine with me.

Re: Staging tree status for the .32 kernel merge

[Luis R. Rodriguez]

>>       - otus.  This is sitting here until a "real" wireless driver
>>         will be merged through the wireless tree.  Hopefully that
>>         happens soon.
>
> ar9170 has been in for a while now, it's just not quite at feature
> parity yet -- however that also means otus will get no work whatsoever
> from any of the wireless folks. Draw your own conclusions. Personally, I
> would drop it and let the users figure out whether they can live with
> ar9170 or need to support work on it.

Greg, as Johannes noted otus has lacked focus as Johannes whipped out
a port for it in a few weeks and then Christian gave it some final
love taps for inclusion, we just still use otus as just a source of
documentation for any yet missing feature, but for that I guess I can
just refer people to my git tree. Chris would know better where we're
at as far as feature-parity is concerned though so I'll leave it up to
him to judge whether or not having otus gets some users anything
ar9170 doesn't yet have.

  Luis

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Thu, Sep 03, 2009 at 12:35:11PM -0700, Luis R. Rodriguez wrote:
> >>       - otus.  This is sitting here until a "real" wireless driver
> >>         will be merged through the wireless tree.  Hopefully that
> >>         happens soon.
> >
> > ar9170 has been in for a while now, it's just not quite at feature
> > parity yet -- however that also means otus will get no work whatsoever
> > from any of the wireless folks. Draw your own conclusions. Personally, I
> > would drop it and let the users figure out whether they can live with
> > ar9170 or need to support work on it.
> 
> Greg, as Johannes noted otus has lacked focus as Johannes whipped out
> a port for it in a few weeks and then Christian gave it some final
> love taps for inclusion, we just still use otus as just a source of
> documentation for any yet missing feature, but for that I guess I can
> just refer people to my git tree. Chris would know better where we're
> at as far as feature-parity is concerned though so I'll leave it up to
> him to judge whether or not having otus gets some users anything
> ar9170 doesn't yet have.

Ok, as I've said before, just let me know when you want the otus driver
removed from the tree and I'll be glad to do so.

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]


> 	- wlan-ng driver: a bit of work here, but this seems to be
> 	  dropping off, with the loss of a test platform for the driver.
> 	  Hopefully someone has a device around and can help out here.

I have a USB-Stick with prism2-chipset (Netgear MA111v1) that I succesfully
used with wlan-ng in the past. If it is of any help for further
development, I would donate it. Is somebody interested?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Staging tree status for the .32 kernel merge

[Belisko Marek]

Hi,

On Thu, Sep 3, 2009 at 6:14 AM, Greg KH<greg@kroah.com> wrote:
> Hi all,
>
> Here's a summary of the state of the drivers/staging/ tree, basically
> what will be coming in the 2.6.32 merge, and what the status of the
> different drivers are so far.
>
> First off, drivers/staging/ is NOT a dumping ground for dead code.  If
> no one steps up to maintain and work to get the code merged into the
> main portion of the kernel, the drivers will be removed.
>
> As proof of that, the EPL (Ethernet Power Link) driver will be removed
> in the .32 kernel, as no one is working on it, the upstream developers
> never respond to my emails, and no one seems to care about it.
>
> The pata_rdc driver is also going to be removed, as there is a "better"
> one being merged through the libata tree for this hardware.
>
> So, taking the drivers in chunks, here's some that have had active
> development on for the .32 release:
>        - rt* wireless drivers.  Bart has done amazing work merging all
>          of these together into something much better than they
>          originally were.  And even better, they still work!   Great
>          job Bart!
>
>        - rtl* wireless drivers.  Again, Bart has been doing great work
>          here.
>
>        - wlan-ng driver: a bit of work here, but this seems to be
>          dropping off, with the loss of a test platform for the driver.
>          Hopefully someone has a device around and can help out here.
>
>        - comedi drivers had only a bit of work done, lots more is
>          needed here, let's not loose the fact that this is getting
>          closer to a mergable shape.
>
>        - Android drivers have had a bit of work done, but upstream
>          seems to not care at all about what is going on here, as they
>          are working to forward port their code to the 2.6.29! kernel.
>          {sigh}.  If this keeps up, the drivers will be dropped in the
>          2.6.32 kernel release.
>          Note, Pavel has been adding some of the Dream hardware
>          drivers, which are separate from the core Android drivers.  I
>          have no objection to those, but they should work to get merged
>          to their "correct" places in the tree in another release or
>          so.
>
>        - w35und driver.  It's slowly being worked on.
>
>        - echo driver.  This one is now in good enough shape to merge
>          into the main kernel tree.  I'll send out review patches soon
>          for this.
>
>        - eth131x driver. Alan Cox is working on fixing up the issues in
>          this driver.  Hopefully it will get into mergable shape soon.
>
> New drivers that will show up in the .32 kernel release:
>        - vt66* wireless drivers.  These VIA drivers are being actively
>          worked on to get into a much better shape.  Nice job.
>
>        - new rt3090, and rtl8192e wireless drivers have been added and
>          worked on cleaning up issues involved in them.
>
>        - Microsoft Hyper-V drivers.  Over 200 patches make up the
>          massive cleanup effort needed to just get this code into a
>          semi-sane kernel coding style (someone owes me a bit bottle of
>          rum for that work!)  Unfortunately the Microsoft developers
>          seem to have disappeared, and no one is answering my emails.
>          If they do not show back up to claim this driver soon, it will
>          be removed in the 2.6.33 release.  So sad...
>
>        - quatech_usb2 driver.  I don't know if it quite works, but
>          someone is developing it, so I'm not complaining :)
>
>        - VME bus drivers.  Yeah!  They are progressing nicely.
>
>        - SEP and RAR drivers.  Alan Cox has been working on cleaning
>          these up a lot.
>
>        - IIO (Industrial I/O), these are new drivers that are being
>          actively worked on.
>
>        - pohmelfs and dst.  It seems that DST is dead, so I think I
>          will remove it in .33.  pohmelfs is under active development
>          outside of the tree, and hopefully patches start moving in
>          here to help out with keeping it up to date.
>
>        - cowloop.  Yes, another COW driver!  :)  Seriously, this does
>          things that DM can't do, so it might be useful.  The upstream
>          developer is interested in getting this merged properly, and
>          is working on cleaning it up.
>
> Drivers not being actively worked on:
>        - otus.  This is sitting here until a "real" wireless driver
>          will be merged through the wireless tree.  Hopefully that
>          happens soon.
>
>        - agnx wireless driver.  No one seems to care about it.  If no
>          one steps up soon, it will be removed in .33.
>
>        - altpciechdma.  Upstream developers seem to have disappeared.
>          Again, if no one steps up, it will be removed in .33
>
>        - asus_oled.  This only needs minor cleanups to get merged
>          properly into the main tree.  If someone wants an easy
>          project, this would be it.
I'll work on this driver. I'll send patches soon.
>
>        - at76_usb wireless driver.  Again, no one working on it, it
>          will be dropped in .33.
>
>        - b3dfg.  I really do not think anyone cares about this.  again,
>          will be dropped if this is true in .33.
>
>        - cpc-usb.  After the initial flurry of development, everyone
>          seems to have run away.  Was it the fact that I hadn't
>          showered in a few days?  Again, will be removed if no one
>          comes back.  And I am wearing deodorant now...
>
>        - frontier.  A nice driver, again, should not be hard to get
>          merged into the main tree, if someone wants an easy project...
>
>        - go7007.  Ugh.  Unless someone steps up now to take this over,
>          it's going to be removed in .33.  There is no hardware made
>          with this anymore, and no specs around that I know of, and the
>          code isn't the nicest in the world.
>
>        - heci.  A wonderful example of a company throwing code over the
>          wall, watching it get rejected, and then running away as fast
>          as possible, all the while yelling over their shoulder, "it's
>          required on all new systems, you will love it!"  We don't, it
>          sucks, either fix it up, or I am removing it.
>
>        - line6.  Another nice driver that should be simple to get
>          merged.  Please, if you are looking for something to do, this
>          is it.
>
>        - me4000 and meilhaus.  They work on the same hardware, and they
>          duplicate the existing COMEDI drivers.  Someone thinks that
>          custom userspace interfaces are fun and required.  Turns out
>          that being special and unique is not what to do here, use the
>          COMEDI drivers instead.  These will be removed.  Heck, I'll go
>          remove them for .32, there is no reason these should still be
>          around, except to watch the RT guys squirm as they try to
>          figure out the byzantine locking and build logic here (which
>          certainly does count for something, cheap entertainment is
>          always good.)
>
>        - mimio.  Another driver that should be simple to get merged.
>          Someone just step up to do this please, there are users of
>          this hardware out there.
>
>        - p9auth.  While it seemed like a good idea, I don't think that
>          anyone actually uses this.  It will be removed in .33 unless
>          someone comes forward.
>
>        - panel.  Another one that should be simple to merge.  Anyone?
>
>        - phison.  What?  I thought I asked for this to be merged a
>          while ago, sorry about that, no reason it should still be in
>          staging anymore, it's just so small it slipped through the
>          cracks...
>
>        - poch.  A long-suffering company is enduring the slowest
>          developers in the world here.  Hopefully the code will be
>          replaced with a UIO driver, but testing the userspace side
>          seems to be difficult and slow.  I have to give Redrapids
>          major credit for being patient here, they are being amazing.
>
>        - rspiusb.  A weird, very expensive camera, from a company that
>          does not want to release the specs, and wants custom userspace
>          interfaces.  The code hasn't built since the 2.6.20 days.
>          I'll go delete it now from .32, it doesn't deserve to live as
>          no one cares about it, least of all, the original authors of
>          the code :(
>
>        - slicoss and sxg.  These are being developed by a consulting
>          company for the main producer of the chips.  Yet they seem to
>          have disappeared half-way through the job.  Odd.  Hopefully
>          they come back soon.
>
>        - stlc45xx.  Another wireless driver that no one seems to care
>          about.  So sad.  I guess no one will miss it when it goes away
>          in .33.
>
>        - udlfb.  Video over USB, it doesn't get anymore whacked than
>          that.  This is still being developed but the developer doesn't
>          like to do incremental updates for some odd reason.  Hopefully
>          he pops up again with an update.  But for now, it is quite
>          workable for a number of developers.
>
>        - usbip.  USB over IP.  I guess if you ran video over IP to your
>          USB device, that would be more whacked than just video over
>          USB.  This did get one big update during the .32 development
>          cycle, hopefully the developer can come back again when they
>          get some free time to continue working on it.  Rumor has it
>          that some major distros are starting to rely on this code, so
>          it would be nice to get their help to get it working better...
>
> That should cover all of the 600+ patches in the staging tree for the
> .32 kernel merge, and the existing drivers/staging/ tree.  If I missed
> anything, please let me know.
>
> Any questions?
>
> thanks for making it this far,
>
> greg k-h
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
>

Marek

-- 
as simple as primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com

Re: Staging tree status for the .32 kernel merge

[Marcel Holtmann]

Hi Greg,

> > > > > And do they come with their own wireless stack too?
> > > > 
> > > > Please don't put in the vendor vt6656 driver, it will conflict with a
> > > > proper mac80211 vt6656 driver a group mentored by me will submit late in
> > > > the 2.6.32 cycle.
> > > 
> > > It's already in the linux-next tree, and is almost merged with the
> > > vt6655 driver from what I can see.  When your driver goes in I will be
> > > glad to disable the device ids that it covers, just let me know.
> > 
> > vt665_6_ has just one usb device id.  And please make sure to rename the
> > crap driver to something else than vt6656.ko so that it does not get in
> > way for the proper driver.
> 
> Ok, does vt6656_crap.ko sound good to you?  :)

can we suffix all of the staging drivers with _crap actually? At least
for the wireless ones.

Regards

Marcel

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Sat, Sep 05, 2009 at 02:16:00AM +0200, Marcel Holtmann wrote:
> Hi Greg,
> 
> > > > > > And do they come with their own wireless stack too?
> > > > > 
> > > > > Please don't put in the vendor vt6656 driver, it will conflict with a
> > > > > proper mac80211 vt6656 driver a group mentored by me will submit late in
> > > > > the 2.6.32 cycle.
> > > > 
> > > > It's already in the linux-next tree, and is almost merged with the
> > > > vt6655 driver from what I can see.  When your driver goes in I will be
> > > > glad to disable the device ids that it covers, just let me know.
> > > 
> > > vt665_6_ has just one usb device id.  And please make sure to rename the
> > > crap driver to something else than vt6656.ko so that it does not get in
> > > way for the proper driver.
> > 
> > Ok, does vt6656_crap.ko sound good to you?  :)
> 
> can we suffix all of the staging drivers with _crap actually? At least
> for the wireless ones.

Heh, no, the "crap" name is internal only, we don't expose that to
users.

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Willy Tarreau]

Hi Greg,

On Wed, Sep 02, 2009 at 09:14:30PM -0700, Greg KH wrote:
> 	- panel.  Another one that should be simple to merge.  Anyone?

I just got an email from a guy who proposed to work on it and who
showed me he's currently running tests and fixing a bug when removing
the module.

Hopefully he'll make enough progress to get the driver merged.

This proves that the principle of the staging tree seems to work,
and that your call was useful ;-)

Regards,
Willy

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Sat, Sep 05, 2009 at 02:39:51PM +0200, Willy Tarreau wrote:
> Hi Greg,
> 
> On Wed, Sep 02, 2009 at 09:14:30PM -0700, Greg KH wrote:
> > 	- panel.  Another one that should be simple to merge.  Anyone?
> 
> I just got an email from a guy who proposed to work on it and who
> showed me he's currently running tests and fixing a bug when removing
> the module.
> 
> Hopefully he'll make enough progress to get the driver merged.
> 
> This proves that the principle of the staging tree seems to work,
> and that your call was useful ;-)

Glad to hear it!

Re: Staging tree status for the .32 kernel merge

[Pavel Machek]

Hi!

> 	  Note, Pavel has been adding some of the Dream hardware
> 	  drivers, which are separate from the core Android drivers.  I
> 	  have no objection to those, but they should work to get merged
> 	  to their "correct" places in the tree in another release or
> 	  so.

Well, some of those drivers should be moderately easy (touchscreen),
but some (camera) will take longer than that. For example camera --
contains _lots_ of code, and uses obsolete v4l api.

Plus, I really need to get recent kernel to boot and then get arch/arm
pieces merged....

So next release is a bit optimistics, but I'm (slowly) working on it.
 

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Staging tree status for the .32 kernel merge

[Daniel Walker]

On Sun, 2009-09-06 at 07:28 +0200, Pavel Machek wrote:
> Hi!
> 
> > 	  Note, Pavel has been adding some of the Dream hardware
> > 	  drivers, which are separate from the core Android drivers.  I
> > 	  have no objection to those, but they should work to get merged
> > 	  to their "correct" places in the tree in another release or
> > 	  so.
> 
> Well, some of those drivers should be moderately easy (touchscreen),
> but some (camera) will take longer than that. For example camera --
> contains _lots_ of code, and uses obsolete v4l api.
> 
> Plus, I really need to get recent kernel to boot and then get arch/arm
> pieces merged....

I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
boot yet .. I had to drop certain parts like the key pad support since
it had a big generic change attached to it .. It's all part of a git
tree which I can expose if you want to look at it.

Daniel

Re: Staging tree status for the .32 kernel merge

[Mauro Carvalho Chehab]

Em Sun, 6 Sep 2009 07:28:19 +0200
Pavel Machek <pavel@ucw.cz> escreveu:

> Hi!
> 
> > 	  Note, Pavel has been adding some of the Dream hardware
> > 	  drivers, which are separate from the core Android drivers.  I
> > 	  have no objection to those, but they should work to get merged
> > 	  to their "correct" places in the tree in another release or
> > 	  so.
> 
> Well, some of those drivers should be moderately easy (touchscreen),
> but some (camera) will take longer than that. For example camera --
> contains _lots_ of code, and uses obsolete v4l api.

The usage of the obsolete V4L API is a problem since we aren't accepting any
drivers with the old API for a long time, doing large efforts to convert the
few remaining ones to V4L2 API.

This probably means also that they are not using the current V4L framework. Are
they already somewhere at the staging tree?



Cheers,
Mauro

Re: Staging tree status for the .32 kernel merge

[Mauro Carvalho Chehab]

Em Wed, 2 Sep 2009 21:14:30 -0700

> 	- go7007.  Ugh.  Unless someone steps up now to take this over,
> 	  it's going to be removed in .33.  There is no hardware made
> 	  with this anymore, and no specs around that I know of, and the
> 	  code isn't the nicest in the world.

I think nobody will cry if you remove this one. This is an old hardware, and not
manufactured anymore. The chipset of the compression hardware is
obsolete and orphaned, as the audio/video unit were sold to another company.

> 	- udlfb.  Video over USB, it doesn't get anymore whacked than
> 	  that.  This is still being developed but the developer doesn't
> 	  like to do incremental updates for some odd reason.  Hopefully
> 	  he pops up again with an update.  But for now, it is quite
> 	  workable for a number of developers.

Is this a video streaming driver (like other V4L2 drivers) or a video adapter
driver?



Cheers,
Mauro

Re: Staging tree status for the .32 kernel merge

[Greg KH]

On Mon, Sep 07, 2009 at 08:21:34PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 2 Sep 2009 21:14:30 -0700
> 
> > 	- go7007.  Ugh.  Unless someone steps up now to take this over,
> > 	  it's going to be removed in .33.  There is no hardware made
> > 	  with this anymore, and no specs around that I know of, and the
> > 	  code isn't the nicest in the world.
> 
> I think nobody will cry if you remove this one. This is an old hardware, and not
> manufactured anymore. The chipset of the compression hardware is
> obsolete and orphaned, as the audio/video unit were sold to another company.

I agree.  I do have a device around here, but it was only for testing,
the company who produced it said they could not release the specs due to
ownership issues.

> > 	- udlfb.  Video over USB, it doesn't get anymore whacked than
> > 	  that.  This is still being developed but the developer doesn't
> > 	  like to do incremental updates for some odd reason.  Hopefully
> > 	  he pops up again with an update.  But for now, it is quite
> > 	  workable for a number of developers.
> 
> Is this a video streaming driver (like other V4L2 drivers) or a video adapter
> driver?

Video adapter driver, it's a frame buffer driver, sorry for any
confusion.

thanks,

greg k-h

Re: Staging tree status for the .32 kernel merge

[Pavel Machek]

On Wed 2009-09-09 07:19:01, Daniel Walker wrote:
> On Wed, 2009-09-09 at 11:57 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > > 	  Note, Pavel has been adding some of the Dream hardware
> > > > > 	  drivers, which are separate from the core Android drivers.  I
> > > > > 	  have no objection to those, but they should work to get merged
> > > > > 	  to their "correct" places in the tree in another release or
> > > > > 	  so.
> > > > 
> > > > Well, some of those drivers should be moderately easy (touchscreen),
> > > > but some (camera) will take longer than that. For example camera --
> > > > contains _lots_ of code, and uses obsolete v4l api.
> > > > 
> > > > Plus, I really need to get recent kernel to boot and then get arch/arm
> > > > pieces merged....
> > > 
> > > I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
> > > boot yet .. I had to drop certain parts like the key pad support since
> > > it had a big generic change attached to it .. It's all part of a git
> > > tree which I can expose if you want to look at it.
> > 
> > Yes, minimal, but booting version would be very welcome. I tried to
> > produce exactly that few times, but did not succeed (yet).
> 
> Last night I discovered maybe a better tree to use ..
> 
> https://www.codeaurora.org/gitweb/quic/kernel/?p=bryanh/linux-2.6.git;a=summary
> 
> It's based off a newer kernel 2.6.31-rc6 . I have a feeling it's minus a
> lot of the google stuff.

Big question is... 'does it boot?' :-). The rest should be easy.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Staging tree status for the .32 kernel merge

[Pavel Machek]

On Mon 2009-09-07 20:12:05, Mauro Carvalho Chehab wrote:
> Em Sun, 6 Sep 2009 07:28:19 +0200
> Pavel Machek <pavel@ucw.cz> escreveu:
> 
> > Hi!
> > 
> > > 	  Note, Pavel has been adding some of the Dream hardware
> > > 	  drivers, which are separate from the core Android drivers.  I
> > > 	  have no objection to those, but they should work to get merged
> > > 	  to their "correct" places in the tree in another release or
> > > 	  so.
> > 
> > Well, some of those drivers should be moderately easy (touchscreen),
> > but some (camera) will take longer than that. For example camera --
> > contains _lots_ of code, and uses obsolete v4l api.
> 
> The usage of the obsolete V4L API is a problem since we aren't accepting any
> drivers with the old API for a long time, doing large efforts to convert the
> few remaining ones to V4L2 API.

Understood.

> This probably means also that they are not using the current V4L framework. Are
> they already somewhere at the staging tree?

It will appear in drivers/staging/dream/camera in 2.6.32 or so. It
should be in -next by now.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Staging tree status for the .32 kernel merge

[Pavel Machek]

Hi!

> > > 	  Note, Pavel has been adding some of the Dream hardware
> > > 	  drivers, which are separate from the core Android drivers.  I
> > > 	  have no objection to those, but they should work to get merged
> > > 	  to their "correct" places in the tree in another release or
> > > 	  so.
> > 
> > Well, some of those drivers should be moderately easy (touchscreen),
> > but some (camera) will take longer than that. For example camera --
> > contains _lots_ of code, and uses obsolete v4l api.
> > 
> > Plus, I really need to get recent kernel to boot and then get arch/arm
> > pieces merged....
> 
> I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
> boot yet .. I had to drop certain parts like the key pad support since
> it had a big generic change attached to it .. It's all part of a git
> tree which I can expose if you want to look at it.

Yes, minimal, but booting version would be very welcome. I tried to
produce exactly that few times, but did not succeed (yet).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Staging tree status for the .32 kernel merge

[Daniel Walker]

On Wed, 2009-09-09 at 11:57 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > 	  Note, Pavel has been adding some of the Dream hardware
> > > > 	  drivers, which are separate from the core Android drivers.  I
> > > > 	  have no objection to those, but they should work to get merged
> > > > 	  to their "correct" places in the tree in another release or
> > > > 	  so.
> > > 
> > > Well, some of those drivers should be moderately easy (touchscreen),
> > > but some (camera) will take longer than that. For example camera --
> > > contains _lots_ of code, and uses obsolete v4l api.
> > > 
> > > Plus, I really need to get recent kernel to boot and then get arch/arm
> > > pieces merged....
> > 
> > I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
> > boot yet .. I had to drop certain parts like the key pad support since
> > it had a big generic change attached to it .. It's all part of a git
> > tree which I can expose if you want to look at it.
> 
> Yes, minimal, but booting version would be very welcome. I tried to
> produce exactly that few times, but did not succeed (yet).

Last night I discovered maybe a better tree to use ..

https://www.codeaurora.org/gitweb/quic/kernel/?p=bryanh/linux-2.6.git;a=summary

It's based off a newer kernel 2.6.31-rc6 . I have a feeling it's minus a
lot of the google stuff.

Daniel

Re: Staging tree status for the .32 kernel merge

[Pavel Machek]

On Wed 2009-09-09 07:19:01, Daniel Walker wrote:
> On Wed, 2009-09-09 at 11:57 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > > 	  Note, Pavel has been adding some of the Dream hardware
> > > > > 	  drivers, which are separate from the core Android drivers.  I
> > > > > 	  have no objection to those, but they should work to get merged
> > > > > 	  to their "correct" places in the tree in another release or
> > > > > 	  so.
> > > > 
> > > > Well, some of those drivers should be moderately easy (touchscreen),
> > > > but some (camera) will take longer than that. For example camera --
> > > > contains _lots_ of code, and uses obsolete v4l api.
> > > > 
> > > > Plus, I really need to get recent kernel to boot and then get arch/arm
> > > > pieces merged....
> > > 
> > > I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
> > > boot yet .. I had to drop certain parts like the key pad support since
> > > it had a big generic change attached to it .. It's all part of a git
> > > tree which I can expose if you want to look at it.
> > 
> > Yes, minimal, but booting version would be very welcome. I tried to
> > produce exactly that few times, but did not succeed (yet).
> 
> Last night I discovered maybe a better tree to use ..
> 
> https://www.codeaurora.org/gitweb/quic/kernel/?p=bryanh/linux-2.6.git;a=summary
> 
> It's based off a newer kernel 2.6.31-rc6 . I have a feeling it's minus a
> lot of the google stuff.

Did you get it to boot? ... ... It does not seem to contain any HTC
Dream stuff; why do you think it is interesting?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Staging tree status for the .32 kernel merge

[Brian Swetland]

On Wed, Sep 9, 2009 at 7:19 AM, Daniel Walker<dwalker@fifo99.com> wrote:
> On Wed, 2009-09-09 at 11:57 +0200, Pavel Machek wrote:
>> Hi!
>> > > >           Note, Pavel has been adding some of the Dream hardware
>> > > >           drivers, which are separate from the core Android drivers.  I
>> > > >           have no objection to those, but they should work to get merged
>> > > >           to their "correct" places in the tree in another release or
>> > > >           so.
>> > >
>> > > Well, some of those drivers should be moderately easy (touchscreen),
>> > > but some (camera) will take longer than that. For example camera --
>> > > contains _lots_ of code, and uses obsolete v4l api.
>> > >
>> > > Plus, I really need to get recent kernel to boot and then get arch/arm
>> > > pieces merged....
>> >
>> > I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
>> > boot yet .. I had to drop certain parts like the key pad support since
>> > it had a big generic change attached to it .. It's all part of a git
>> > tree which I can expose if you want to look at it.
>>
>> Yes, minimal, but booting version would be very welcome. I tried to
>> produce exactly that few times, but did not succeed (yet).
>
> Last night I discovered maybe a better tree to use ..
>
> https://www.codeaurora.org/gitweb/quic/kernel/?p=bryanh/linux-2.6.git;a=summary
>
> It's based off a newer kernel 2.6.31-rc6 . I have a feeling it's minus a
> lot of the google stuff.

That would be somewhat surprising, since the qct/quicinc folks support
the full android stack on top of their kernels (though we're not
entirely converged at this point).

Not sure if their tree has full support for devices like
dream/sapphire/etc -- I believe they primarily verify on their SURF
platform.  Added Bryan to the CC so he can comment.

Brian

RE: Staging tree status for the .32 kernel merge

[Huntsman, Bryan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2611 bytes --]

> On Wed, Sep 9, 2009 at 7:19 AM, Daniel Walker<dwalker@fifo99.com> wrote:
> > On Wed, 2009-09-09 at 11:57 +0200, Pavel Machek wrote:
> >> Hi!
> >> > > >           Note, Pavel has been adding some of the Dream hardware
> >> > > >           drivers, which are separate from the core Android drivers.
>  I
> >> > > >           have no objection to those, but they should work to get
> merged
> >> > > >           to their "correct" places in the tree in another release
> or
> >> > > >           so.
> >> > >
> >> > > Well, some of those drivers should be moderately easy (touchscreen),
> >> > > but some (camera) will take longer than that. For example camera --
> >> > > contains _lots_ of code, and uses obsolete v4l api.
> >> > >
> >> > > Plus, I really need to get recent kernel to boot and then get arch/arm
> >> > > pieces merged....
> >> >
> >> > I've got a tree with a lot of the arch/arm/msm pieces isolated, doesn't
> >> > boot yet .. I had to drop certain parts like the key pad support since
> >> > it had a big generic change attached to it .. It's all part of a git
> >> > tree which I can expose if you want to look at it.
> >>
> >> Yes, minimal, but booting version would be very welcome. I tried to
> >> produce exactly that few times, but did not succeed (yet).
> >
> > Last night I discovered maybe a better tree to use ..
> >
> > https://www.codeaurora.org/gitweb/quic/kernel/?p=bryanh/linux-
> 2.6.git;a=summary
> >
> > It's based off a newer kernel 2.6.31-rc6 . I have a feeling it's minus a
> > lot of the google stuff.
> 
> That would be somewhat surprising, since the qct/quicinc folks support
> the full android stack on top of their kernels (though we're not
> entirely converged at this point).
> 
> Not sure if their tree has full support for devices like
> dream/sapphire/etc -- I believe they primarily verify on their SURF
> platform.  Added Bryan to the CC so he can comment.
> 
> Brian

Brian, the tree you reference is not for Android.  It's just a minimal tree to boot our internal SURF platform on .31.  It may have some android bits in it but they are not used.  We only validated console and the sd bus driver.  Our latest released Android tree is https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29b.  It's based on your android-msm-2.6.29 branch from back in May and has whatever dream/sapphire support you had at that time.

- Bryan
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Staging tree status for the .32 kernel merge

[Peter Huewe]

Am Saturday 05 September 2009 16:50:35 schrieb Greg KH:
> On Sat, Sep 05, 2009 at 02:39:51PM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > On Wed, Sep 02, 2009 at 09:14:30PM -0700, Greg KH wrote:
> > > 	- panel.  Another one that should be simple to merge.  Anyone?
> >
> > I just got an email from a guy who proposed to work on it and who
> > showed me he's currently running tests and fixing a bug when removing
> > the module.
> >
> > Hopefully he'll make enough progress to get the driver merged.
> >
> > This proves that the principle of the staging tree seems to work,
> > and that your call was useful ;-)
>
> Glad to hear it!

yeah - Greg's call definitely was useful!
Although I'm still not sure if there is a point to getting the driver merged 
or not -- see discussion: "staging panel driver"
http://driverdev.linuxdriverproject.org/pipermail/devel/2009-September/001610.html

More opinions/suggestions are welcomed - especially from people who are more 
into lcdproc than I am.

However I'm currently working on it anyways - I already eliminated the bug:
while removing the module misc_deregister gets called twice (keypad and led - 
both twice) - once in the  panel_detach function and once in the 
panel_cleanup_module function.

And of course the second call fails :)
I will provide a (very simple :) patch to these issues tomorrow.



Thanks,
Peter

Frontier USB Drivers (Was: Staging tree status for the .32 kernel merge)

[Dave Taht]

Greg KH <greg@kroah.com> writes:

> 	- frontier.  A nice driver, again, should not be hard to get
> 	  merged into the main tree, if someone wants an easy project...

Thank you for your kind words.

Mild correction, it's actually two drivers, one for the Frontier Designs
Tranzport, the other is for the Frontier Designs Alphatrack. The
interfaces are very similar in most respects.

I would certainly like to see the frontier drivers escape staging and
become part of the regular kernel. The tranzport sub-driver in
particular, has been in daily use in my studio for nearly two years now,
and people like Dave Phillips are also happy with it. (at least the
kernel portion, userspace needs more work)

In looking over the drivers/staging/frontier/TODO list for these
drivers, I would love to get some help and feedback on the remaining,
minor, problems:

	- review by the USB developer community

DEEPLY Desired, see below for details. 

- Missing usb ids for lsusb.

Although I had submitted the requisite usb ids to the maintainer
I'm not sure if they ever made it into the kernel. I am not presently
tracking the tip of kernel development however.

- Stolen USB minor device numbers

I reused some uncommon usb minor numbers in these drivers. Presumably
new ones need to be applied for or has the world gone dynamic these days?

Haven't the foggiest idea how to apply for minor numbers. I just googled
for the right procedure. Oh, wait, there's this greg KH guy that assigns
those. Greg!  Need two minor numbers for these devices! We've talked
about it, a couple times...

It's possible to plug more than one Alphatrack into a system. I'm not
sure how that's supposed to work, numberwise.

	- checkpatch.pl clean

I submitted patches to this during the last kernel round that made the
alphatrack and tranzport drivers checkpatch.pl clean for all except one
error message that I didn't understand, which I noted at the time.

$ /home/d/src/git/linux-2.6/scripts/checkpatch.pl --file alphatrack.c
WARNING: mutexes are preferred for single holder semaphores
#681: FILE: alphatrack.c:681:
+	init_MUTEX(&dev->sem);

total: 0 errors, 1 warnings, 895 lines checked


***But it IS a single holder semaphore!***

	- sparse clean

I don't know a darn thing about sparse. I'm willing to learn but...

	- possibly just port to userspace with libusb

No. The original version of this was written for libusb. Unless libusb
has improved dramatically, it was simply incapable of keeping up with
interrupts, particularly the high number of interrupts the scroll wheel
would generate. When you have a keyboard-like device, missing one key-up
event is disastrous. When the tranzport is controlling a real-time audio
session, with live musicians and backing tracks all playing at once,
when you hit that key and spin that knob it better do what you expect,
every time. Thus, these became kernel drivers.

I also tried writing this in UIO, but that lacked adequate support for
USB disconnect events. Thus, these drivers became very small drivers
that merely handled interrupts, usb related events, and kept a
ringbuffer around of backlogged events.

I wrote these drivers back around 2.6.17 and today is the first time
I've subscribed to read lkml since 2.6.22....

	- fix userspace interface to be sane

This is the biggest open question I have. Right now the drivers just
handle the interrupts, and queue up the data in a ringbuffer, sending the
events in the exact same format as received from the device, and vice versa.

Coming up with an abstract means to handle a very specialized device - a
control surface that simultaneously is a LCD screen, a bunch of LEDS, a
scroll wheel, and 20+ buttons that can be pressed in various
combinations, would kind of involve reinventing a char I/O based X11,
and I don't really feel that much or any of that needs to happen in
kernel space.

(the alphatrack is worse, it has a slider with feedback and buttons that
have touch sensitivity, and a special key that remaps the sliders and
buttons to another keymap entirely)

There are a lot of "surfaces" out there in the music world, with all
kinds of combinations of buttons and knobs and gee-gaws, etc, but coming
up with adaquate abstractions for them all is an effort on the scale of
X11, with a considerably smaller user-base, and more rapidly shifting
market.

Far better, I thought, to just handle the RT critical portions of the
code in the kernel and hand off the rest of the chaos to userspace.

But certainly, some guidance and thought on this matter would be welcomed.

	- review by the USB developer community

I'd like that. My test or production userspace code doesn't test poll
for example. My inexperienced eyeballs look at the poll stub and say
that it can't possibly work, and I worry that there are situations
involving suspend or hubs or inotify or some other desirable set of
usb calls, or something that has changed since I wrote the thing back in
2.6.17 days. that actually matters in newer versions of the kernel.

So if someone truly expert in USB would PLEASE review this code I'd
appreciate it very much. I can be available via irc or email for further
discussions, and I will track lkml for as long as it takes.

Stuff that is not in the TODO that needs to be done.

Documentation 

udev line

-- 

Dave (AKA "Mike") Taht 
Postcards from the Bleeding Edge (http://the-edge.blogspot.com)

Re: Frontier USB Drivers (Was: Staging tree status for the .32 kernel merge)

[Greg KH]

On Sat, Sep 12, 2009 at 01:40:28PM -0600, Dave Taht wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > 	- frontier.  A nice driver, again, should not be hard to get
> > 	  merged into the main tree, if someone wants an easy project...
> 
> Thank you for your kind words.
> 
> Mild correction, it's actually two drivers, one for the Frontier Designs
> Tranzport, the other is for the Frontier Designs Alphatrack. The
> interfaces are very similar in most respects.

Yes, sorry.

> I would certainly like to see the frontier drivers escape staging and
> become part of the regular kernel. The tranzport sub-driver in
> particular, has been in daily use in my studio for nearly two years now,
> and people like Dave Phillips are also happy with it. (at least the
> kernel portion, userspace needs more work)
> 
> In looking over the drivers/staging/frontier/TODO list for these
> drivers, I would love to get some help and feedback on the remaining,
> minor, problems:
> 
> 	- review by the USB developer community
> 
> DEEPLY Desired, see below for details. 
> 
> - Missing usb ids for lsusb.
> 
> Although I had submitted the requisite usb ids to the maintainer
> I'm not sure if they ever made it into the kernel. I am not presently
> tracking the tip of kernel development however.

Who did you send them to?  Me?

> - Stolen USB minor device numbers
> 
> I reused some uncommon usb minor numbers in these drivers. Presumably
> new ones need to be applied for or has the world gone dynamic these days?
> 
> Haven't the foggiest idea how to apply for minor numbers. I just googled
> for the right procedure. Oh, wait, there's this greg KH guy that assigns
> those. Greg!  Need two minor numbers for these devices! We've talked
> about it, a couple times...
> 
> It's possible to plug more than one Alphatrack into a system. I'm not
> sure how that's supposed to work, numberwise.

I'll have to pick a number, and a range, will do that when the drivers
move to the main portion of the kernel tree.

> 	- checkpatch.pl clean
> 
> I submitted patches to this during the last kernel round that made the
> alphatrack and tranzport drivers checkpatch.pl clean for all except one
> error message that I didn't understand, which I noted at the time.
> 
> $ /home/d/src/git/linux-2.6/scripts/checkpatch.pl --file alphatrack.c
> WARNING: mutexes are preferred for single holder semaphores
> #681: FILE: alphatrack.c:681:
> +	init_MUTEX(&dev->sem);
> 
> total: 0 errors, 1 warnings, 895 lines checked
> 
> 
> ***But it IS a single holder semaphore!***

Can this be a 'struct semaphore' then?

> 	- sparse clean
> 
> I don't know a darn thing about sparse. I'm willing to learn but...

I can do this.

> 	- possibly just port to userspace with libusb
> 
> No. The original version of this was written for libusb. Unless libusb
> has improved dramatically, it was simply incapable of keeping up with
> interrupts, particularly the high number of interrupts the scroll wheel
> would generate. When you have a keyboard-like device, missing one key-up
> event is disastrous. When the tranzport is controlling a real-time audio
> session, with live musicians and backing tracks all playing at once,
> when you hit that key and spin that knob it better do what you expect,
> every time. Thus, these became kernel drivers.
> 
> I also tried writing this in UIO, but that lacked adequate support for
> USB disconnect events. Thus, these drivers became very small drivers
> that merely handled interrupts, usb related events, and kept a
> ringbuffer around of backlogged events.

Ok, that's fair enough, just want to make sure.

> I wrote these drivers back around 2.6.17 and today is the first time
> I've subscribed to read lkml since 2.6.22....
> 
> 	- fix userspace interface to be sane
> 
> This is the biggest open question I have. Right now the drivers just
> handle the interrupts, and queue up the data in a ringbuffer, sending the
> events in the exact same format as received from the device, and vice versa.
> 
> Coming up with an abstract means to handle a very specialized device - a
> control surface that simultaneously is a LCD screen, a bunch of LEDS, a
> scroll wheel, and 20+ buttons that can be pressed in various
> combinations, would kind of involve reinventing a char I/O based X11,
> and I don't really feel that much or any of that needs to happen in
> kernel space.
> 
> (the alphatrack is worse, it has a slider with feedback and buttons that
> have touch sensitivity, and a special key that remaps the sliders and
> buttons to another keymap entirely)
> 
> There are a lot of "surfaces" out there in the music world, with all
> kinds of combinations of buttons and knobs and gee-gaws, etc, but coming
> up with adaquate abstractions for them all is an effort on the scale of
> X11, with a considerably smaller user-base, and more rapidly shifting
> market.
> 
> Far better, I thought, to just handle the RT critical portions of the
> code in the kernel and hand off the rest of the chaos to userspace.
> 
> But certainly, some guidance and thought on this matter would be welcomed.

Hm, I'll look at this, but if what you say is how it works, it might be
fine as-is.

> 	- review by the USB developer community
> 
> I'd like that. My test or production userspace code doesn't test poll
> for example. My inexperienced eyeballs look at the poll stub and say
> that it can't possibly work, and I worry that there are situations
> involving suspend or hubs or inotify or some other desirable set of
> usb calls, or something that has changed since I wrote the thing back in
> 2.6.17 days. that actually matters in newer versions of the kernel.
> 
> So if someone truly expert in USB would PLEASE review this code I'd
> appreciate it very much. I can be available via irc or email for further
> discussions, and I will track lkml for as long as it takes.
> 
> Stuff that is not in the TODO that needs to be done.
> 
> Documentation 
> 
> udev line

I'll take what we currently have, run it through sparse, and then submit
it to the linux-usb list for review there.

And we can then take it from there.

thanks,

greg k-h

Re: Frontier USB Drivers (Was: Staging tree status for the .32 kernel merge)

[Clemens Ladisch]

Dave Taht wrote:
> 	- fix userspace interface to be sane
> 
> This is the biggest open question I have. Right now the drivers just
> handle the interrupts, and queue up the data in a ringbuffer, sending the
> events in the exact same format as received from the device, and vice versa.
> 
> Coming up with an abstract means to handle a very specialized device - a
> control surface that simultaneously is a LCD screen, a bunch of LEDS, a
> scroll wheel, and 20+ buttons that can be pressed in various
> combinations, would kind of involve reinventing a char I/O based X11,
> and I don't really feel that much or any of that needs to happen in
> kernel space.
> 
> (the alphatrack is worse, it has a slider with feedback and buttons that
> have touch sensitivity, and a special key that remaps the sliders and
> buttons to another keymap entirely)
> 
> There are a lot of "surfaces" out there in the music world, with all
> kinds of combinations of buttons and knobs and gee-gaws, etc,

... and practically all of them send/receive MIDI messages, which ties
in with the fact that most applications you would want to control with
this allow to be controlled by MIDI.

The Frontier Windows drivers also have a MIDI mode, so I'd strongly
suggest that you implement that.

> Far better, I thought, to just handle the RT critical portions of the
> code in the kernel and hand off the rest of the chaos to userspace.

The ALSA framework already handles buffering and routing of MIDI events,
so you'd just have to map between the device's bits and sequencer events.


Best regards,
Clemens