Re: [RFC] USBdump patches

[Weongyo Jeong]

On Wed, Nov 24, 2010 at 07:35:30PM +1300, Andrew Thompson wrote:
> On 24 November 2010 18:46, Weongyo Jeong  wrote:
> > On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote:
> >> On 24 November 2010 13:36, Jung-uk Kim  wrote:
> >> > On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote:
> >> >>    - BPF was normally for ethernet frames (most operations were
> >> >> based on mbuf including the machine filter and there were a lot of
> >> >> assumptions the input buffer is mbuf type.  For example, handling
> >> >> BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf
> >> >> style that it's just a linear buffer.  So the most important code
> >> >> or assumption wasn't compatible.
> >> >
> >> > BPF can deal with linear buffer just fine.  For example, ng_bpf(4)
> >> > does it.  Please see sys/netgraph/ng_bpf.c.
> >> >
> >> >>    - Just making the patch for BPF code, it looked like a trick or
> >> >> a hack to me because I couldn't define what BPF should be.
> >> >
> >> > If you don't want to touch bpf.c for some reason, netgraph(4) (->
> >> > ng_bpf) may be an alternate solution for you.
> >> >
> >> >>    - I could not define BPF exactly myself that what BPF should
> >> >> cover. I agreed with that BPF is for ethernet packet filtering but
> >> >> could not make sure myself that BPF could cover USB packets.
> >> >
> >> > BPF is a generic packet filter machine, i.e., bytecode is generic
> >> > enough for any type of data stream.
> >>
> >> I agree that this is the best way forward, if it can be achieved.
> >
> > Attached is what I really wanted to do.  USB pf is greatly simplified
> > and perfectly satisfy me.  It'll fully benefit from changes of BPF code.
> >
> > I'll commit this version into HEAD if no objections.
> 
> Looks good. Is this compatible with the wireshark pcap format?

Not yet.  I think it could happen soon.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [RFC] USBdump patches

[Weongyo Jeong]

On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote:
> On 24 November 2010 13:36, Jung-uk Kim  wrote:
> > On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote:
> >>    - BPF was normally for ethernet frames (most operations were
> >> based on mbuf including the machine filter and there were a lot of
> >> assumptions the input buffer is mbuf type.  For example, handling
> >> BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf
> >> style that it's just a linear buffer.  So the most important code
> >> or assumption wasn't compatible.
> >
> > BPF can deal with linear buffer just fine.  For example, ng_bpf(4)
> > does it.  Please see sys/netgraph/ng_bpf.c.
> >
> >>    - Just making the patch for BPF code, it looked like a trick or
> >> a hack to me because I couldn't define what BPF should be.
> >
> > If you don't want to touch bpf.c for some reason, netgraph(4) (->
> > ng_bpf) may be an alternate solution for you.
> >
> >>    - I could not define BPF exactly myself that what BPF should
> >> cover. I agreed with that BPF is for ethernet packet filtering but
> >> could not make sure myself that BPF could cover USB packets.
> >
> > BPF is a generic packet filter machine, i.e., bytecode is generic
> > enough for any type of data stream.
> 
> I agree that this is the best way forward, if it can be achieved.

Attached is what I really wanted to do.  USB pf is greatly simplified
and perfectly satisfy me.  It'll fully benefit from changes of BPF code.

I'll commit this version into HEAD if no objections.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [RFC] USBdump patches

[Weongyo Jeong]

On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote:
> On 24 November 2010 13:36, Jung-uk Kim  wrote:
> > On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote:
> >>    - BPF was normally for ethernet frames (most operations were
> >> based on mbuf including the machine filter and there were a lot of
> >> assumptions the input buffer is mbuf type.  For example, handling
> >> BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf
> >> style that it's just a linear buffer.  So the most important code
> >> or assumption wasn't compatible.
> >
> > BPF can deal with linear buffer just fine.  For example, ng_bpf(4)
> > does it.  Please see sys/netgraph/ng_bpf.c.
> >
> >>    - Just making the patch for BPF code, it looked like a trick or
> >> a hack to me because I couldn't define what BPF should be.
> >
> > If you don't want to touch bpf.c for some reason, netgraph(4) (->
> > ng_bpf) may be an alternate solution for you.
> >
> >>    - I could not define BPF exactly myself that what BPF should
> >> cover. I agreed with that BPF is for ethernet packet filtering but
> >> could not make sure myself that BPF could cover USB packets.
> >
> > BPF is a generic packet filter machine, i.e., bytecode is generic
> > enough for any type of data stream.
> 
> I agree that this is the best way forward, if it can be achieved.

Yes it's best.  I think it could be achieved.  I'll make the patch.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [RFC] USBdump patches

[Weongyo Jeong]

On Tue, Nov 23, 2010 at 07:36:47PM -0500, Jung-uk Kim wrote:
> On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote:
> > On Tue, Nov 23, 2010 at 06:52:36PM -0500, Jung-uk Kim wrote:
> > > On Tuesday 23 November 2010 06:31 pm, Jung-uk Kim wrote:
> > > > [CC sanitized]
> > > >
> > > > On Tuesday 23 November 2010 06:01 pm, Hans Petter Selasky wrote:
> > > > > Dear Weongyo,
> > > > >
> > > > > > NACK.  You already could recognize that the patch is quite
> > > > > > big and multiple patches are mixed into one.  Please
> > > > > > separate into smallest pieces then send freebsd-usb@ again.
> > > > > >  I don't want to do a jumbo jump.
> > >
> > > Technically, I don't like the copy-and-pasted code from bpf.c and
> > > bpf_filter.c.  Was it really necessary?  Is the dump file in PCAP
> > > format?
> > >
> > > Please enlighten me if I missed something.
> >
> > The following paragraph is extracted from email I sent to rwatson@
> > because he also asked same question to me.  And I added CC to
> > freebsd-usb@ to share my story with other developers who might
> > think similar.
> >
> >   Hello Roberts,
> >
> >   I understand what you're worry and agree with you that if I could
> > remove this duplication it'd be best one.  I think it could be
> > happen enough later if we could reach the consensus.
> >
> >   The biggest confusions I encountered during implementing?
> > (porting) it for USB packet filter were as follows.  Please let me
> > know if there are something I missed:
> >
> >- BPF was normally for ethernet frames (most operations were
> > based on mbuf including the machine filter and there were a lot of
> > assumptions the input buffer is mbuf type.  For example, handling
> > BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf
> > style that it's just a linear buffer.  So the most important code
> > or assumption wasn't compatible.
> 
> BPF can deal with linear buffer just fine.  For example, ng_bpf(4) 
> does it.  Please see sys/netgraph/ng_bpf.c.
> 
> >- Just making the patch for BPF code, it looked like a trick or
> > a hack to me because I couldn't define what BPF should be.
> 
> If you don't want to touch bpf.c for some reason, netgraph(4) (-> 
> ng_bpf) may be an alternate solution for you.
> 
> >- I could not define BPF exactly myself that what BPF should
> > cover. I agreed with that BPF is for ethernet packet filtering but
> > could not make sure myself that BPF could cover USB packets.
> 
> BPF is a generic packet filter machine, i.e., bytecode is generic 
> enough for any type of data stream.

Oh I see what you mean.   `buflen' was a key variable whether the buffer
is mbuf or linear buffer that I missed it.  You saved my enough time.
:-)

I think we could reduce significant code of USB pf.  And I'll provide a
second patch for this.  Please forgive my ignorance.  Thank you!

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [RFC] USBdump patches

[Weongyo Jeong]

On Tue, Nov 23, 2010 at 06:52:36PM -0500, Jung-uk Kim wrote:
> On Tuesday 23 November 2010 06:31 pm, Jung-uk Kim wrote:
> > [CC sanitized]
> >
> > On Tuesday 23 November 2010 06:01 pm, Hans Petter Selasky wrote:
> > > Dear Weongyo,
> > >
> > > > NACK.  You already could recognize that the patch is quite big
> > > > and multiple patches are mixed into one.  Please separate into
> > > > smallest pieces then send freebsd-usb@ again.  I don't want to
> > > > do a jumbo jump.
> > >
> >
> 
> Technically, I don't like the copy-and-pasted code from bpf.c and 
> bpf_filter.c.  Was it really necessary?  Is the dump file in PCAP 
> format?
> 
> Please enlighten me if I missed something.

The following paragraph is extracted from email I sent to rwatson@
because he also asked same question to me.  And I added CC to 
freebsd-usb@ to share my story with other developers who might think
similar.

  Hello Roberts,

  I understand what you're worry and agree with you that if I could remove
  this duplication it'd be best one.  I think it could be happen enough
  later if we could reach the consensus.

  The biggest confusions I encountered during implementing? (porting) it
  for USB packet filter were as follows.  Please let me know if there are
  something I missed:

   - BPF was normally for ethernet frames (most operations were based on
 mbuf including the machine filter and there were a lot of
 assumptions the input buffer is mbuf type.  For example, handling
 BPF_LD|BPF_W|BPF_ABS).  However the USB packet isn't like mbuf style
 that it's just a linear buffer.  So the most important code or
 assumption wasn't compatible.
   - Just making the patch for BPF code, it looked like a trick or a hack
 to me because I couldn't define what BPF should be.
   - I could not define BPF exactly myself that what BPF should cover.
 I agreed with that BPF is for ethernet packet filtering but could
 not make sure myself that BPF could cover USB packets.

Please tell me your opinion if you guys have better approach.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [RFC] USBdump patches

[Weongyo Jeong]

On Tue, Nov 23, 2010 at 11:19:33PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> Please find attached official usbdump patch from HPS trying to re-use as much 
> as possible of Weongyo's code which was committed not long ago. You need to 
> SVN up to the latest 9-current.
> 
> This patch should fix all USB-dump issues reported so far!
> 
> 1) Fix for proper offset calculation on ISOCHRONOUS reception.
> 2) Fixes for device mode.
> 3) PF-virtual-machine is OK (and done before copy of data).
> 4) Can load and unload the PF-code like a module.
> 
> How to use:
> 
> cd /usr/src
> cat usbdump_r215656_patch.txt | patch
> 
> You need to make new kernel, but not userland.
> 
> Install sys/dev/usb/usb_pf.h into /usr/include/dev/usb/ and make all install 
> in src/usr.sbin/usbdump .
> 
> After reboot:
> 
> kldload usb_pf
> 
> usbdump -d -1 -vvv
> 
> man usbdump

NACK.  You already could recognize that the patch is quite big and
multiple patches are mixed into one.  Please separate into smallest
pieces then send freebsd-usb@ again.  I don't want to do a jumbo jump.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [RFC] Outline of USB process integration in the kernel taskqueue system

[Weongyo Jeong]

On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> In the patch attached to this e-mail I included Matthew Fleming's patch 
> aswell.
> 
> 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles 
> the words of the callout and USB API's terminology for doing the same.
> 
> 2) I turns out I need to have code in subr_taskqueue.c to be able to make the 
> operations atomic.
> 
> 3) I did not update the manpage in this patch. Will do that before a commit.
> 
> 4) My patch implements separate state keeping in "struct task_pair", which 
> avoids having to change any KPI's for now, like suggested by John Baldwin I 
> think.
> 
> 5) In my implementation I hard-coded the priority argument to zero, so that 
> enqueuing is fast.
> 
> Comments are welcome!

The patch looks almost you moved usb_process.c code into taskqueue(9)
that I means it still follows that a entry which enqueued at last should
be executed at last.  It seems that at least it's not a general for
taskqueue(9).   In my humble opinion it looks a trick.  I think it'd
better to find a general solution to solve it though I used sx(9) lock
in my patches.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [CFR] add usb_sleepout.[ch]

[Weongyo Jeong]

On Mon, Nov 01, 2010 at 09:10:43AM +0100, Hans Petter Selasky wrote:
> On Monday 01 November 2010 03:03:48 Weongyo Jeong wrote:
> > On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote:
> > > On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote:
> > > > Hello USB guys,
> > > 
> > > 1) All the sleepout_xxx() functions need mutex asserts.
> > 
> 
> Hi,
> 
> > It looks it don't need it because callout(9) does it instead of sleepout
> > routines.  Moreover sleepout don't create any mutexes in itself.
> 
> Ok.
> 
> > 
> > > 2) Is it allowed to call callout_stop() / callout_reset() unlocked at
> > > all?
> > 
> > Yes as long as it doesn't have side effects.  It seems no drivers hold a
> > lock to call callout_stop() / callout_reset().
> 
> All USB drivers do to ensure state coherency.
> 
> > 
> > > What are the concequences if the mutex associated with the sleepout is
> > > NULL ?
> > 
> > I added KASSERT macro to check this case at below.  However the sleepout
> > pointer normally never be NULL because the intention of usage was as
> > follows:
> > 
> >   struct _softc {
> >   struct sleepout sleepout;
> >   struct sleepout_task sleepout_task;
> >   };
> > 
> >   sleepout_create(&sc->sleepout, "blah");
> > 
> > Only it could be happen if `struct sleepout' is allocated by
> > dynamically though it's not my first purpose.
> > 
> > > 3) As per the current implementation it can happen that the task'ed
> > > timeout is called after that sleepout_stop() is used. The code should
> > > have a check in the task function to see if the sleepout() has been
> > > cancelled or not, when the mutex associated with the sleepout is locked.
> > 
> > Yes it's true but it'd better to implement first taskqueue_stop() than
> > adding it sleepout routines directly.  However no plans yet because I
> > couldn't imagine a side effect due to lack of this feature.  Please let
> > me know if I missed the something important.
> 
> Maybe not when you are implementing a watchdog timer for ethernet, but then 
> you are limiting the use of those functions to USB ethernet only. The problem 
> happens when you are updating a state-machine in the callback and cannot 
> trust 
> that a stop cancelled the sleepout. All existing USB functions are written 
> this way. I.E. no completion done callback after usbd_transfer_stop().
> 
> For example if your watchdog is calling if_start() somehow, and then you do 
> an 
> if_down() which stops the watchdog, and then you can end up triggering the 
> if_start() after if_down(), which is incorrect.

OK that it makes sense to me.  I'll try to make a patch, taskqueue_stop().

> > > 4) Should the functions be prefixed by usb_ ?
> > 
> > I don't have a preference for this.  I think it's no problem to change
> > it.  It could happen soon.
> > 
> > > 5) In drain you should drain the callout first, then drain the tasqueue.
> > > Else the timer can trigger after the taskqueue is drained.
> 
> Have you considered using the USB sub-systems taskqueue, instead of the 
> kernel 
> one, so that jobs can be serialised among the two? Else you end up 
> introducing 
> SX-locks in all drivers? Is that on purpose?

As mentioned at the previous email.  I prefer to use SX lock than
taskqueue.  Please refer my email which sent just minutes ago.

> > It's fixed.  Thank you for your review and the updated version is
> > embedded at this email.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [CFR 2-3/n] removes uther dependency of axe(4)

[Weongyo Jeong]

On Mon, Nov 01, 2010 at 09:30:25AM +0100, Hans Petter Selasky wrote:
> On Sunday 31 October 2010 23:43:04 Weongyo Jeong wrote:
> > +static void
> > +axe_watchdog(void *arg)
> > +{
> > +   struct axe_softc *sc = arg;
> > +   struct ifnet *ifp = sc->sc_ifp;
> > +
> > +   if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
> > +   return;
> > +
> 
> Hi,
> 
> Please explain what is wrong with the existing code regarding code 
> synchronisation. Your patch is very big and is likely to introduce problems.

Hello Hans,

I think your approach to synchronize the multiple tasks isn't bad though
the implementation of approach isn't familiar with me comparing the
other task queue implementations.  It seems to me that it's a customized
task queue implementation only for USB subsystem.

> I oppose the introduction of SX-locks. Please explain why you think SX-locks 
> are better than the USB process taskqueue.

I'd like to say that I also don't like SX locks that the reason is
mentioned at CONTEXT section of sx(9) man page.

I think using SX lock and the USB process taskqueue are both bad that if
I could avoid using it, I'll willing to avoid it to use it.  But the
problem is that it's inevitable.  I think we could choice one of two
approaches that one is using SX lock other is using USB process
taskqueue.  The result of both would same, serialization.

Regarding to the approach there'll be pros and cons:

  Pros of using SX lock:
- Don't need to create extra thread.
- Simple to read.  Other developers could catch writer's intention
  easily.

  Cons of using SX lock:
- Unexpecting sleep with holding mutex according to CONTEXT section
  of sx(9) man page.  It should be used carefully.
- Adds another lock to the driver.

  Pros of using USB process taksqueue:
- Please fill.

  Cons of using USB process taskqueue:
- No atomic operation that it need to be drained explicitly with
  sleeping that adds extra quirk code.
- Tasks would be merged into one if the task is enqueued multiple
  times during pending that it means the writer takes care extra
  exceptions.  It could lead to unexpected device behavior depending
  on device characteristics.
- At least two threads are involved.  One is caller thread other
  would be worker thread (USB process).  It makes weak to race
  conditions.  It always make code complex.

> Are you absolutely sure that all the IOCTL's that are called are allowed to 
> block in the way you have programmed?

Of course not because I'm a human.  Human always do a mistake.  :-)  But
there are few cases which need to be atomic in USB devices.  For
example, device up and down.  It means sx(9) lock would be used very
limited places only.

> The checks in xxx_watchdog() are not good enough. axe_tick() will execute 
> synchronous USB functions, which sleep for many hundreds of microseconds. You 
> should add this check before the sleepout_reset() too, and is this code 
> called 
> with any lock locked? I.E. Are you doing the clearing of IFF_DRV_RUNNING 
> atomic to testing this flag? Else the result can be random?

Maybe xxx_watchdog() would be called with holding the driver lock so
at least ifp->if_drv_flags would be protected.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: [CFR] add usb_sleepout.[ch]

[Weongyo Jeong]

On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote:
> On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote:
> > Hello USB guys,
> > 
> > The following patch is to add a implementation, called `sleepout'.
> > Please reviews.  I'd like to commit it into HEAD if no objections.
> > 
> >   Adds `sleepout' prototype which is a comic combination of callout(9) and
> >   taskqueue(8) only for USB drivers to implement one step timer.  In
> >   current USB drivers using callout(9) interface they all have two step
> >   execution flow as follows:
> > 
> > 1. callout callback is fired by the interrupt context.  Then it needs
> >to pass it to USB process context because it could sleep(!) while
> >callout(9) don't allow it.
> > 2. In the USB process context it operates USB commands that most of
> >times it'd be blocked at least 125 us (it'd be always true for USB)
> > 
> >   In a view of driver developer it'd be more convenient if USB stack has a
> >   feature like this (timer supporting blocking).
> > 
> 
> Hi,
> 
> I think this is a good idea too.
> 
> However, there are some atomic issues I think you need to fix first.
> 
> 1) All the sleepout_xxx() functions need mutex asserts.

It looks it don't need it because callout(9) does it instead of sleepout
routines.  Moreover sleepout don't create any mutexes in itself.

> 2) Is it allowed to call callout_stop() / callout_reset() unlocked at all? 

Yes as long as it doesn't have side effects.  It seems no drivers hold a
lock to call callout_stop() / callout_reset().

> What are the concequences if the mutex associated with the sleepout is NULL ?

I added KASSERT macro to check this case at below.  However the sleepout
pointer normally never be NULL because the intention of usage was as
follows:

  struct _softc {
  struct sleepout sleepout;
  struct sleepout_task sleepout_task;
  };

  sleepout_create(&sc->sleepout, "blah");

Only it could be happen if `struct sleepout' is allocated by
dynamically though it's not my first purpose.

> 3) As per the current implementation it can happen that the task'ed timeout 
> is 
> called after that sleepout_stop() is used. The code should have a check in 
> the 
> task function to see if the sleepout() has been cancelled or not, when the 
> mutex associated with the sleepout is locked.

Yes it's true but it'd better to implement first taskqueue_stop() than
adding it sleepout routines directly.  However no plans yet because I
couldn't imagine a side effect due to lack of this feature.  Please let
me know if I missed the something important.

> 4) Should the functions be prefixed by usb_ ?

I don't have a preference for this.  I think it's no problem to change
it.  It could happen soon.

> 5) In drain you should drain the callout first, then drain the tasqueue. Else 
> the timer can trigger after the taskqueue is drained.

It's fixed.  Thank you for your review and the updated version is
embedded at this email.

regards,
Weongyo Jeong

Index: usb_sleepout.c
===
--- usb_sleepout.c  (revision 0)
+++ usb_sleepout.c  (revision 0)
@@ -0,0 +1,149 @@
+/*-
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+void
+sleepout_create(struct sleepout *s, const char *name)
+{
+
+   KASSERT(s != NULL, ("sleepout ptr is NULL"));
+
+   s->s_taskqueue = taskqueue_create(name, M_WAITOK,
+   taskqueue_thread_enqueue, &s->s_taskqueue);
+   /* XXX adjusts the priority. */
+   taskqueue_start_threads(&s->s_taskqueue, 1, PI_NET, "%s sleepout",
+   name);
+}
+
+void
+sleepout_free(struct sleepout *s)
+{
+
+   KASSERT(s != NULL, ("sleepout ptr is NULL"));
+
+   taskqueue_free(s->s_taskqueue);
+}
+
+static void
+_sleepout_taskqueue_callback

[CFR 4/n] removes uether dependency of cdce(4)

[Weongyo Jeong]

Hello,

This patch is to remove a uether dependency of cdce(4) and some style(9)
changes.  The change logs would be as follows:

  o removes uether dependency.
  o defines CDCE_DEV to clean up the supported device list.
  o uses bzero instead of memset.
  o style(9) - get rid of extra spaces and parentheses.

Please reviews.

regards,
Weongyo Jeong

Index: if_cdce.c
===
--- if_cdce.c   (revision 214604)
+++ if_cdce.c   (working copy)
@@ -61,6 +61,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -68,6 +70,14 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -77,6 +87,7 @@ __FBSDID("$FreeBSD$");
 #defineUSB_DEBUG_VAR cdce_debug
 #include 
 #include 
+#include 
 #include "usb_if.h"
 
 #include 
@@ -99,14 +110,16 @@ static usb_callback_t cdce_ncm_bulk_write_callback
 static usb_callback_t cdce_ncm_bulk_read_callback;
 #endif
 
-static uether_fn_t cdce_attach_post;
-static uether_fn_t cdce_init;
-static uether_fn_t cdce_stop;
-static uether_fn_t cdce_start;
-static uether_fn_t cdce_setmulti;
-static uether_fn_t cdce_setpromisc;
-
 static uint32_tcdce_m_crc32(struct mbuf *, uint32_t, uint32_t);
+static int cdce_ioctl(struct ifnet *, u_long, caddr_t);
+static voidcdce_start(struct ifnet *);
+static voidcdce_start_locked(struct ifnet *);
+static voidcdce_init(void *);
+static voidcdce_init_locked(struct cdce_softc *);
+static voidcdce_stop_locked(struct cdce_softc *);
+static int cdce_rxmbuf(struct cdce_softc *, struct mbuf *, unsigned int);
+static struct mbuf *cdce_newbuf(void);
+static voidcdce_rxflush(struct cdce_softc *);
 
 #ifdef USB_DEBUG
 static int cdce_debug = 0;
@@ -120,7 +133,6 @@ SYSCTL_INT(_hw_usb_cdce, OID_AUTO, interval, CTLFL
 #endif
 
 static const struct usb_config cdce_config[CDCE_N_TRANSFER] = {
-
[CDCE_BULK_RX] = {
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
@@ -174,7 +186,6 @@ static const struct usb_config cdce_config[CDCE_N_
 
 #if CDCE_HAVE_NCM
 static const struct usb_config cdce_ncm_config[CDCE_N_TRANSFER] = {
-
[CDCE_BULK_RX] = {
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
@@ -255,29 +266,21 @@ MODULE_DEPEND(cdce, uether, 1, 1, 1);
 MODULE_DEPEND(cdce, usb, 1, 1, 1);
 MODULE_DEPEND(cdce, ether, 1, 1, 1);
 
-static const struct usb_ether_methods cdce_ue_methods = {
-   .ue_attach_post = cdce_attach_post,
-   .ue_start = cdce_start,
-   .ue_init = cdce_init,
-   .ue_stop = cdce_stop,
-   .ue_setmulti = cdce_setmulti,
-   .ue_setpromisc = cdce_setpromisc,
-};
-
 static const struct usb_device_id cdce_devs[] = {
-   {USB_VPI(USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632, 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250, 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX, 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00, 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN, 
CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2, 
CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_NETCHIP, USB_PRODUCT_NETCHIP_ETHERNETGADGET, 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501, 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500, CDCE_FLAG_ZAURUS)},
-   {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600, CDCE_FLAG_ZAURUS | 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLA300, CDCE_FLAG_ZAURUS | 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC700, CDCE_FLAG_ZAURUS | 
CDCE_FLAG_NO_UNION)},
-   {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC750, CDCE_FLAG_ZAURUS | 
CDCE_FLAG_NO_UNION)},
+#defineCDCE_DEV(v,p,i) { USB_VPI(USB_VENDOR_##v, 
USB_PRODUCT_##v##_##p, i) }
+   CDCE_DEV(ACERLABS, M5632, CDCE_FLAG_NO_UNION),
+   CDCE_DEV(AMBIT, NTL_250, CDCE_FLAG_NO_UNION),
+   CDCE_DEV(COMPAQ, IPAQLINUX, CDCE_FLAG_NO_UNION),
+   CDCE_DEV(GMATE, YP3X00, CDCE_FLAG_NO_UNION),
+   CDCE_DEV(MOTOROLA2, USBLAN, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION),
+   CDCE_DEV(MOTOROLA2, USBLAN2, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION),
+   CDCE_DEV(NETCHIP, ETHERNETGADGET, CDCE_FLAG_NO_UNION),
+   CDCE_DEV(PROLIFIC, PL2501, CDCE_FLAG_NO_UNION),
+   CDCE_DEV(SHARP, SL5500, CDCE_FLAG_ZAURUS),
+   CDCE_DEV(SHARP, SL5600, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION),
+   CDCE_DEV(SHARP, SLA300, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION),
+   CDCE_DEV(SHARP, SLC700, CDCE_FLAG_ZAURUS | CDCE_FLAG_N

[CFR 3/n] removes uther dependency of axe(4)

[Weongyo Jeong]

Hello,

As one of patch series it's for patching axe(4) without dependency of
uether module.  The change log would be almost same like the previous
patch log.

regards,
Weongyo Jeong

Index: if_axereg.h
===
--- if_axereg.h (revision 214604)
+++ if_axereg.h (working copy)
@@ -185,7 +185,7 @@ struct axe_sframe_hdr {
uint16_t ilen;
 } __packed;
 
-#defineGET_MII(sc) uether_getmii(&(sc)->sc_ue)
+#defineGET_MII(sc) (device_get_softc(sc->sc_miibus))
 
 /* The interrupt endpoint is currently unused by the ASIX part. */
 enum {
@@ -195,20 +195,35 @@ enum {
 };
 
 struct axe_softc {
-   struct usb_ethersc_ue;
+   struct ifnet*sc_ifp;
+   device_tsc_dev;
+   device_tsc_miibus;
+   struct usb_device   *sc_udev; /* used by uether_do_request() */
struct mtx  sc_mtx;
-   struct usb_xfer *sc_xfer[AXE_N_TRANSFER];
+   struct sx   sc_sx;
+   struct usb_xfer *sc_xfer[AXE_N_TRANSFER];
+
+   /* ethernet address from eeprom */
+   uint8_t sc_eaddr[ETHER_ADDR_LEN];
+   struct ifqueue  sc_rxq;
+
+   struct sleepout sc_sleepout;
+   struct sleepout_tasksc_watchdog;
+   struct task sc_setmulti;
+   struct task sc_setpromisc;
+
+   int sc_unit;
int sc_phyno;
-
int sc_flags;
 #defineAXE_FLAG_LINK   0x0001
 #defineAXE_FLAG_7720x1000  /* AX88772 */
 #defineAXE_FLAG_1780x2000  /* AX88178 */
-
uint8_t sc_ipgs[3];
uint8_t sc_phyaddrs[2];
 };
 
+#defineAXE_SXLOCK(_sc) sx_xlock(&(_sc)->sc_sx)
+#defineAXE_SXUNLOCK(_sc)   sx_xunlock(&(_sc)->sc_sx)
 #defineAXE_LOCK(_sc)   mtx_lock(&(_sc)->sc_mtx)
 #defineAXE_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx)
 #defineAXE_LOCK_ASSERT(_sc, t) mtx_assert(&(_sc)->sc_mtx, t)
Index: if_axe.c
===
--- if_axe.c(revision 214604)
+++ if_axe.c(working copy)
@@ -89,6 +89,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -96,6 +98,19 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "miibus_if.h"
+
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -104,6 +119,7 @@ __FBSDID("$FreeBSD$");
 #defineUSB_DEBUG_VAR axe_debug
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -178,23 +194,26 @@ static miibus_readreg_t axe_miibus_readreg;
 static miibus_writereg_t axe_miibus_writereg;
 static miibus_statchg_t axe_miibus_statchg;
 
-static uether_fn_t axe_attach_post;
-static uether_fn_t axe_init;
-static uether_fn_t axe_stop;
-static uether_fn_t axe_start;
-static uether_fn_t axe_tick;
-static uether_fn_t axe_setmulti;
-static uether_fn_t axe_setpromisc;
-
 static int axe_ifmedia_upd(struct ifnet *);
 static voidaxe_ifmedia_sts(struct ifnet *, struct ifmediareq *);
 static int axe_cmd(struct axe_softc *, int, int, int, void *);
 static voidaxe_ax88178_init(struct axe_softc *);
 static voidaxe_ax88772_init(struct axe_softc *);
 static int axe_get_phyno(struct axe_softc *, int);
+static voidaxe_watchdog(void *);
+static voidaxe_init(void *);
+static voidaxe_init_locked(struct axe_softc *);
+static int axe_ioctl(struct ifnet *, u_long, caddr_t);
+static voidaxe_start(struct ifnet *);
+static voidaxe_start_locked(struct ifnet *);
+static voidaxe_tick(struct axe_softc *);
+static voidaxe_stop(struct axe_softc *);
+static voidaxe_stop_locked(struct axe_softc *);
+static voidaxe_setmulti_locked(struct axe_softc *);
+static voidaxe_setpromisc(void *, int);
+static voidaxe_setpromisc_locked(struct axe_softc *);
 
 static const struct usb_config axe_config[AXE_N_TRANSFER] = {
-
[AXE_BULK_DT_WR] = {
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
@@ -250,18 +269,14 @@ MODULE_DEPEND(axe, ether, 1, 1, 1);
 MODULE_DEPEND(axe, miibus, 1, 1, 1);
 MODULE_VERSION(axe, 1);
 
-static const struct usb_ether_methods axe_ue_methods = {
-   .ue_attach_post = axe_attach_post,
-   .ue_start = axe_start,
-   .ue_init = axe_init,
-   .ue_stop = axe_stop,
-   .ue_tick = axe_tick,
-   .ue_setmulti = axe_setmulti,
-   .ue_setpromisc = axe_setpromisc,
-   .ue_mii_upd = axe_ifmedia_upd,
-   .ue_mii_sts = axe_ifmedia_sts,
-};
+static uint8_t
+axe_pause(struct axe_softc *sc, unsigned int _ticks)
+{
 
+ 

[CFR 2/n] removes uther dependency of aue(4)

[Weongyo Jeong]

Hello,

The following patch is to remove uether(4) dependency of aue(4) and
change logs would be as follows:

  - removes uether module dependency of aue(4) that finally uether
module would be gone.  The reasons why I'm trying to remove uether
module are that
  I discussed with USB ethernet maintainers about whether it's
  useful or not.  yongari@ answered that it's not helpful, not
  straight forward to understand and make code complex.
  - adds newly two uether APIs, uether_alloc_unr and uether_free_unr for
backward compatibility because current interface names for each
ethernet devices are linux-style `ue[0-9]+'.  The naming rule would
be kept at STABLE_8 but not sure at STABLE_9.

If no objections I'd like to see this patch at HEAD.

regards,
Weongyo Jeong

Index: usb_ethernet.c
===
--- usb_ethernet.c  (revision 214568)
+++ usb_ethernet.c  (working copy)
@@ -597,5 +597,19 @@ uether_rxflush(struct usb_ether *ue)
}
 }
 
+int
+uether_alloc_unr(void)
+{
+
+   return (alloc_unr(ueunit));
+}
+
+void
+uether_free_unr(int unit)
+{
+
+   free_unr(ueunit, unit);
+}
+
 DECLARE_MODULE(uether, uether_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);
 MODULE_VERSION(uether, 1);
Index: if_aue.c
===
--- if_aue.c(revision 214568)
+++ if_aue.c(working copy)
@@ -81,6 +81,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -88,6 +90,19 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "miibus_if.h"
+
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -96,6 +111,7 @@ __FBSDID("$FreeBSD$");
 #defineUSB_DEBUG_VAR aue_debug
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -197,14 +213,6 @@ static usb_callback_t aue_intr_callback;
 static usb_callback_t aue_bulk_read_callback;
 static usb_callback_t aue_bulk_write_callback;
 
-static uether_fn_t aue_attach_post;
-static uether_fn_t aue_init;
-static uether_fn_t aue_stop;
-static uether_fn_t aue_start;
-static uether_fn_t aue_tick;
-static uether_fn_t aue_setmulti;
-static uether_fn_t aue_setpromisc;
-
 static uint8_t aue_csr_read_1(struct aue_softc *, uint16_t);
 static uint16_taue_csr_read_2(struct aue_softc *, uint16_t);
 static voidaue_csr_write_1(struct aue_softc *, uint16_t, uint8_t);
@@ -217,6 +225,20 @@ static voidaue_reset_pegasus_II(struct aue_softc
 
 static int aue_ifmedia_upd(struct ifnet *);
 static voidaue_ifmedia_sts(struct ifnet *, struct ifmediareq *);
+static int aue_ioctl(struct ifnet *, u_long, caddr_t);
+static voidaue_start(struct ifnet *);
+static voidaue_start_locked(struct ifnet *);
+static voidaue_init(void *);
+static voidaue_stop_locked(struct aue_softc *);
+static voidaue_setmulti(void *, int);
+static voidaue_setmulti_locked(struct aue_softc *);
+static voidaue_rxflush(struct aue_softc *);
+static int aue_rxbuf(struct aue_softc *, struct usb_page_cache *, 
+   unsigned int, unsigned int);
+static voidaue_setpromisc(void *, int);
+static voidaue_setpromisc_locked(struct aue_softc *);
+static voidaue_init_locked(struct aue_softc *);
+static voidaue_watchdog(void *);
 
 static const struct usb_config aue_config[AUE_N_TRANSFER] = {
 
@@ -283,24 +305,19 @@ MODULE_DEPEND(aue, ether, 1, 1, 1);
 MODULE_DEPEND(aue, miibus, 1, 1, 1);
 MODULE_VERSION(aue, 1);
 
-static const struct usb_ether_methods aue_ue_methods = {
-   .ue_attach_post = aue_attach_post,
-   .ue_start = aue_start,
-   .ue_init = aue_init,
-   .ue_stop = aue_stop,
-   .ue_tick = aue_tick,
-   .ue_setmulti = aue_setmulti,
-   .ue_setpromisc = aue_setpromisc,
-   .ue_mii_upd = aue_ifmedia_upd,
-   .ue_mii_sts = aue_ifmedia_sts,
-};
-
 #defineAUE_SETBIT(sc, reg, x) \
aue_csr_write_1(sc, reg, aue_csr_read_1(sc, reg) | (x))
 
 #defineAUE_CLRBIT(sc, reg, x) \
aue_csr_write_1(sc, reg, aue_csr_read_1(sc, reg) & ~(x))
 
+static void
+aue_pause(struct aue_softc *sc, unsigned int _ticks)
+{
+
+   usb_pause_mtx(&sc->sc_mtx, _ticks);
+}
+
 static uint8_t
 aue_csr_read_1(struct aue_softc *sc, uint16_t reg)
 {
@@ -314,7 +331,8 @@ aue_csr_read_1(struct aue_softc *sc, uint16_t reg)
USETW(req.wIndex, reg);
USETW(req.wLength, 1);
 
-   err = uether_do_request(&sc->sc_ue, &req, &val, 1000);
+   err = usbd_do_request_flags(sc->sc_udev, &sc->sc_mtx, &req, &val, 0,
+   NULL, 1000);
if (err)
return (0);
return (val);
@@ -333,7 +351,8 @@ aue_csr_read_2(struct aue_softc *sc, uint16_t reg)
USETW(req.wIndex, reg)

[CFR] add usb_sleepout.[ch]

[Weongyo Jeong]

Hello USB guys,

The following patch is to add a implementation, called `sleepout'.
Please reviews.  I'd like to commit it into HEAD if no objections.

  Adds `sleepout' prototype which is a comic combination of callout(9) and
  taskqueue(8) only for USB drivers to implement one step timer.  In
  current USB drivers using callout(9) interface they all have two step
  execution flow as follows:

1. callout callback is fired by the interrupt context.  Then it needs
   to pass it to USB process context because it could sleep(!) while
   callout(9) don't allow it.
2. In the USB process context it operates USB commands that most of
   times it'd be blocked at least 125 us (it'd be always true for USB)

  In a view of driver developer it'd be more convenient if USB stack has a
  feature like this (timer supporting blocking).

regards,
Weongyo Jeong

Index: usb_sleepout.c
===
--- usb_sleepout.c  (revision 0)
+++ usb_sleepout.c  (revision 0)
@@ -0,0 +1,122 @@
+/*-
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+void
+sleepout_create(struct sleepout *s, const char *name)
+{
+
+   s->s_taskqueue = taskqueue_create(name, M_WAITOK,
+   taskqueue_thread_enqueue, &s->s_taskqueue);
+   /* XXX adjusts the priority. */
+   taskqueue_start_threads(&s->s_taskqueue, 1, PI_NET, "%s sleepout",
+   name);
+}
+
+void
+sleepout_free(struct sleepout *s)
+{
+
+   taskqueue_free(s->s_taskqueue);
+}
+
+static void
+_sleepout_taskqueue_callback(void *arg, int pending)
+{
+   struct sleepout_task *st = arg;
+
+   (void)pending;
+
+   if (st->st_mtx != NULL)
+   mtx_lock(st->st_mtx);
+
+   st->st_func(st->st_arg);
+
+   if (st->st_mtx != NULL)
+   mtx_unlock(st->st_mtx);
+}
+
+void
+sleepout_init(struct sleepout *s, struct sleepout_task *st, int mpsafe)
+{
+
+   st->st_sleepout = s;
+   callout_init(&st->st_callout, mpsafe);
+   TASK_INIT(&st->st_task, 0, _sleepout_taskqueue_callback, st);
+   st->st_mtx = NULL;
+}
+
+void
+sleepout_init_mtx(struct sleepout *s, struct sleepout_task *st, struct mtx 
*mtx,
+int flags)
+{
+
+   st->st_sleepout = s;
+   callout_init_mtx(&st->st_callout, mtx, flags);
+   TASK_INIT(&st->st_task, 0, _sleepout_taskqueue_callback, st);
+   st->st_mtx = mtx;
+}
+
+static void
+_sleepout_callout_callback(void *arg)
+{
+   struct sleepout_task *st = arg;
+   struct sleepout *s = st->st_sleepout;
+
+   taskqueue_enqueue(s->s_taskqueue, &st->st_task);
+}
+
+int
+sleepout_reset(struct sleepout_task *st, int to_ticks, sleepout_func_t ftn,
+void *arg)
+{
+
+   st->st_func = ftn;
+   st->st_arg = arg;
+   return (callout_reset(&st->st_callout, to_ticks,
+   _sleepout_callout_callback, st));
+}
+
+int
+sleepout_pending(struct sleepout_task *st)
+{
+
+   return (callout_pending(&st->st_callout));
+}
+
+int
+sleepout_stop(struct sleepout_task *st)
+{
+
+   return (callout_stop(&st->st_callout));
+}
+
+int
+sleepout_drain(struct sleepout_task *st)
+{
+   struct sleepout *s = st->st_sleepout;
+
+   taskqueue_drain(s->s_taskqueue, &st->st_task);
+   return (callout_drain(&st->st_callout));
+}

Property changes on: usb_sleepout.c
___
Added: svn:mime-type
   + text/plain
Added: svn:keywords
   + Id
Added: svn:eol-style
   + native

Index: usb_sleepout.h
===
--- usb_sleepout.h  (revision 0)
+++ usb_sleepout.h  (revision 0)
@@ -0,0 +1,53 @@
+/*-
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRA

Re: USB_ERR_TIMEOUT and USB_ERR_STALLED

[Weongyo Jeong]

On Mon, Oct 25, 2010 at 10:16:00AM +0400, Boris Samorodov wrote:
> On Sat, 23 Oct 2010 16:49:59 -0700 Weongyo Jeong wrote:
> > On Thu, Oct 21, 2010 at 10:56:12PM +0200, Hans Petter Selasky wrote:
> > > 
> > > Weongyo is working on a usbdump utility to monitor ongoing USB traffic.
> 
> > It's merged into HEAD not too lately. :-)

It'll be 

Fixes a typo.  Sorry for confusing.

regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB_ERR_TIMEOUT and USB_ERR_STALLED

[Weongyo Jeong]

On Thu, Oct 21, 2010 at 10:56:12PM +0200, Hans Petter Selasky wrote:
> On Thursday 21 October 2010 17:02:30 Mike Tancsa wrote:
> > I am trying to use RELENG_8 to monitor a number of APC upses and it
> > seems when there are more than one, I start to see a lot of USB
> > errors with the devices "coming and going"
> > 
> > In the logs, I see a lot of
> > 
> > 
> > # grep USB /var/log/all.log  | tail
> > Oct 21 10:24:05 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:25:47 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:27:45 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:29:44 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:30:35 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub5
> > Oct 21 10:32:35 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:37:04 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:38:38 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub4
> > Oct 21 10:44:14 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub5
> > Oct 21 10:45:09 upsmon1 root: Unknown USB device: vendor 0x051d
> > product 0x0002 bus uhub5
> > 
> > 
> > 
> > # usbconfig
> > ugen0.1:  at usbus0, cfg=0 md=HOST spd=FULL
> > (12Mbps) pwr=ON
> > ugen1.1:  at usbus1, cfg=0 md=HOST spd=FULL
> > (12Mbps) pwr=ON
> > ugen2.1:  at usbus2, cfg=0 md=HOST spd=FULL
> > (12Mbps) pwr=ON
> > ugen3.1:  at usbus3, cfg=0 md=HOST spd=HIGH
> > (480Mbps) pwr=ON
> > ugen3.2:  at usbus3, cfg=0 md=HOST
> > spd=HIGH (480Mbps) pwr=SAVE
> > ugen0.2:  > Conversion> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.3:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.4:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.5:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.6:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.7:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.8:  at usbus3, cfg=0 md=HOST spd=HIGH
> > (480Mbps) pwr=SAVE
> > ugen3.9:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.10:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > ugen3.11:  > Conversion> at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
> > 
> > 
> > This is with a kernel from Oct 4th, i386.  Any idea what might be up
> > or how to debug this ??  Setting
> > hw.usb.debug to anything > 0 causes the system to almost hang under
> > the load unfortunately.
> > 
> >  ---Mike
> 
> Weongyo is working on a usbdump utility to monitor ongoing USB traffic.

It's merged into HEAD not too lately. :-)

regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

q: a trivial question of usb2_transfer_unsetup()

[Weongyo Jeong]

Hello Hans,

I have a simple question that is there a possibility for .mh.callback of
usb2_config to be called after usb2_transfer_unsetup()?

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: q: Memory modified after free in usb2

[Weongyo Jeong]

On Thu, Mar 26, 2009 at 09:02:02AM +0100, Hans Petter Selasky wrote:
> On Thursday 26 March 2009, Weongyo Jeong wrote:
> > On Wed, Mar 25, 2009 at 10:46:54AM +0100, Hans Petter Selasky wrote:
> 
> > > > To solve this problem I modified codes slightly like below:
> > > >
> > > >   usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
> > > >   usb2_pause_mtx(NULL, 5 * hz);
> > > >   ...
> > > >   uath_free_rx_data_list(sc);
> > > >   uath_free_tx_data_list(sc);
> > > >   uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);
> > > >
> > > > After adding it I couldn't see `Memory modified after free' messages
> > > > anymore.  My question is that I can't understand why adding
> > > > usb2_pause_mtx() helps this symptom?
> > >
> > > Did you drain all the taskqueues before unsetup ?
> >
> > Yes.  All I used was two callouts that the driver currently doesn't use
> > usb2_proc_create() and tried to drain its before calling
> > usb2_transfer_unsetup() but it still encounters `Memory modified after
> > free'.
> 
> Hi,
> 
> Is this the link to the complete code?
> 
> http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/weongyo/wireless/src/sys/dev/usb/wlan/if_uath.c&REV=24

Yes. 

> 1) The manpage states: "This function MUST NOT be called while holding any 
> locks ..."
>   |UATH_LOCK(sc);
>   |callout_drain(&sc->stat_ch);
>   |callout_drain(&sc->watchdog_ch);
> 505: 159831 21 |UATH_UNLOCK(sc);
> 
> 
> callout_stop() is not callout_drain() !
> 
> Same sematics with USB2. transfer_stop()/transfer_drain()

It looks it's my mistake to lock before going into callout_drain(9).

> 2) Instead of copying the data twice, use the .ext_buffer=1 flag to instruct 
> USB to not allocate its own buffer in "struct usb2_config", see "umass.c" for 
> example, and the  and 
> usb2_set_frame_data(xfer,
> urb->transfer_buffer, 0);
> 
> Before you start the hardware!
> 
> Actually you can save alot of copying if you can exploit the multi-frame 
> feature of the USB-stack for BULK transfers! Then you have to set "frames > 
> 1" in usb2_config structure. For example you would then copy in the header to 
> wMaxPacketSize bytes, and use the data pointer for the rest, given that the 
> IP-packet is not that defragged.

This is what I want!  I'll apply it immediately.  Thanks! :-)

> 3) There is a chicken egg problem at detach.
> 
> I suspect that "uath_bulk_tx_callback()" is called with the USB_ERR_CANCELLED 
> error. And here you seem to access freed memory. I think you need to re-think 
> how you get that last node freed. Maybe it should be done by the if_stop() 
> and not at cancelled, because according to detach, you will do if_stop() 
> first and then cancel USB and unless you drain, you are not certain that the 
> callback is complete!
> 
>   |default:
>|data = STAILQ_FIRST(&sc->sc_datatx_active);
>|if (data == NULL)
>|goto setup;
> 2605: 159735  3 |if (data->ni != NULL) {
>|ieee80211_free_node(data->ni);
>|data->ni = NULL;
>|ifp->if_oerrors++;
>|}
> 2610: 159733  1 |if (xfer->error != USB_ERR_CANCELLED) {
>|xfer->flags.stall_pipe = 1;
>|goto setup;
>|}
> 
> I recommend that you do the usb2_transfer_unsetup() first at detach like in 
> if_rum.c and the other WLAN drivers. That will solve your problem, and maybe 
> you have to fix the datatx_active queue, so that the last "data" is not stuck 
> there for ever ???

Thank you for advice again.  I'll try to do some more tests.  It looks
ordering is important when detaching and with looking other WLAN drivers
it seems calling ieee80211_ifdetach(ic) should be moved before
usb2_transfer_unsetup(9) including if_zyd.c, if_ural.c and if_ral.c

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: q: Memory modified after free in usb2

[Weongyo Jeong]

On Wed, Mar 25, 2009 at 10:46:54AM +0100, Hans Petter Selasky wrote:
> On Wednesday 25 March 2009, Weongyo Jeong wrote:
> > Hello Hans :),
> >
> > I think porting uath(4) to usb almost have done that it works well to
> > associate with AP and for WPA but I'm suffered from a strange panic after
> > detach as follows:
> >
> >   Memory modified after free 0xc4da3600(508) val=2400 @ 0xc4da3600
> >   panic: Most recently used by USBdev
> >
> >   cpuid = 0
> >   KDB: enter: panic
> >   [thread pid 17 tid 100036 ]
> >   Stopped at  kdb_enter+0x3a: movl$0,kdb_why
> >
> > The detach step is like as follows:
> >
> >   usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
> >   ...
> >   uath_free_rx_data_list(sc);
> >   uath_free_tx_data_list(sc);
> >   uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);
> >
> > that I've checked all memory leaks or calls after freeing memory but it
> > looks it's not a driver problem.
> >
> > To solve this problem I modified codes slightly like below:
> >
> >   usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
> >   usb2_pause_mtx(NULL, 5 * hz);
> >   ...
> >   uath_free_rx_data_list(sc);
> >   uath_free_tx_data_list(sc);
> >   uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);
> >
> > After adding it I couldn't see `Memory modified after free' messages
> > anymore.  My question is that I can't understand why adding
> > usb2_pause_mtx() helps this symptom?
> 
> Did you drain all the taskqueues before unsetup ?

It looks I found a problem that some tasks running by net80211 causes
this problem.  It looks calling usb2_transfer_unsetup() after 
ieee80211_ifdetach(ic) solves the problem.  Thanks!

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: q: Memory modified after free in usb2

[Weongyo Jeong]

On Wed, Mar 25, 2009 at 10:46:54AM +0100, Hans Petter Selasky wrote:
> On Wednesday 25 March 2009, Weongyo Jeong wrote:
> > Hello Hans :),
> >
> > I think porting uath(4) to usb almost have done that it works well to
> > associate with AP and for WPA but I'm suffered from a strange panic after
> > detach as follows:
> >
> >   Memory modified after free 0xc4da3600(508) val=2400 @ 0xc4da3600
> >   panic: Most recently used by USBdev
> >
> >   cpuid = 0
> >   KDB: enter: panic
> >   [thread pid 17 tid 100036 ]
> >   Stopped at  kdb_enter+0x3a: movl$0,kdb_why
> >
> > The detach step is like as follows:
> >
> >   usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
> >   ...
> >   uath_free_rx_data_list(sc);
> >   uath_free_tx_data_list(sc);
> >   uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);
> >
> > that I've checked all memory leaks or calls after freeing memory but it
> > looks it's not a driver problem.
> >
> > To solve this problem I modified codes slightly like below:
> >
> >   usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
> >   usb2_pause_mtx(NULL, 5 * hz);
> >   ...
> >   uath_free_rx_data_list(sc);
> >   uath_free_tx_data_list(sc);
> >   uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);
> >
> > After adding it I couldn't see `Memory modified after free' messages
> > anymore.  My question is that I can't understand why adding
> > usb2_pause_mtx() helps this symptom?
> 
> Did you drain all the taskqueues before unsetup ?

Yes.  All I used was two callouts that the driver currently doesn't use
usb2_proc_create() and tried to drain its before calling
usb2_transfer_unsetup() but it still encounters `Memory modified after
free'.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

q: Memory modified after free in usb2

[Weongyo Jeong]

Hello Hans :),

I think porting uath(4) to usb almost have done that it works well to
associate with AP and for WPA but I'm suffered from a strange panic after
detach as follows:

  Memory modified after free 0xc4da3600(508) val=2400 @ 0xc4da3600
  panic: Most recently used by USBdev

  cpuid = 0
  KDB: enter: panic
  [thread pid 17 tid 100036 ]
  Stopped at  kdb_enter+0x3a: movl$0,kdb_why

The detach step is like as follows:

  usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
  ...
  uath_free_rx_data_list(sc);
  uath_free_tx_data_list(sc);
  uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);

that I've checked all memory leaks or calls after freeing memory but it
looks it's not a driver problem.

To solve this problem I modified codes slightly like below:

  usb2_transfer_unsetup(sc->sc_xfer, UATH_N_XFERS);
  usb2_pause_mtx(NULL, 5 * hz);
  ...
  uath_free_rx_data_list(sc);
  uath_free_tx_data_list(sc);
  uath_free_cmd_list(sc, sc->sc_cmd, UATH_CMD_LIST_COUNT);

After adding it I couldn't see `Memory modified after free' messages
anymore.  My question is that I can't understand why adding
usb2_pause_mtx() helps this symptom?

regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

On Thu, Mar 19, 2009 at 02:32:23PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> On Thursday 19 March 2009, Weongyo Jeong wrote:
> > On Thu, Mar 19, 2009 at 09:01:23AM +0100, Hans Petter Selasky wrote:
> > > On Thursday 19 March 2009, Weongyo Jeong wrote:
> > > > ugen_default_read_callback:384: actlen=0, aframes=0
> > > > ugen_default_read_callback:384: actlen=0, aframes=0
> > > > ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared
> > >
> > > One difference from the old ugen implementation is that a stall error
> > > does not cause any error to be returned to userland!
> > >
> > > You could try to return a ZLP on errors. Try this patch:
> > >
> > > http://perforce.freebsd.org/chv.cgi?CH=159423
> > >
> > > If you need to distinguish a ZLP from a STALL, then you have to use the
> > > new libusb! Ugen is not meant to be a replacement for libusb!
> >
> > Thanks you for a patch but it's not a answer what I want because my
> > symptom is that recv(2) waits forever before or returns 0 after applying
> > your patch.  It shouldn't return 0 or nothing that the size of the recv(2)
> > return value should be 512.
> 
> The ugen interface is now double buffered, so it will read data in the 
> background! The old was not double buffered. There are currently only two 
> buffers. If you see the packet in the analyzer it has most likely also ended 
> up in a UGEN buffer.
> 
> > I tried to dump USB transactions using USB 
> > analyzer and the dump file is available at:
> >
> > http://people.freebsd.org/~weongyo/uathload_20090319_export.txt
> 
> What happens if you change:
> 
>   |if (read(msg, &rxmsg, sizeof(rxmsg)) != 
> sizeof(rxmsg)) {
> 215:  |VERBOSE("%s", "\n");
>   |err(-1, "error reading msg (%s)", 
> msgdev);
>   |break;
>   |}
> 
> Into while loop for sake of testing? So that if the length is 0 you loop one 
> more time and if you have more than X zero lengths returned, you break?

I tried to do your suggestion but no changes.  read(2) returned always 0
(after applying http://perforce.freebsd.org/chv.cgi?CH=159423) that it
looks ugen missed a transaction the device sent to the host.

> >
> > Interesting packets could be found after 241 transactions and the steps
> > of program are as follows:
> >
> > write(endpoint 0x1, buf, 512);
> > write(endpoint 0x2, buf, 512);
> > write(endpoint 0x2, buf, 512);
> > write(endpoint 0x2, buf, 512);
> > write(endpoint 0x2, buf, 512);
> > read(endpoint 0x81, buf, 512);  <-- here error.
> >
> > As you can see with looking the dump file, ugen couldn't catch the read
> > event even though the USB stick responses data at Transaction 264, 265
> > and 266.  It looks the problem is in ugen(4).  As looking usb_generic.c
> > it looks the read/write pipe are opened on the fly when read(2) or
> > write(2) systemcalls are called though in the previous ugen(4) in usb1
> > all pipes are opened at open(2).  Could this difference affect this
> > symptom?  I'd try to test another cases.
> 
> The old ugen would also do a clear-stall which the new one does not do, 
> unless 
> you do an IOCTL before the first read! That is also something you can try.

Also I tried this with commenting out all of ioctl(2) calls.  But after
it it looks recv(2) never returns.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

On Thu, Mar 19, 2009 at 09:01:23AM +0100, Hans Petter Selasky wrote:
> On Thursday 19 March 2009, Weongyo Jeong wrote:
> > ugen_default_read_callback:384: actlen=0, aframes=0
> > ugen_default_read_callback:384: actlen=0, aframes=0
> > ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared
> 
> One difference from the old ugen implementation is that a stall error does 
> not 
> cause any error to be returned to userland!
> 
> You could try to return a ZLP on errors. Try this patch:
> 
> http://perforce.freebsd.org/chv.cgi?CH=159423
> 
> If you need to distinguish a ZLP from a STALL, then you have to use the new 
> libusb! Ugen is not meant to be a replacement for libusb!

Thanks you for a patch but it's not a answer what I want because my
symptom is that recv(2) waits forever before or returns 0 after applying your
patch.  It shouldn't return 0 or nothing that the size of the recv(2) return
value should be 512.  I tried to dump USB transactions using USB
analyzer and the dump file is available at:

http://people.freebsd.org/~weongyo/uathload_20090319_export.txt

Interesting packets could be found after 241 transactions and the steps
of program are as follows:

write(endpoint 0x1, buf, 512);
write(endpoint 0x2, buf, 512);
write(endpoint 0x2, buf, 512);
write(endpoint 0x2, buf, 512);
write(endpoint 0x2, buf, 512);
read(endpoint 0x81, buf, 512);  <-- here error.

As you can see with looking the dump file, ugen couldn't catch the read
event even though the USB stick responses data at Transaction 264, 265
and 266.  It looks the problem is in ugen(4).  As looking usb_generic.c
it looks the read/write pipe are opened on the fly when read(2) or
write(2) systemcalls are called though in the previous ugen(4) in usb1
all pipes are opened at open(2).  Could this difference affect this
symptom?  I'd try to test another cases.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

On Wed, Mar 18, 2009 at 02:54:17PM +0100, Hans Petter Selasky wrote:
> On Wednesday 18 March 2009, Weongyo Jeong wrote:
> > On Wed, Mar 18, 2009 at 08:52:47AM +0100, Hans Petter Selasky wrote:
> > > Hi,
> > >
> > > On Wednesday 18 March 2009, Weongyo Jeong wrote:
> > > > Hello,
> > > >
> > > > During porting uath(4) to usb2 I found the following code failed to
> > > > run:
> > > >
> > > > data = open("/dev/usb/0.2.2", O_WRONLY, 0);
> > > > timeout = UATH_DATA_TIMEOUT;
> > > > if (ioctl(data, USB_SET_TIMEOUT, &timeout) < 0)
> > > > err(-1, "%s: USB_SET_TIMEOUT(%u)", datadev,
> > > > UATH_DATA_TIMEOUT);
> > > >
> > > > and the error was:
> > > >
> > > > uathload: /dev/usb/0.2.2: USB_SET_TIMEOUT(1000): Invalid
> > > > argument
> > >
> > > Use the following macro instead:
> > >
> > > #define USB_SET_TX_TIMEOUT  _IOW ('U', 137, int)
> > >
> > > There also is a match for USB_SET_RX_TIMEOUT .
> > >
> > > USB_SET_TIMEOUT has been removed.
> > >
> > > Also don't forget to include "usb_ioctl.h" .
> > >
> > > Another idea:
> > >
> > > Port the program to libusb 
> > >
> > > > It looks it's ok with calling ioctl(msg, USB_SET_TIMEOUT, ..) to
> > > > /dev/usb/0.2.1
> > > >
> > > > And the behaviour of program isn't likely with usb1 that it worked well
> > > > in usb1.  After writing some data into msg and data pipe there was no
> > > > any response using read(2).  The problem source can be found at:.
> > > >
> > > > 
> > > > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/weo
> > > >ngyo /wireless/src/usr.sbin/uathload&HIDEDEL=NO
> > > >
> > > > Are there something I missed in here?
> > >
> > > See hints above.
> >
> > Thank you for advise. :-)  I've solve `Invalid argument' error.  However
> > the program looks it still doesn't work.  All functions the problem used
> > are open(2), ioctl(2), read(2) and write(2).  I think I can try to use
> > libusb but it'd be better if it works again using the above 4 system
> > calls.
> >
> > Is it supported in CURRENT or is it a one of regression?
> >
> > regards,
> > Weongyo Jeong
> 
> What other IOCTL's are used?
> 
> Can you make a debug trace:
> 
> sysctl hw.usb2.ugen.debug=15
> sysctl hw.usb2.dev.debug=15
> 
> ?

It's a simple program so only USB_SET_RX_TIMEOUT and USB_SET_TX_TIMEOUT
are set via ioctl(2).  And the result is as follows:

[r...@kkk /usr/p4/w/usr.sbin/uathload]# ./uathload -d /dev/ugen0.2 -v
usb2_open:823: fflags=0x0003
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374bc0 need uref=1
usb2_ref_device:243: ref udev - needed
usb2_fifo_create:409: Endpoint device, searching for 0x01
usb2_fifo_create:480: dev_get_pipe(1, 0x0)
usb2_fifo_create:507: dev_get_pipe(1, 0x1)
usb2_fifo_create:536: fifo index = 0
ugen_open:158: flag=0x1
ugen_open:158: flag=0x2
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374bc0 need uref=0
usb2_ref_device:235: ref write
usb2_ref_device:239: ref read
usb2_ioctl:1021: fflags=3, cmd=0x80045572
ugen_ioctl:1388: cmd=0x80045572
ugen_ioctl:1566: error=-3
usb2_uref_location:297: ref udev
ugen_ioctl_post:1963: cmd=0x80045572
ugen_ioctl_post:2164: error=0
usb2_open:823: fflags=0x0002
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374740 need uref=1
usb2_ref_device:243: ref udev - needed
usb2_fifo_create:409: Endpoint device, searching for 0x02
usb2_fifo_create:480: dev_get_pipe(2, 0x0)
usb2_fifo_create:536: fifo index = 2
ugen_open:158: flag=0x2
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374740 need uref=0
usb2_ref_device:235: ref write
usb2_ioctl:1021: fflags=2, cmd=0x80045589
ugen_ioctl:1388: cmd=0x80045589
ugen_ioctl:1566: error=-3
usb2_uref_location:297: ref udev
ugen_ioctl_post:1963: cmd=0x80045589
ugen_ioctl_post:2164: error=0
Load firmware aru5523.bin (builtisn) to /dev/ugen0b.2
send block  20: 147368 bytes _remainingwrite:1291: 
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374bc0 need uref=0
usb2_ref_device:235: ref write
usb2_ref_device:239: ref read
usb2_write:1362: transfer 512 bytes to 0xc8382038
ugen_default_write_callback:434: actlen=0, aframes=0
ugen_default_write_callback:434: actlen=0, aframes=0
ugen_default_write_callback:434: actlen=512, aframes=1

u : dsata...b2_write:1291: 
usb2_ref_device:165: us

Re: q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

On Wed, Mar 18, 2009 at 08:52:47AM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> On Wednesday 18 March 2009, Weongyo Jeong wrote:
> > Hello,
> >
> > During porting uath(4) to usb2 I found the following code failed to run:
> >
> > data = open("/dev/usb/0.2.2", O_WRONLY, 0);
> > timeout = UATH_DATA_TIMEOUT;
> > if (ioctl(data, USB_SET_TIMEOUT, &timeout) < 0)
> > err(-1, "%s: USB_SET_TIMEOUT(%u)", datadev,
> > UATH_DATA_TIMEOUT);
> >
> > and the error was:
> >
> > uathload: /dev/usb/0.2.2: USB_SET_TIMEOUT(1000): Invalid
> > argument
> 
> Use the following macro instead:
> 
> #define USB_SET_TX_TIMEOUT  _IOW ('U', 137, int)
> 
> There also is a match for USB_SET_RX_TIMEOUT .
> 
> USB_SET_TIMEOUT has been removed.
> 
> Also don't forget to include "usb_ioctl.h" .
> 
> Another idea:
> 
> Port the program to libusb 
> 
> >
> > It looks it's ok with calling ioctl(msg, USB_SET_TIMEOUT, ..) to
> > /dev/usb/0.2.1
> >
> > And the behaviour of program isn't likely with usb1 that it worked well
> > in usb1.  After writing some data into msg and data pipe there was no
> > any response using read(2).  The problem source can be found at:.
> >
> > 
> > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo
> >/wireless/src/usr.sbin/uathload&HIDEDEL=NO
> >
> > Are there something I missed in here?
> >
> 
> See hints above.

Thank you for advise. :-)  I've solve `Invalid argument' error.  However
the program looks it still doesn't work.  All functions the problem used
are open(2), ioctl(2), read(2) and write(2).  I think I can try to use
libusb but it'd be better if it works again using the above 4 system
calls.

Is it supported in CURRENT or is it a one of regression?

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

Hello,

During porting uath(4) to usb2 I found the following code failed to run:

data = open("/dev/usb/0.2.2", O_WRONLY, 0);
timeout = UATH_DATA_TIMEOUT;
if (ioctl(data, USB_SET_TIMEOUT, &timeout) < 0)
err(-1, "%s: USB_SET_TIMEOUT(%u)", datadev,
UATH_DATA_TIMEOUT);

and the error was:

uathload: /dev/usb/0.2.2: USB_SET_TIMEOUT(1000): Invalid
argument

It looks it's ok with calling ioctl(msg, USB_SET_TIMEOUT, ..) to
/dev/usb/0.2.1

And the behaviour of program isn't likely with usb1 that it worked well
in usb1.  After writing some data into msg and data pipe there was no
any response using read(2).  The problem source can be found at:.


http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo/wireless/src/usr.sbin/uathload&HIDEDEL=NO

Are there something I missed in here?

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB support in NDIS -- IFF_NEEDSGIANT?

[Weongyo Jeong]

On Fri, Mar 13, 2009 at 11:37:57AM +, Robert Watson wrote:
> 
> On Tue, 17 Feb 2009, Weongyo Jeong wrote:
> 
> >>As you know, I've been gradually working to eliminate all non-MPSAFE
> >>network device driver infrastructure for 8.0, having removed non-MPSAFE
> >>network protocol infrastructure in 7.0.  In reviewing remaining drivers
> >>using IFF_NEEDSGIANT, I spotted this in the NDIS code:
> ...
> >>Having taken a glance, it looks like this was added specifically to 
> >>support
> >>USB devices attached via NDIS.
> >
> >AFAIK all of usb wireless drivers had it so I couldn't avoid it when I had 
> >implemented.
> >
> >>With the new USB code, are NDIS drivers still supported?
> >
> >I think that it would be supported at 8.0
> >
> >>And in the new world order, is this IFF_NEEDSGIANT still required?
> >
> >Probably we can remove the IFF_NEEDSGIANT flags at the new USB code.
> >
> >>Can I simply remove it once the old USB code is on the way out the door?
> >
> >IMHO yes I think.
> 
> Dear all:
> 
> A few weeks have passed, so I wanted to check in and see how this project 
> was going -- are we at a point yet where removing IFF_NEEDSGIANT won't 
> cause significant loss of functionality?

In the current, NDIS USB porting almost have completed and it doesn't use
IFF_NEEDSGIANT anymore.  With some tests it looks it works well so I
think it wouldn't cause any loss of functionality.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB support in NDIS -- IFF_NEEDSGIANT?

[Weongyo Jeong]

On Mon, Feb 16, 2009 at 11:33:18AM +, Robert Watson wrote:
> 
> Dear all:
> 
> As you know, I've been gradually working to eliminate all non-MPSAFE 
> network device driver infrastructure for 8.0, having removed non-MPSAFE 
> network protocol infrastructure in 7.0.  In reviewing remaining drivers 
> using IFF_NEEDSGIANT, I spotted this in the NDIS code:
> 
>   718 if_initname(ifp, device_get_name(dev), device_get_unit(dev));
>   719 ifp->if_mtu = ETHERMTU;
>   720 ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
>   721 if (sc->ndis_iftype == PNPBus)
>   722 ifp->if_flags |= IFF_NEEDSGIANT;
>   723 ifp->if_ioctl = ndis_ioctl;
>   724 ifp->if_start = ndis_start;
>   725 ifp->if_init = ndis_init;
> 
> Having taken a glance, it looks like this was added specifically to support 
> USB devices attached via NDIS.

AFAIK all of usb wireless drivers had it so I couldn't avoid it when I
had implemented.

> With the new USB code, are NDIS drivers still supported?

I think that it would be supported at 8.0

> And in the new world order, is this IFF_NEEDSGIANT still required?

Probably we can remove the IFF_NEEDSGIANT flags at the new USB code.

> Can I simply remove it once the old USB code is on the way out the
> door?

IMHO yes I think.

> (Note that the plan is to remove all device drivers that still require 
> IFF_NEEDSGIANT some time before 8.0, probably starting with disabling them 
> from the build in about 2-3 weeks).

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: HEADSUP: urtw(4) to be committed soon

[Weongyo Jeong]

On Wed, Jan 21, 2009 at 02:38:18PM +0800, Kevin Lo wrote:
> Weongyo Jeong wrote:
> > Hello,
> 
> Hi Weongyo,
> 
> > I would like to commit urtw(4) driver for supporting Realtek's 8187L
> > wireless chipset based on USB into HEAD by the end of the week if there
> > are no objections.  And the license of files would be as follows that
> > AFAIK it's based on OpenBSD's template license file:
> > 
> > /*-
> >  * Copyright (c) 2008 Weongyo Jeong 
> >  *
> >  * Permission to use, copy, modify, and distribute this software for any
> >  * purpose with or without fee is hereby granted, provided that the above
> >  * copyright notice and this permission notice appear in all copies.
> >  *
> >  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> >  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> >  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> >  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> >  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> >  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> >  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >  */
> > 
> > Because I'm not a lawyer it'd definitely fail to answer about your
> > detailed questions.  Just one thing I want to is that it's okay if it's
> > enough to use in *BSD, OpenSolaris and etc.  Not want to go into
> > troubles.  :-)
> > 
> > I'm looking for a person to port from USB to NEWUSB and if you want to
> > test you can find the sources at:
> > 
> > http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz
> 
> 
> Works for me, thanks. Though it's quite a bit slower, that's a job
> for another day :-)
> 
> $ dmesg | grep urtw0
> urtw0:  2> on uhub0
> urtw0: WARNING: using obsoleted IFF_NEEDSGIANT flag
> 
> $ ifconfig
> plip0: flags=108810 metric 0
> mtu 1500
> lo0: flags=8049 metric 0 mtu 16384
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff00
> urtw0: flags=108843
> metric 0 mtu 2290
> ether 00:40:0c:04:3b:2a
> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
> status: associated
> wlan0: flags=8843 metric 0 mtu
> 1500
> ether 00:40:0c:04:3b:2a
> inet 192.168.1.116 netmask 0xff00 broadcast 192.168.1.255
> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
> status: associated
> ssid MSI channel 11 (2462 Mhz 11g) bssid 00:11:09:0c:2f:91
> country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid
> 60
> bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5
> protmode CTS

Thank you for testing.  :-)  The performance issue is a known issue that
I think we need to fix a rate control routine for urtw(4).  I tried to use
wlan_amrr(4) but concluded it's hard to apply it without documents
because I couldn't find a flag whether the tx is failed or not.  It looks
it's not enough with just looking USB_STATUS value of usb callbacks.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

HEADSUP: urtw(4) to be committed soon

[Weongyo Jeong]

Hello,

I would like to commit urtw(4) driver for supporting Realtek's 8187L
wireless chipset based on USB into HEAD by the end of the week if there
are no objections.  And the license of files would be as follows that
AFAIK it's based on OpenBSD's template license file:

/*-
 * Copyright (c) 2008 Weongyo Jeong 
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

Because I'm not a lawyer it'd definitely fail to answer about your
detailed questions.  Just one thing I want to is that it's okay if it's
enough to use in *BSD, OpenSolaris and etc.  Not want to go into
troubles.  :-)

I'm looking for a person to port from USB to NEWUSB and if you want to
test you can find the sources at:

http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: HEADSUP: NDIS USB code has been committed

[Weongyo Jeong]

On Sat, Dec 27, 2008 at 06:36:56PM +0800, Ganbold wrote:
> Weongyo Jeong wrote:
> > Hello,
> >
> > Just for information.  The code for supporting NDIS USB drivers has been
> > committed into HEAD.  Please tell me if you encounter problems.
> >   
> Tried to compile kernel, but gives error. Is it related to your commit?
> ...
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -std=c99 -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/obj/usr/src/sys/DEVIL/opt_global.h -I. -I@ -I@/contrib/altq
> -finline-limit=8000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/DEVIL
> -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
> -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs
> -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
> -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c
> /usr/src/sys/modules/usb2/ndis/../../../dev/usb2/ndis/if_ndis_usb2.c
> In file included from
> /usr/src/sys/modules/usb2/ndis/../../../dev/usb2/ndis/if_ndis_usb2.c:60:
> @/dev/if_ndis/if_ndisvar.h:121: error: expected specifier-qualifier-list
> before 'usbd_xfer_handle'
> @/dev/if_ndis/if_ndisvar.h:212: error: expected specifier-qualifier-list
> before 'usbd_pipe_handle'
> *** Error code 1
> 1 error
> *** Error code 2
> ...

Yes.  It's related with my commit that now if_ndisvar.h has some
structures referring to the original USB framework so it breaks on the
newusb.

Now building NDIS part on the newusb have decoupled from the default
build.  I hope now the builds are recovered.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: HEADSUP: NDIS USB code has been committed

[Weongyo Jeong]

On Sat, Dec 27, 2008 at 02:09:37AM -0800, Julian Elischer wrote:
> Weongyo Jeong wrote:
> >Hello,
> >
> >Just for information.  The code for supporting NDIS USB drivers has been
> >committed into HEAD.  Please tell me if you encounter problems.
> >
> >regards,
> >Weongyo Jeong
> 
> using the original USB code, right?

Yes.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

HEADSUP: NDIS USB code has been committed

[Weongyo Jeong]

Hello,

Just for information.  The code for supporting NDIS USB drivers has been
committed into HEAD.  Please tell me if you encounter problems.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: HEADSUP: NDIS USB support to be merged soon

[Weongyo Jeong]

On Tue, Dec 23, 2008 at 05:18:00PM +0100, Hans Petter Selasky wrote:
> On Tuesday 23 December 2008, Alfred Perlstein wrote:
> > [[ Moved to -usb. ]]
> >
> > Hans, can you look at this for the usb4bsd switchover, it doesn't
> > look that challenging to port.
> >
> > thank you,
> > -Alfred
> 
> I will have a look at it. Meanwhile, can Weongyo have a look at the following 
> file:
> 
> /usr/src/sys/dev/usb2/core/usb2_compat_linux.c
> 
> I suppose we have to do NDIS in a similar way.

Sorry I couldn't follow.  Could you please elaborate it?  IIRC NDIS's
approach to support Windows Binary and a approach to support Linux
Binary Compatibility are different.  I'm not sure we can do it like what
the linuxulator is doing.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

HEADSUP: NDIS USB support to be merged soon

[Weongyo Jeong]

Hello,

Before several months ago I'd requested CFT about NDIS USB support.  Now
I'd like to merge the result into HEAD and want to hear opinions and
problems from users because many problems have fixed now and I think
it's stable to use.

If no objections, I would like to merge it by the end of the week or the
next week.

For those of you wanting to test, please rebuild/reinstall ndiscvt(8)
after applying the patch which can be found as follows:

http://people.freebsd.org/~weongyo/patch_ndisusb_20081223.diff

This work is based on USB1 framework so I'm also looking for a person to
port this from USB1 to USB2.

regards,
Weongyo Jeong

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"