From owner-freebsd-hackers@freebsd.org Thu Jul 16 23:18:57 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 971A837044C for ; Thu, 16 Jul 2020 23:18:57 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (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 4B79Dc28xNz4D9N; Thu, 16 Jul 2020 23:18:56 +0000 (UTC) (envelope-from bmcgover@cisco.com) IronPort-PHdr: =?us-ascii?q?9a23=3ACapZYxMn6/6Ww1VghGwl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw93lHTUIjR8P4CjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8jkalDYuXH06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABT3xBf/4YNJK1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE5AgEBAQELAYEiAS4jLgeBRy8sh3kDjUa?= =?us-ascii?q?TcoRsglMDVQsBAQEMAQEtAgQBAYRMAoITAiQ3Bg4CAwEBCwEBBQEBAQIBBgR?= =?us-ascii?q?thVsMhW8BAQEBAxIVGQEBOA8CAQgRBAEBAS4yHQgCBAESCBqFA00DLgGgRwK?= =?us-ascii?q?BOYhhdIEBM4MBAQEFhUUYgg4JgTgBgmmGBIQEGoFBP4ERQ4JNPoN1KiCDR4I?= =?us-ascii?q?tmR4mm3UKgl2PCYp4n0GRfJ59AgQCBAUCDgEBBYFpJIFXcBWDJFAXAg2OHgw?= =?us-ascii?q?Xg06KVnQ3AgYIAQEDCXyMdII1AQE?= X-IronPort-AV: E=Sophos;i="5.75,360,1589241600"; d="scan'208,217";a="513039200" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2020 23:18:54 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 06GNIsvd021272 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jul 2020 23:18:54 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 18:18:54 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 19:18:52 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 16 Jul 2020 18:18:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f/51Cs8Ly8Ke5Wf3IOsVoVv2tsNda0tKmjgLGrD1N/ub8IODexmKsg4yLzDgrQbkBS7B5KNqWlucBjZhmowhLUqCUXARxaWIFHq8ARn4tXLXxZ+868XX5gRse+yew3IoIttKAxAY1laZdKGM4D0xMU9xm2kwzncV4GWKku4enLN7i/ShoD/Vbf143s/SK6J3niSQfSfI8MHqJWVXDlbjIfCAzU9O2lqihUUK5kE6QL92+RI4mNAosLpydWFbw4u56toADhb/L6qUiWXZe3yXsY4LcuNO9qL7Mu4IL7iiCYmZszYqqaukY4SLN4RSfZboNy6KckuJAW1aUzTDGYGImQ== 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=qBy+orJ62vUT/4zWGT35LZ1hbJsPuvSXzFR4f5sbfH4=; b=nPStCt2pLFKKULUm4nPCQ/U/7We7M7n/BGaX3qbiYNlOSQ6GEDMvvQHeiD3unXk3mnUvV42AutXXjre7NPOE7fPRSy6ZAKSDn/K521ItIb3BNl+yUitsQnFopkHhSmFg2DNC8PqWa07zvi04L/mCjef0jmTn7kl9chz1CDXPnbaT2Qlwt0wsufaOKdBpd8tfsR6F2LOnwNNcFsR9WeWfg/j+Dj4TeFV6AM0heZ2mdf0EquYiK9V3yIAxcBQNCcLpguTIYq/2gAVoTV0p1YyJ2OBLEimqKMW1qn+N2EDmnxWgEuuwjnsqPw9ypa7y5Xv6IlojY5TTw/eAAF7eVNXZLA== 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 BL0PR11MB3124.namprd11.prod.outlook.com (2603:10b6:208:30::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Thu, 16 Jul 2020 23:18:51 +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; Thu, 16 Jul 2020 23:18:51 +0000 From: "Brian Mcgovern (bmcgover)" To: 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/I0wUQCzKkKtsuAgAAT3YCAAAGJvw== Date: Thu, 16 Jul 2020 23:18:51 +0000 Message-ID: References: , <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> In-Reply-To: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> 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: 4006a12b-e38a-496d-f8da-08d829de99e5 x-ms-traffictypediagnostic: BL0PR11MB3124: 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: CBdnCklatAH1e0o8fljl4jOF6eHpSfBbQYBaELNqIl8u9RxZBIVnFl60wqGAUF1Mqk/bAh9m0U/OqoBEk05HcEKk7CAXbQJsOVFTntRzogMeYvhXZm+sF2AqcCCSuB8dIhUWaguChMeK3hQWKlMuFYEVYXFOQH6bP7IPSGlt/tzp/LXZFsZV7I8CEyDF3PIREeepocU7jvHJxinGLUbkjL9JVOgT9N/RDwIPlNqJARYs7Z8XRZZoGn52QWmPgRyDirCF/6c1oJgIv4ODIMYGR30zFANB1cx5rD9QtlHJl6UO57YF8vEYzzh6NAgzvHQ4PUkvKl4qFMyXB/EzuCXD3Q== 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)(39860400002)(136003)(376002)(366004)(396003)(346002)(9686003)(86362001)(55016002)(83380400001)(8676002)(5660300002)(71200400001)(52536014)(8936002)(7696005)(6506007)(478600001)(53546011)(186003)(19627405001)(66446008)(66476007)(2906002)(64756008)(316002)(66556008)(110136005)(33656002)(76116006)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 29khqv+tqCWSMtZb+36o/iNUi0Ifo/Qf9J/rpOhniFcOKWwuQRAHQxLIYNuS8V2I2NPL5izzNxiiOxJ101W6yIXEPZUq4Np1Pp/HSlzmuhhhjIHFzLESyszQFoJwspKiDv7BYi9YsC5vX9auJwEjuG0P8oLi3rx4oYifSVG1hCMt22yH0c9DSBV8uLb2JgE+CZZdlcGzP/5D6+shr3h9m6qLe5ozibBTswlBWkfwYbVvdpRHG1RuLxWMPTp0orB5DtjMWyDQa67GPgkdyK9oXDtlBUiHJJ/AmppbNKtUU1zji+7kV9bv+hdCg7pVpgKfWrF6tBtRhMavDeYfyxdIpizGFnIya8dDapgMjwfZtwHvkGEuqDUGdGyYDp1e7C+kaNo0mr1+MoWSeSeUvkvBVjllOHQ+A6ViyS+I6yRG8RWjQxJl6ev3j3+1hkmRURwqfAhX/o75EejYrYK9Gf18kOLV8AFPZEJtAD5MbkNabq1X9HcIVKFzyCeUXZYOQBjQN/gvGaN7lSSj99UPj76wHixbFrLeA8kmJxdSRxdtOTCZzPT/B2n0gD2hDFSZfBBl 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: 4006a12b-e38a-496d-f8da-08d829de99e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 23:18:51.3740 (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: deN32NNT3rMdG1Ke2wjjuTl7CNzocwBMpg4kBdQ/ceXXxjJ3d11KUl6I0vMiZvvdGPZuW+zHfWpeXUJexVvWHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3124 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com X-Rspamd-Queue-Id: 4B79Dc28xNz4D9N X-Spamd-Bar: ----------- X-Spamd-Result: default: False [-11.90 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; 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)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.37.142.64/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_DKIM_ARC_DNSWL_HI(-1.00)[]; NEURAL_HAM_LONG(-1.02)[-1.022]; DWL_DNSWL_MED(-2.00)[cisco.com:dkim]; 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]; NEURAL_HAM_SHORT(-1.36)[-1.359]; 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.128.0/19, country:US]; RCVD_COUNT_SEVEN(0.00)[8]; RWL_MAILSPIKE_VERYGOOD(0.00)[173.37.142.88:from]; RCVD_IN_DNSWL_HI(-0.50)[173.37.142.88: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: Thu, 16 Jul 2020 23:18:57 -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 th= e 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_devic= e entries and their respective addresses. What I see with the cuaUXX format= ting is that if one gets rebooted or someone hits the power cord, it'll bou= nce fast enough that it'll come back with a different name. As a result, ev= en though we can get a consistent layout on power up, if you come back a we= ek or two later, everything is out of order. I was hoping that if I could a= t 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 w= ere doing. The reason for picking this particular section of the code is that it appea= rs I can get most of the work done locally and have similar behavior with a= ll 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. -B ________________________________ From: Ian Lepore 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? -- Ian