Date: Thu, 16 Jul 2020 17:18:34 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: "Brian Mcgovern (bmcgover)" <bmcgover@cisco.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: <20200717001834.GU4213@funkthat.com> In-Reply-To: <BL0PR11MB344286D12DDD48451E274141C57F0@BL0PR11MB3442.namprd11.prod.outlook.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 more consistent name, similar to /dev/usb, based on the tree of struct usb_device entries and their respective addresses. What I see with the cuaUXX formatting is that if one gets rebooted or someone hits the power cord, it'll bounce 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 would 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 appears 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 hurdle 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) <bmcgover@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?20200717001834.GU4213>