Date: Fri, 17 Jul 2020 14:06:05 +0000 From: "Brian Mcgovern (bmcgover)" <bmcgover@cisco.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Ian Lepore <ian@freebsd.org>, Hans Petter Selasky <hps@selasky.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Question on structure of USB (specifically USB Serial) stack Message-ID: <BL0PR11MB344284FEDD14FF304E0579DCC57C0@BL0PR11MB3442.namprd11.prod.outlook.com> In-Reply-To: <20200717001834.GU4213@funkthat.com> References: <BL0PR11MB34425EBBCF3E674E6A7766E1C57F0@BL0PR11MB3442.namprd11.prod.outlook.com> <c20edccb-616b-aedf-6a60-e4857341f2fb@selasky.org> <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> <BL0PR11MB344286D12DDD48451E274141C57F0@BL0PR11MB3442.namprd11.prod.outlook.com>, <20200717001834.GU4213@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney said Look here: https://reviews.freebsd.org/D21886 I've added a script, linked here: https://www.funkthat.com/~jmg/FreeBSD/usbserialsn There are two modes, if the device has a serial number, that will be used. If the device has an empty serial number, it's usb bus and port number path will be used. Thank you. I'll take a look at the patch and script today. From a quick onc= e over, it looks like it'll meet my needs - pretty much keeping the device = names unique and identifiable during reboots and detach/reattach events. If= I see any issues, I'll let you know. -Brian ________________________________ From: John-Mark Gurney <jmg@funkthat.com> Sent: Thursday, July 16, 2020 8:18 PM To: Brian Mcgovern (bmcgover) <bmcgover@cisco.com> Cc: Ian Lepore <ian@freebsd.org>; Hans Petter Selasky <hps@selasky.org>; fr= eebsd-hackers@freebsd.org <freebsd-hackers@freebsd.org> Subject: Re: Question on structure of USB (specifically USB Serial) stack FreeBSD Hackers wrote this message on Thu, Jul 16, 2020 at 23:18 +0000: > Ian Lepore said: > > This seems to me to be one of those situations where answering the > exact question that was asked isn't the right thing to do. Instead it > needs to be answered with another question: What it is you're really > trying to accomplish, and why do you think doing this crazy-unsafe > casting is the only way to get it done? > > I get its crazy unsafe for the non-specific case. That is why I'm asking = the question - to see if there is a good way to get the info. > > What I'm hoping to do is pin some USB devices with FTDI interfaces to mor= e consistent name, similar to /dev/usb, based on the tree of struct usb_dev= ice entries and their respective addresses. What I see with the cuaUXX form= atting is that if one gets rebooted or someone hits the power cord, it'll b= ounce fast enough that it'll come back with a different name. As a result, = even though we can get a consistent layout on power up, if you come back a = week or two later, everything is out of order. I was hoping that if I could= at least get an alias that mapped to the port the device was in, that woul= d be sufficient to find the "right one", regardless of what the cuaUX names= were doing. > > The reason for picking this particular section of the code is that it app= ears I can get most of the work done locally and have similar behavior with= all of the devices that share ucom. However, if what I'm seeing as a hurdl= e is really a wall, I'm open to better ideas. Look here: https://reviews.freebsd.org/D21886 I've added a script, linked here: https://www.funkthat.com/~jmg/FreeBSD/usbserialsn There are two modes, if the device has a serial number, that will be used. If the device has an empty serial number, it's usb bus and port number path will be used. > Sent: Thursday, July 16, 2020 6:32 PM > To: Hans Petter Selasky <hps@selasky.org>; Brian Mcgovern (bmcgover) <bmc= gover@cisco.com>; freebsd-hackers@freebsd.org <freebsd-hackers@freebsd.org> > Subject: Re: Question on structure of USB (specifically USB Serial) stack > > On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > > wrote: > > > All, > > > I'm doing some playing with the ucom code, and I'm down to a > > > link in the data that I'm just not confident I've parsed the code > > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > > structure for the device used elsewhere in the USB code. The > > > specific devices I'm working with are USB->RJ 45 cables with a > > > built in FTDI chip, in case this matters > > > > > > It appears that the ucom_super_softc and ucom_softc structures > > > are available. From looking around the code, it appears the > > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > > structure in uftdi.c (for the uftdi case), so the path would be > > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > > void *, as it appears each of the devices that use ucom as the base > > > have sc_udev in a different part of their structure, meaning I'm > > > likely going to crash the system if I plan on it being an FTDI > > > device, and its not. Is there a callback or a canonical mechanism > > > for accessing this part of the structure given a starting point of > > > the ucom_softc? Alternatively, are there any well defined > > > attributes I can use to figure out what that void* is pointing to, > > > or at least conditionalizing the code so I can dereference it > > > correctly? > > > > Hi, > > > > Usually using void pointers this way works fine, as long as you are > > careful. There is also something called __containerof() which can be > > used to get the pointer to a structure based on the pointer to a > > structure inside that structure, thinking of the struct ucom_softc, > > which is type-safe. > > > > > > You still can't just blindly cast ucom_softc->sc_parent back to a > struct uftdi_softc in ucom_tty_attach() because it will crash and burn > if any non-ftdi serial device is attached. Using __container_of() > doesn't change that in any way -- you must already know for certain > that the type pointed to by the pointer is the type you name in the > container_of() invocation. > > This seems to me to be one of those situations where answering the > exact question that was asked isn't the right thing to do. Instead it > needs to be answered with another question: What it is you're really > trying to accomplish, and why do you think doing this crazy-unsafe > casting is the only way to get it done? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BL0PR11MB344284FEDD14FF304E0579DCC57C0>