From owner-freebsd-hackers@freebsd.org Fri Jul 17 14:06:11 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8CB20365DBE for ; Fri, 17 Jul 2020 14:06:11 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (Client CN "iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7XwK5kTGz46RZ; Fri, 17 Jul 2020 14:06:09 +0000 (UTC) (envelope-from bmcgover@cisco.com) IronPort-PHdr: =?us-ascii?q?9a23=3AeNOpNBErrVgJAZvUZvtGyZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gebU5jd6O5EgvaQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFPPpH6u7TcOXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAACarxFf/4MNJK1dAxYEAQEBAQE?= =?us-ascii?q?BAQEBAQMBAQEBEgEBAQECAgEBAQFAgUqBIwEuIy4Hb1gvLId5A41Gk3KEbIJ?= =?us-ascii?q?TA1ULAQEBDAEBIwoCBAEBhEwCghkCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIV?= =?us-ascii?q?vAQEBAwESFRkBATcBBAsCAQgRBAEBAS4yHQgCBA4FCBqDBYF+TQMOIAEOn0Q?= =?us-ascii?q?CgTmIYXSBATODAQEBBYEyAYNQGIIOAwaBOAGCaYNIhkAagUE/gRFDgk0+g3U?= =?us-ascii?q?qIB8MGoMCgi2Paok4Jpt1CoJdiFaGNIp4n0OcJJRWAgQCBAUCDgEBBYFqI4F?= =?us-ascii?q?XcBWDJFAXAg2OHgwXg06FFIVCdDcCBggBAQMJfIxBgjUBAQ?= X-IronPort-AV: E=Sophos;i="5.75,362,1589241600"; d="scan'208,217";a="789667469" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2020 14:06:07 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06HE67KI016245 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jul 2020 14:06:07 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 09:06:07 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 09:06:06 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jul 2020 09:06:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=heD93iyrt+6A7yx3gPw2alvQ50bJbRyE8j7oP4VXHvdKp6HhfaYWT2FPj6UcDFLf3u12ioIpwxUnbItbk/XfRWvBaOzCdL9VRDZ9D2/WO6aVE0BMRwMNu0JwGaYHfiHDKswJSLy4uK5OvZgBNAuGA0mpFlyGXvWB9dJDIP2qz1Grq8GuMvuz+RLIBGCjvMkTq/2TuRSlLeiHn0qimWfFv3GH9RFR6Xx5l758MjRC5VR8cZw3CPrC2ZcmCS6MLSDnMM5HKgkbXer36bwo7jgqXhdDoXwZebS/WESY+TK7/lMS66FA84/yKl3bdvTwXrbQ2qNJb01ilKM8IXcDX8ocFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nB2AMed5HKyIxwdFsD8BcHW1qhvTw7Jlj7Ho8vl9JL4=; b=N+hrAvnSr66bLwqXnmlll+yQrzFQhL+MT+BhyiPGpHaBSxXnXwyCtcEmN0unjpFi3U9Mtgk9aJBZvDbR0Z5ZKUpHUQ7z+La2de0gkA7nD0dLUfr/3++LYynIJlWS+2Pj5LnrEAlbqf/KkBW+nh0vOVPyJGCc01f32hsBPdm0l5KTsrzOF4crA63b6EHqdy1B8bNAFIztkbuAhp8xYe/WWKnn7pzQj6MpH5vioOiE5uSAoVgHkPY+h8DCoACqIea4MK2LLEnq6Gaf2EIhFBkD/YVssPEcQyXMjRSbHAeJnDmFxdzBDnSkCcVmp+qS30QIMxxqvDIJJ/A1yLCgr+0l+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none Received: from BL0PR11MB3442.namprd11.prod.outlook.com (2603:10b6:208:68::19) by MN2PR11MB4480.namprd11.prod.outlook.com (2603:10b6:208:191::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Fri, 17 Jul 2020 14:06:05 +0000 Received: from BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539]) by BL0PR11MB3442.namprd11.prod.outlook.com ([fe80::844f:50d2:7986:e539%7]) with mapi id 15.20.3174.026; Fri, 17 Jul 2020 14:06:05 +0000 From: "Brian Mcgovern (bmcgover)" To: John-Mark Gurney CC: Ian Lepore , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: Question on structure of USB (specifically USB Serial) stack Thread-Topic: Question on structure of USB (specifically USB Serial) stack Thread-Index: AQHWW66ajFBPEQF6REi43/I0wUQCzKkKtsuAgAAT3YCAAAGJv4AAHA8AgADjcso= Date: Fri, 17 Jul 2020 14:06:05 +0000 Message-ID: References: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> , <20200717001834.GU4213@funkthat.com> In-Reply-To: <20200717001834.GU4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:d07f:d140:547b:bff9:d6a8:7b19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ab72d3a-c6c2-4082-89ef-08d82a5a8bc3 x-ms-traffictypediagnostic: MN2PR11MB4480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mFs1MQywqt+rHwbjGpmdinDkkQyleIoUd6mUC94Oebd5Jt+HZXdfk5pn5QJNFanHk4Rjre99nIctAWBeN7LrzLheWxb7eLAlYMgKMdrh2ok7Lgn7QEKux1onxXOIHq4iek7J/qGSuk5zezPPvfHSEi5POIX00Ou1a/zU+VCcJhoTUMh6HpAU4H5jWvtwrYgOKEW5cunXSwdvIHfeHmV3DESNRM38NKtOE5OH9dw4POvwtH3lSxiVlNyxCQxJPzNkf7Innhufr0Fz0qV1zfNBYiiG8bLmyfhosKdOYuNu+4rVUTFQsDaf6x4SIRojMWqt/0n4gFATBJvoZ6znwEB8Q9Os9WWS9YVy70HDhakqqAjCVfU4E5E+z/GFhhERh60LeIqLs8EHcy6iTzFOsVZ0Ag== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3442.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(346002)(39860400002)(396003)(83380400001)(2906002)(86362001)(7696005)(6506007)(53546011)(478600001)(966005)(186003)(9686003)(55016002)(4326008)(19627405001)(8676002)(52536014)(8936002)(5660300002)(66946007)(166002)(66446008)(33656002)(76116006)(316002)(71200400001)(66556008)(54906003)(64756008)(6916009)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XiHOEpVCgl6Lw+sukdLg21XRTJ9rSCg/j7Fg5IkO/AQ8v2uallxCsp7HnRGQH5KYe+gZ6LZfDM7+DderAE4+/gn+ZZyHdX/JZIw0VWyd80JGPpTiosgjkA09TUVNFxUNy9LaIL1ioUbuuhg6roBTGu4555buit2KAKQ8Ptl/1WC89Otm1hXB/aeAztitV/qZIyPV93YuqF/IhSm4YlvqIp866PQzyywOPly4Tpi+prluFI4z4Xl2jW636bBYbV8XkJHca3kcOZOxqWdbS08frI6oQqlhNAfUE2iX8eb2dTcbluCq/XfcGGf9RwrAf43yMKJMim39UqnzdN/GH2ni/khyhs15npBESCmeNqRah/LC8K+GDWwtNv846avqSlcEPtCNLYChpo+5hmGMTPpTvAZTKXfEsv6W9h/a3P3eq8rSEPxXEqEhRVvPuRtn+OxfX73zgS44wGD/DO3ZHJtHYpqIhRqh5ssVc+8HQFaA9RVvg9Q+eulUO8pP1Ew5VshV+gPGcyV5kodePmKdguLHutq3VxhEjCHuqZ3mjijTPmVAOFCryljTU3EV33gEefJv x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3442.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ab72d3a-c6c2-4082-89ef-08d82a5a8bc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 14:06:05.2412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U/aiG/CB881ERNIpb206fDExlfHweK5MXIX4rE+uKr2NzpqMRyoc1/R9xeEcOZ/encnJM5FpuBtbTEq59w2sCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4480 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-1.cisco.com X-Rspamd-Queue-Id: 4B7XwK5kTGz46RZ X-Spamd-Bar: ------------ X-Spamd-Result: default: False [-12.23 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; R_DKIM_ALLOW(-0.20)[cisco.com:s=iport,cisco.onmicrosoft.com:s=selector2-cisco-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.37.86.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_DKIM_ARC_DNSWL_HI(-1.00)[]; NEURAL_HAM_LONG(-1.01)[-1.009]; RWL_MAILSPIKE_GOOD(0.00)[173.37.86.78:from]; WHITELIST_SPF_DKIM(-3.00)[cisco.com:d:+,cisco.com:s:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cisco.com:+,cisco.onmicrosoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[cisco.com,quarantine]; DWL_DNSWL_MED(-2.00)[cisco.com:dkim]; NEURAL_HAM_SHORT(-1.71)[-1.714]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:109, ipnet:173.37.64.0/18, country:US]; RCVD_COUNT_SEVEN(0.00)[8]; RCVD_IN_DNSWL_HI(-0.50)[173.37.86.78:from] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 14:06:11 -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 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 Sent: Thursday, July 16, 2020 8:18 PM To: Brian Mcgovern (bmcgover) Cc: Ian Lepore ; Hans Petter Selasky ; fr= eebsd-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 ; Brian Mcgovern (bmcgover) ; 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."