Date: Fri, 17 Jul 2020 20:45:56 +0200 From: Daniel Ebdrup Jensen <debdrup@FreeBSD.org> To: freebsd-hackers@freebsd.org Cc: "Brian Mcgovern (bmcgover)" <bmcgover@cisco.com>, Ian Lepore <ian@freebsd.org>, Hans Petter Selasky <hps@selasky.org> Subject: Re: Question on structure of USB (specifically USB Serial) stack Message-ID: <20200717184556.2ad5wby3demdxeo4@nerd-thinkpad.local> In-Reply-To: <20200717183034.GW4213@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> <BL0PR11MB344284FEDD14FF304E0579DCC57C0@BL0PR11MB3442.namprd11.prod.outlook.com> <20200717183034.GW4213@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--w4gtqdzvg7aa4kp7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2020 at 11:30:34AM -0700, John-Mark Gurney wrote: >Brian Mcgovern (bmcgover) wrote this message on Fri, Jul 17, 2020 at 14:06= +0000: >> 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 = once over, it looks like it'll meet my needs - pretty much keeping the devi= ce names unique and identifiable during reboots and detach/reattach events.= If I see any issues, I'll let you know. > >Just for clarification, the script does not require the patch to be >applied. That patch in the review was a separate effort. > >The script should likely work on past FreeBSD releases as well, but >I haven't tested it on them. > I'm using it on 12.1-RELEASE, and it works fine there. :) >> ________________________________ >> 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>;= freebsd-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 aski= ng 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 f= ormatting is that if one gets rebooted or someone hits the power cord, it'l= l bounce fast enough that it'll come back with a different name. As a resul= t, 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 co= uld at least get an alias that mapped to the port the device was in, that w= ould be sufficient to find the "right one", regardless of what the cuaUX na= mes 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 w= ith all of the devices that share ucom. However, if what I'm seeing as a hu= rdle 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.o= rg> >> > Subject: Re: Question on structure of USB (specifically USB Serial) st= ack >> > >> > 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? > >--=20 > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --w4gtqdzvg7aa4kp7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8R8eRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87ooHggAnUAK0eoyuNQXcCxt/c4F5DICTcRjJ5tV3DoW/rAfLxua3Xrt/ymMiYYF hHPGHEzca6D3zVWDMmd9EC2P5nmH3UTPLm3lejBn7uCzxlFM6eOowel45S3y3U4c cGDQYbPy48CS50OjL8zdbfRHNAS/7EIrhSLubUKdDz7aPIpNLCZZNa9X7a2VofHd M1FCts6LfIrwvUWZmwfEE/yo0Q3/XiUHu68YWQK0I+ovrXGQT5CS6Rm2BkTumh9r 18Y2DqZRqWFbeV8DBXZrzvljdwZ6mEb7PjIR16A0cjqWufb02i7SVPt1ceBXVxHI f6nw/2vqO6Is+A4BROvAxvMXKMZ6WQ== =Q4M2 -----END PGP SIGNATURE----- --w4gtqdzvg7aa4kp7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200717184556.2ad5wby3demdxeo4>