Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jul 2020 20:14:26 +0000
From:      "Brian Mcgovern (bmcgover)" <bmcgover@cisco.com>
To:        Daniel Ebdrup Jensen <debdrup@FreeBSD.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>
Cc:        Ian Lepore <ian@freebsd.org>, Hans Petter Selasky <hps@selasky.org>
Subject:   Re: Question on structure of USB (specifically USB Serial) stack
Message-ID:  <BL0PR11MB3442AD4793BA13B235B83152C57C0@BL0PR11MB3442.namprd11.prod.outlook.com>

next in thread | raw e-mail | index | archive | help

I installed both. The script looks like its working, the patch, not quite. =
To explain, I did a quick log with the script to print out $1-$4.

What I'm seeing in the log is this....

attach uftdi0 A9L5QT3S U384
attach uftdi1 A978RDEY U384
attach utfdi2 A9LITAWI U384

It appears the drivers are mapping all of the USB devices to /dev/cuaU384 a=
nd friends. I am seeing appropriate entities in /dev/usb - e.g. I'm getting=
 0.4.[0-2], 0.5.[0-2], and 0.6.[0-2]. This might be due to me not reverting=
 all my own changes back, so to be sure, I'm going to grab clean source and=
 reapply the patch, but I thought I'd mention it. Good to know there is suc=
cess elsewhere.

          -B

________________________________
From: Daniel Ebdrup Jensen
Sent: Friday, July 17, 2020 2:45 PM
To: freebsd-hackers@freebsd.org
Cc: Brian Mcgovern (bmcgover); Ian Lepore; Hans Petter Selasky
Subject: Re: Question on structure of USB (specifically USB Serial) stack

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) stac=
k
>>
>> 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 th=
e
>> > > > void *, as it appears each of the devices that use ucom as the bas=
e
>> > > > 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."
>_______________________________________________
>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"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BL0PR11MB3442AD4793BA13B235B83152C57C0>