Re: Merging ugen into the usb stack

[Martin Husemann]

On Tue, Feb 13, 2018 at 03:07:11PM +0100, Martin Husemann wrote:
> On Tue, Feb 13, 2018 at 03:02:56PM +0100, Wolfgang Solfrank wrote:
> > What exactly do you mean with "can't use ttyU1"?
> 
> The ttyU1 serial console is dead, no data in/no data out as far as I can
> tell. I'll debug/investigate this, as I have a good debug setup now.

Not sure what stupid thing I did wrong on initial testing (typo the serial
speed or something?) - it just works now when I retested it, both with
a single "regular" uftdi and the SheevaPlug JTAG console port.

Martin

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi,


It doesn't solve the generic (no pun intended) problem of raw ugen access to 
arbitrary other devices, e.g. for use by USB over IP
http://usbip.sourceforge.net/

Of course, a better approach may be to add detach kernel driver functionality:
http://libusb.sourceforge.net/api-1.0/group__dev.html#ga21bd343325f558987ca57e4e281a6d47


While this may be a good idea in general, for this particular use case
it will not work as expected (at lease expected by me):  By detaching
the (original) uftdi driver from the device, you would not only have to
drive the jtag channel from userland, but the serial line on the second
channel, too.

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank

Re: Merging ugen into the usb stack

[Martin Husemann]

On Tue, Feb 13, 2018 at 03:02:56PM +0100, Wolfgang Solfrank wrote:
> What exactly do you mean with "can't use ttyU1"?

The ttyU1 serial console is dead, no data in/no data out as far as I can
tell. I'll debug/investigate this, as I have a good debug setup now.

Martin

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi Martin,

Martin Husemann schrieb:

On Thu, Feb 08, 2018 at 07:15:55PM +0100, Martin Husemann wrote:

Seems to work for me as well:

root file system type: ffs
kern.module.path=/stand/i386/8.99.12/modules
ugen0 at uhub0 port 1 configuration 1 interface 0
ugen0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 
2
uftdi0 at uhub0 port 1 configuration 1 interface 1
uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
addr 2
ucom1 at uftdi0 portno 2


Hmm, not quite, i can't use ttyU1 (or the other uftdi ones), while the uplcom
based ttyU0 and ttyU2 work.


What exactly do you mean with "can't use ttyU1"?

Did you try to use it with nothing else going on?  Or are you
trying to access ttyU1 while using openocd at the same time?

Does it crash?  Hang?

Unfortunately I'm currently unable to test this.  While I still
have the debug board available, the device to be debugged by this
doesn't work any longer.  And since the seial line is brought out
of the debug board on the same ffc as the jtag connection, I don't
have easy access to it.

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank

Re: Merging ugen into the usb stack

[Stephen Borrill]

On Thu, 8 Feb 2018, Martin Husemann wrote:

On Thu, Feb 08, 2018 at 05:22:18PM +0100, Wolfgang Solfrank wrote:

Hi,

with the attached diffs I'm able to attach my debug board like this:

ugen0 at uhub5 port 1 configuration 1 interface 0
ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr 3
uftdi0 at uhub5 port 1 configuration 1 interface 1
uftdi0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr 
3
ucom0 at uftdi0 portno 2


Very cool!

Seems to work for me as well:

root file system type: ffs
kern.module.path=/stand/i386/8.99.12/modules
ugen0 at uhub0 port 1 configuration 1 interface 0
ugen0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 
2
uftdi0 at uhub0 port 1 configuration 1 interface 1
uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
addr 2
ucom1 at uftdi0 portno 2
uhub5 at uhub2 port 2: vendor 0451 (0x451) product 1446 (0x1446), class 9/0, 
rev 1.10/1.10, addr 3
uhub5: 4 ports with 4 removable, self powered
uplcom1 at uhub5 port 1
uplcom1: Prolific Technology Inc. (0x67b) USB-Serial Controller (0x2303), rev 
1.10/3.00, addr 4
ucom2 at uplcom1
uftdi1 at uhub5 port 3 configuration 1 interface 0
uftdi1: FTDI (0x403) TTL232R-3V3 (0x6001), rev 2.00/6.00, addr 5
ucom3 at uftdi1 portno 1
uftdi2 at uhub5 port 4 configuration 1 interface 0
uftdi2: FTDI (0x403) TTL232R-3V3 (0x6001), rev 2.00/6.00, addr 6
...


I like the aproach, we could even add a few uftdi specific instances of
this ugen variant to GENERIC (or usbdevices.config).

Can we get this commited? Anyone objecting?


It doesn't solve the generic (no pun intended) problem of raw ugen access 
to arbitrary other devices, e.g. for use by USB over IP

http://usbip.sourceforge.net/

Of course, a better approach may be to add detach kernel driver 
functionality:

http://libusb.sourceforge.net/api-1.0/group__dev.html#ga21bd343325f558987ca57e4e281a6d47

--
Stephen

Re: Merging ugen into the usb stack

[Martin Husemann]

On Thu, Feb 08, 2018 at 07:15:55PM +0100, Martin Husemann wrote:
> Seems to work for me as well:
> 
> root file system type: ffs
> kern.module.path=/stand/i386/8.99.12/modules
> ugen0 at uhub0 port 1 configuration 1 interface 0
> ugen0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
> addr 2
> uftdi0 at uhub0 port 1 configuration 1 interface 1
> uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
> addr 2
> ucom1 at uftdi0 portno 2

Hmm, not quite, i can't use ttyU1 (or the other uftdi ones), while the uplcom
based ttyU0 and ttyU2 work.

Martin

Re: Merging ugen into the usb stack

[Martin Husemann]

On Thu, Feb 08, 2018 at 05:22:18PM +0100, Wolfgang Solfrank wrote:
> Hi,
> 
> with the attached diffs I'm able to attach my debug board like this:
> 
> ugen0 at uhub5 port 1 configuration 1 interface 0
> ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, 
> addr 3
> uftdi0 at uhub5 port 1 configuration 1 interface 1
> uftdi0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, 
> addr 3
> ucom0 at uftdi0 portno 2

Very cool!

Seems to work for me as well:

root file system type: ffs
kern.module.path=/stand/i386/8.99.12/modules
ugen0 at uhub0 port 1 configuration 1 interface 0
ugen0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 
2
uftdi0 at uhub0 port 1 configuration 1 interface 1
uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
addr 2
ucom1 at uftdi0 portno 2
uhub5 at uhub2 port 2: vendor 0451 (0x451) product 1446 (0x1446), class 9/0, 
rev 1.10/1.10, addr 3
uhub5: 4 ports with 4 removable, self powered
uplcom1 at uhub5 port 1
uplcom1: Prolific Technology Inc. (0x67b) USB-Serial Controller (0x2303), rev 
1.10/3.00, addr 4
ucom2 at uplcom1
uftdi1 at uhub5 port 3 configuration 1 interface 0
uftdi1: FTDI (0x403) TTL232R-3V3 (0x6001), rev 2.00/6.00, addr 5
ucom3 at uftdi1 portno 1
uftdi2 at uhub5 port 4 configuration 1 interface 0
uftdi2: FTDI (0x403) TTL232R-3V3 (0x6001), rev 2.00/6.00, addr 6
...


I like the aproach, we could even add a few uftdi specific instances of
this ugen variant to GENERIC (or usbdevices.config).

Can we get this commited? Anyone objecting?

Martin

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi,

with the attached diffs I'm able to attach my debug board like this:

ugen0 at uhub5 port 1 configuration 1 interface 0
ugen0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr 3
uftdi0 at uhub5 port 1 configuration 1 interface 1
uftdi0: OpenMoko (0x1457) Debug Board for Neo1973 (0x5118), rev 2.00/5.00, addr 
3
ucom0 at uftdi0 portno 2

(Actually, not, as the codes for my debug board are missing in usbdevs.)

Note that you have to be careful when using this ugen. There
is no restriction to interface 0, you can change configuration
and interfere with the ucom driver attached to interface 1.

The only configuration line needed for this (apart from including
usbdevices.config) is something like

ugen*   at uhub? interface 0 flags 1

or, if you want to restrict this to some specific board:

ugen*   at uhub? vendor 0x1457 product 0x5118 interface 0 flags 1

No need for the previously mentioned "no uftdi*", as the ugen
(due to the "flags 1") will attach with a higher priority.

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank
Index: files.usb
===
RCS file: /cvsroot/src/sys/dev/usb/files.usb,v
retrieving revision 1.148
diff -u -r1.148 files.usb
--- files.usb   10 Dec 2017 17:03:07 -  1.148
+++ files.usb   8 Feb 2018 16:15:11 -
@@ -138,6 +138,7 @@
 # Generic devices
 device ugen
 attach ugen at usbdevif
+attach ugen at usbifif with ugenif
 file   dev/usb/ugen.c  ugenneeds-flag
 
 
@@ -387,7 +388,7 @@
 
 # FTDI serial driver
 device uftdi: ucombus
-attach uftdi at usbdevif
+attach uftdi at usbifif
 file   dev/usb/uftdi.c uftdi
 
 # Prolific PL2303 serial driver
Index: uftdi.c
===
RCS file: /cvsroot/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.66
diff -u -r1.66 uftdi.c
--- uftdi.c 22 Dec 2017 14:18:29 -  1.66
+++ uftdi.c 8 Feb 2018 16:15:11 -
@@ -62,9 +62,7 @@
 #define DPRINTFN(n,x)
 #endif
 
-#define UFTDI_CONFIG_INDEX 0
-#define UFTDI_IFACE_INDEX  0
-#define UFTDI_MAX_PORTS4
+#define UFTDI_CONFIG_NO1
 
 /*
  * These are the default number of bytes transferred per frame if the
@@ -83,17 +81,17 @@
 struct uftdi_softc {
device_tsc_dev; /* base device */
struct usbd_device *sc_udev;/* device */
-   struct usbd_interface * sc_iface[UFTDI_MAX_PORTS];  /* interface */
+   struct usbd_interface * sc_iface;   /* interface */
+   int sc_iface_no;
 
enum uftdi_type sc_type;
u_int   sc_hdrlen;
-   u_int   sc_numports;
u_int   sc_chiptype;
 
u_char  sc_msr;
u_char  sc_lsr;
 
-   device_tsc_subdev[UFTDI_MAX_PORTS];
+   device_tsc_subdev;
 
u_char  sc_dying;
 
@@ -190,29 +188,30 @@
 int
 uftdi_match(device_t parent, cfdata_t match, void *aux)
 {
-   struct usb_attach_arg *uaa = aux;
+   struct usbif_attach_arg *uiaa = aux;
 
DPRINTFN(20,("uftdi: vendor=0x%x, product=0x%x\n",
-uaa->uaa_vendor, uaa->uaa_product));
+uiaa->uiaa_vendor, uiaa->uiaa_product));
 
-   return uftdi_lookup(uaa->uaa_vendor, uaa->uaa_product) != NULL ?
-   UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
+   if (uiaa->uiaa_configno != UFTDI_CONFIG_NO)
+   return UMATCH_NONE;
+
+   return uftdi_lookup(uiaa->uiaa_vendor, uiaa->uiaa_product) != NULL ?
+   UMATCH_VENDOR_PRODUCT_CONF_IFACE : UMATCH_NONE;
 }
 
 void
 uftdi_attach(device_t parent, device_t self, void *aux)
 {
struct uftdi_softc *sc = device_private(self);
-   struct usb_attach_arg *uaa = aux;
-   struct usbd_device *dev = uaa->uaa_device;
-   struct usbd_interface *iface;
+   struct usbif_attach_arg *uiaa = aux;
+   struct usbd_device *dev = uiaa->uiaa_device;
+   struct usbd_interface *iface = uiaa->uiaa_iface;
usb_device_descriptor_t *ddesc;
usb_interface_descriptor_t *id;
usb_endpoint_descriptor_t *ed;
char *devinfop;
-   const char *devname = device_xname(self);
-   int i,idx;
-   usbd_status err;
+   int i;
struct ucom_attach_args ucaa;
 
DPRINTFN(10,("\nuftdi_attach: sc=%p\n", sc));
@@ -224,122 +223,86 @@
aprint_normal_dev(self, "%s\n", devinfop);
usbd_devinfo_free(devinfop);
 
-   /* Move the device into the configured state. */
-   err = usbd_set_config_index(dev, UFTDI_CONFIG_INDEX, 1);
-   if (err) {
-   aprint_error("\n%s: failed to set configuration, err=%s\n",
-  devname, usbd_errstr(err));
-   goto bad;
-   }
-

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi again,



  - add a variation of uftdi that attaches on single interfaces (Wolfgang,
    can you share your code, even if it does not work with -current?), and
    either always use this variant, or use this variant on chips matched
    by above mentioned quirks table.


See attached.


Attached is a version of uftdi.c that works again with current (as of 1/29).


The only other change required is in files.usb, where I had to change the
"attach uftdi at usbdevif" to "attach uftdi at usbifif".  With these changes
I was able to  attach uftdi by specifying an interface.


Without any other change to kernel config files, uftdi will attach separately
to any uftdi interface found.  I.e., with my board I get two instances of uftdi.

If you want uftdi only on the second port, you need, after including
usbdevices.config, something like:

no uftdi*
uftdi* at uhub? interface 1

While it is possible to restrict this to a specific device (with the vendor
and product attributes), it is not possible to have a generic uftdi
attachment in parallel to the above, as then the generic attachment
will match interface 0 on the device in question, too.


  - make ugen be able to attach to single/specific interfaces as well (off
    hand I'm not sure this would need code changes, but again, Wolfgang,
    could you make your patches available?)


Sorry, looks like I lost any changes I made to ugen.c :-(


I will try to reconstruct this, too.

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank
/*	$NetBSD: uftdi.c,v 1.66 2017/12/22 14:18:29 jakllsch Exp $	*/

/*
 * Copyright (c) 2000 The NetBSD Foundation, Inc.
 * All rights reserved.
 *
 * This code is derived from software contributed to The NetBSD Foundation
 * by Lennart Augustsson (lenn...@augustsson.net).
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

#include 
__KERNEL_RCSID(0, "$NetBSD: uftdi.c,v 1.66 2017/12/22 14:18:29 jakllsch Exp $");

#ifdef _KERNEL_OPT
#include "opt_usb.h"
#endif

#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 

#include 

#include 

#ifdef UFTDI_DEBUG
#define DPRINTF(x)	if (uftdidebug) printf x
#define DPRINTFN(n,x)	if (uftdidebug>(n)) printf x
int uftdidebug = 0;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif

#define UFTDI_CONFIG_NO		1

/*
 * These are the default number of bytes transferred per frame if the
 * endpoint doesn't tell us.  The output buffer size is a hard limit
 * for devices that use a 6-bit size encoding.
 */
#define UFTDIIBUFSIZE 64
#define UFTDIOBUFSIZE 64

/*
 * Magic constants!  Where do these come from?  They're what Linux uses...
 */
#define	UFTDI_MAX_IBUFSIZE	512
#define	UFTDI_MAX_OBUFSIZE	256

struct uftdi_softc {
	device_t		sc_dev;		/* base device */
	struct usbd_device *	sc_udev;	/* device */
	struct usbd_interface *	sc_iface;	/* interface */
	int			sc_iface_no;

	enum uftdi_type		sc_type;
	u_int			sc_hdrlen;
	u_int			sc_chiptype;

	u_char			sc_msr;
	u_char			sc_lsr;

	device_t		sc_subdev;

	u_char			sc_dying;

	u_int			last_lcr;

};

Static void	uftdi_get_status(void *, int, u_char *, u_char *);
Static void	uftdi_set(void *, int, int, int);
Static int	uftdi_param(void *, int, struct termios *);
Static int	uftdi_open(void *, int);
Static void	uftdi_read(void *, int, u_char **, uint32_t *);
Static void	uftdi_write(void *, int, u_char *, u_char *,
			uint32_t *);
Static void	uftdi_break(void *, int, int);

struct ucom_methods uftdi_methods = {
	.ucom_get_status = uftdi_get_status,
	.ucom_set = uftdi_set,
	.ucom_param = uftdi_param,
	.ucom_ioctl = NULL,
	.ucom_open = uftdi_open,
	.ucom_close = NULL,
	.ucom_read = uftdi_read,
	.ucom_write = uftdi_write,
};

/*
 * The devices default to 

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi Martin,


  - add a variation of uftdi that attaches on single interfaces (Wolfgang,
can you share your code, even if it does not work with -current?), and
either always use this variant, or use this variant on chips matched
by above mentioned quirks table.


See attached.

The only other change required is in files.usb, where I had to change the
"attach uftdi at usbdevif" to "attach uftdi at usbifif".  With these changes
I was able to  attach uftdi by specifying an interface.


  - make ugen be able to attach to single/specific interfaces as well (off
hand I'm not sure this would need code changes, but again, Wolfgang,
could you make your patches available?)


Sorry, looks like I lost any changes I made to ugen.c :-(

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank
/*	$NetBSD: uftdi.c,v 1.60 2015/02/20 14:50:53 nonaka Exp $	*/

/*
 * Copyright (c) 2000 The NetBSD Foundation, Inc.
 * All rights reserved.
 *
 * This code is derived from software contributed to The NetBSD Foundation
 * by Lennart Augustsson (lenn...@augustsson.net).
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

#include 
__KERNEL_RCSID(0, "$NetBSD: uftdi.c,v 1.60 2015/02/20 14:50:53 nonaka Exp $");

#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 

#include 

#include 

#ifdef UFTDI_DEBUG
#define DPRINTF(x)	if (uftdidebug) printf x
#define DPRINTFN(n,x)	if (uftdidebug>(n)) printf x
int uftdidebug = 0;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif

#define UFTDI_CONFIG_NO		1

/*
 * These are the default number of bytes transferred per frame if the
 * endpoint doesn't tell us.  The output buffer size is a hard limit
 * for devices that use a 6-bit size encoding.
 */
#define UFTDIIBUFSIZE 64
#define UFTDIOBUFSIZE 64

/*
 * Magic constants!  Where do these come from?  They're what Linux uses...
 */
#define	UFTDI_MAX_IBUFSIZE	512
#define	UFTDI_MAX_OBUFSIZE	256

struct uftdi_softc {
	device_t		sc_dev;		/* base device */
	usbd_device_handle	sc_udev;	/* device */

	int			sc_iface_no;
	usbd_interface_handle	sc_iface;	/* interface */

	enum uftdi_type		sc_type;
	u_int			sc_hdrlen;
	u_int			sc_chiptype;

	u_char			sc_msr;
	u_char			sc_lsr;

	device_t		sc_subdev;

	u_char			sc_dying;

	u_int			last_lcr;

};

Static void	uftdi_get_status(void *, int portno, u_char *lsr, u_char *msr);
Static void	uftdi_set(void *, int, int, int);
Static int	uftdi_param(void *, int, struct termios *);
Static int	uftdi_open(void *sc, int portno);
Static void	uftdi_read(void *sc, int portno, u_char **ptr,u_int32_t *count);
Static void	uftdi_write(void *sc, int portno, u_char *to, u_char *from,
			u_int32_t *count);
Static void	uftdi_break(void *sc, int portno, int onoff);

struct ucom_methods uftdi_methods = {
	uftdi_get_status,
	uftdi_set,
	uftdi_param,
	NULL,
	uftdi_open,
	NULL,
	uftdi_read,
	uftdi_write,
};

/* 
 * The devices default to UFTDI_TYPE_8U232AM.
 * Remember to update uftdi_attach() if it should be UFTDI_TYPE_SIO instead
 */
static const struct usb_devno uftdi_devs[] = {
	{ USB_VENDOR_BBELECTRONICS, USB_PRODUCT_BBELECTRONICS_USOTL4 },
	{ USB_VENDOR_FALCOM, USB_PRODUCT_FALCOM_TWIST },
	{ USB_VENDOR_FALCOM, USB_PRODUCT_FALCOM_SAMBA },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_230X },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_232H },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_232RL },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_2232C },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_4232H },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_8U100AX },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_SERIAL_8U232AM },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_MHAM_KW },
	{ USB_VENDOR_FTDI, USB_PRODUCT_FTDI_MHAM_YS },
	{ 

Re: Merging ugen into the usb stack

[Martin Husemann]

On Sat, Dec 16, 2017 at 06:07:42PM -0500, Thor Lancelot Simon wrote:
> On Fri, Dec 15, 2017 at 08:30:00PM +0100, Martin Husemann wrote:
> >  - when libusb takes over controll (as Steffen described) a kernel driver
> >that would have attached (i.e. when the skipping does not happen or
> >the userland application is configured wrong) is detached, so no
> >concurrent access between libusb and a kernel driver can ever happen
> 
> To be safe in general -- particularly for storage devices -- this probably
> has to depend on securelevel.

Yes, and if e.g. a device is open it should reject the request
to transform into a usbgen.

Martin

Re: Merging ugen into the usb stack

[Thor Lancelot Simon]

On Fri, Dec 15, 2017 at 08:30:00PM +0100, Martin Husemann wrote:
>  - when libusb takes over controll (as Steffen described) a kernel driver
>that would have attached (i.e. when the skipping does not happen or
>the userland application is configured wrong) is detached, so no
>concurrent access between libusb and a kernel driver can ever happen

To be safe in general -- particularly for storage devices -- this probably
has to depend on securelevel.

Thor

Re: Merging ugen into the usb stack

[Martin Husemann]

Ok, after playing a bit more with Linux and OpenOCD (and getting kind
help from the openocd mailing list to unbrick my device), I think
I now understand a bit better how it plays together and what could
be done.

So Linux does:

 - on certain fdti devices the first port of the chip is "skipped", as the
   port is reserved for JTAG usage.
 - when libusb takes over controll (as Steffen described) a kernel driver
   that would have attached (i.e. when the skipping does not happen or
   the userland application is configured wrong) is detached, so no
   concurrent access between libusb and a kernel driver can ever happen

It should be pretty easy for us to do something similar. So overall this
proposal turns into:

 - make all "passive" enumeration/discovery and maybe descriptor query
   (as long as it does not change state of the usb device) generically
   available for all usb devices, no matter what driver attached

 - implement the driver detach in libusb (if a driver != ugen has attached)

 - add a quirk table to uftdi listing the JTAG-on-port-X devices and only
   attach ucom on the non-reserved ports

 - add a variation of uftdi that attaches on single interfaces (Wolfgang,
   can you share your code, even if it does not work with -current?), and
   either always use this variant, or use this variant on chips matched
   by above mentioned quirks table.

 - make ugen be able to attach to single/specific interfaces as well (off
   hand I'm not sure this would need code changes, but again, Wolfgang,
   could you make your patches available?)


This should avoid all concurrent access issues in a clearly defined way,
and also should be pretty simple to implement (even if we do not do the
first item initially, it would still make the ftdi JTAGs useable
immediately).

Martin

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi Martin,


I have a Guruplug JTAG device (and right now need to use it to unbrick
one of my Guruplugs after some ... stupid u-boot experiment).


I've got some similar device which also uses a 2 port uftdi, where one
port is wired as a serial interface and the other is used for jtag.

In order to support that, I changed the uftdi driver to match against
an interface instead of the whole device. Thus you could specify

uftdi1 at uhub? port ? configuration ? interface 1
ucom* at uftdi1

and leave interface 0 of uftdi alone, which then resulted in ugen
to attach there.

Unfortunately, this modification has bit rotted since then and
doesn't work in its current state.


I could hack uftdi to allow attaching a ugen child, but that sounds like a
very special hack. Jared suggested to instead make ugen not a separate device,
but globaly fold it into the usb stack. That would also solve similar issues
we have seen with usb scanner devices and ulpts.

So, how should we proceed here?


However, I support the idea of allowing ugen to attach to some
usb device independent of some other driver matching it. Of
course, there needs to be some mutual exclusion between ugen
and the other driver.

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank

Re: Merging ugen into the usb stack

[Stephen Borrill]

On Mon, 11 Dec 2017, Martin Husemann wrote:
[snip]

However, it can not work with the way NetBSD uses ugen devices:

uftdi0 at uhub3 port 2
uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
addr 3
ucom0 at uftdi0 portno 1
ucom1 at uftdi0 portno 2

I can disable the ucom at uftdi0 portno 1, but there is no way to get a ugen
device to attach there.

The uftdi chip itself offers a separate interface for each of the ports,
at that layer there should not be a problem.

I could hack uftdi to allow attaching a ugen child, but that sounds like a
very special hack. Jared suggested to instead make ugen not a separate device,
but globaly fold it into the usb stack. That would also solve similar issues
we have seen with usb scanner devices and ulpts.


This sounds to be related to the requirements of USB remoting 
such as USB-over-IP and Citrix Receiver. With the latter, I may 
choose to access a device using a known virtual channel such as video, in 
which case I would be using the kernel driver. Within my remote session, I 
may choose to use the USB virtual channel which would detach the 
kernel driver and use the native Windows driver within the session.


libusb has libusb_detach_kernel_driver() which NetBSD does not have the 
functionality to support. The ability to detach a kernel driver, then 
attach a ugen in its place would be useful (good for rump device driver 
development too!). However, as Taylor says, with care it may be possible 
to maintain both interfaces.


--
Stephen

Re: Merging ugen into the usb stack

[Greg Troxel]

Martin Husemann  writes:

> On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote:
>> I wonder if we should be attaching drivers to endpoints, rather than
>> devices.
>
> This is the drivers decision (we have drivers that do it).
>
> However, ugen is not able to attach to a single interface itself (currently).

Well, I guess I think it's better to allow drivers to attach to single
interfaces in general, than to make ugen special and try to integrate
it.  But I haven't looked at things enough to justify that opinion.



signature.asc
Description: PGP signature

Re: Merging ugen into the usb stack

[Martin Husemann]

On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote:
> I wonder if we should be attaching drivers to endpoints, rather than
> devices.

This is the drivers decision (we have drivers that do it).

However, ugen is not able to attach to a single interface itself (currently).

Martin

Re: Merging ugen into the usb stack

[Greg Troxel]

Martin Husemann  writes:

> However, it can not work with the way NetBSD uses ugen devices:
>
> uftdi0 at uhub3 port 2
> uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
> addr 3
> ucom0 at uftdi0 portno 1
> ucom1 at uftdi0 portno 2
>
> I can disable the ucom at uftdi0 portno 1, but there is no way to get a ugen
> device to attach there.
>
> The uftdi chip itself offers a separate interface for each of the ports,
> at that layer there should not be a problem.

I wonder if we should be attaching drivers to endpoints, rather than
devices.  It seems fairly common to have multiple endpoints doing
different things (among more-than-one-thing devices), rather than
multiple devices behind a hub.

Letting ugen attach to endpoints that drivers don't deal with seems like
an entirely reasonable solution, and it seems to have lower risk of
problems from things we can't predict.

I also wonder what other operating systems do here (beyond point
solutions that they've had to do).


signature.asc
Description: PGP signature

Re: Merging ugen into the usb stack

[Taylor R Campbell]

> Date: Mon, 11 Dec 2017 12:44:32 +0100
> From: Martin Husemann 
> 
> I could hack uftdi to allow attaching a ugen child, but that sounds
> like a very special hack. Jared suggested to instead make ugen not a
> separate device, but globaly fold it into the usb stack. That would
> also solve similar issues we have seen with usb scanner devices and
> ulpts.

Sounds reasonable as long as we clearly define the semantics of
opening the ugen device as it affects any other usage of the device,
and as long as Someone^TM takes the time to carefully implement that
semantics.