> Documentation
> * Update HOWTO (more hotplug focus)
> * Document hiddev API, add examples
> * Document usbdevfs API
> * Improve programmers guide, add more examples.
>
this point seems to be done first as there are really few documentation
abut usb programing and as with docs more developer
Greg KH wrote:
>
> On Mon, Nov 26, 2001 at 06:53:16AM +1100, Brad Hards wrote:
> > A few other classes that no-one seems to care about (like common class, or the
> > eternal favourite of USBDI:)
> > http://www.usb.org/developers/data/devclass/usbdi10.pdf
>
> The USBDI class is to try to help us
> > > Somewhat related, more of the usbcore functions should show up in
> > > the kernel programming guide -- not a separate doc.
> >
> > Are there any public functions that aren't documented?
>
> Yes. I'll try provide a patch to document some of them soon.
Coming up shortly. I documented abo
> > > I think you have the same idea as I have, but I don't want to dump the
> > > old hcd's completely, but use them as a basis to integrate into the new
> > > hcd architecture.
> >
> > Agreed. Old hcds get dumped from a user space view, not from a code re-use
> > view. I just want to avoid havin
> - Better reference counting and locking in the core USB code, to help
> reduce driver locking issues. A lot of this will fall out of the
> power management patches (hopefully.)
I'd probably attribute it to the device tree management work,
but since that's being driven by power manage
On Mon, Nov 26, 2001 at 06:53:16AM +1100, Brad Hards wrote:
> A few other classes that no-one seems to care about (like common class, or the
> eternal favourite of USBDI:)
> http://www.usb.org/developers/data/devclass/usbdi10.pdf
The USBDI class is to try to help us write drivers, not a type of d
On Mon, Nov 26, 2001, Brad Hards <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
>
> > I think you have the same idea as I have, but I don't want to dump the
> > old hcd's completely, but use them as a basis to integrate into the new
> > hcd architecture.
> Agreed. Old hcds get dumped from a
Johannes Erdfelt wrote:
> I think you have the same idea as I have, but I don't want to dump the
> old hcd's completely, but use them as a basis to integrate into the new
> hcd architecture.
Agreed. Old hcds get dumped from a user space view, not from a code re-use
view. I just want to avoid havi
On Sat, Nov 24, 2001, Brad Hards <[EMAIL PROTECTED]> wrote:
> With the release of 2.5.0, I thought I might start a discussion on what the
> Linux USB hackers might like to accomplish for 2.6.0. Nothing like a little
> planning
Here's my opinion as USB coder peon :)
> Switch to new hcd archit
[EMAIL PROTECTED] wrote:
>
> I realize that the goals presented are more sexy (interesting, .. you
> choose your word), but as far as Im concerned, going back and making
> things work with DEVFS would be on the top of my list as a USER.
what is not working already with devfs?
Brad
_
I realize that the goals presented are more sexy (interesting, .. you
choose your word), but as far as Im concerned, going back and making
things work with DEVFS would be on the top of my list as a USER.
--
Reg.Clemens
On Fri, Nov 23, 2001 at 07:00:09PM -0800, David Brownell wrote:
> You beat me to the question ... :)
>
> That looks like a good list. I'll just comment on a few specific
> items below, and hope that others chime in! I'm sure Greg and
> Johannes both have comments here.
>
> There may also need
On Sat, Nov 24, 2001 at 12:58:38PM +1100, Brad Hards wrote:
[snip]
> * add UHCI support (based on either uhci or usb-uhci, or both)
[snip]
> Specific driver changes
When we do this can we please try and make UHCI endian safe? I
understand there's patches for one of the current drivers, but not
Am Samstag 24 November 2001 04:00 schrieb David Brownell:
> You beat me to the question ... :)
>
> That looks like a good list. I'll just comment on a few specific
> items below, and hope that others chime in! I'm sure Greg and
> Johannes both have comments here.
>
> There may also need to be co
14 matches
Mail list logo
