From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Kunz Subject: Re: serdev: How to attach serdev devices to USB based tty devices? Date: Tue, 21 Aug 2018 18:32:42 +0200 Message-ID: References: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Linux-MIPS , Xue Liu , Ben Whitten , devicetree@vger.kernel.org, "netdev@vger.kernel.org" , Oliver Neukum , Alexander Graf , "LoRa_Community_Support@semtech.com" , Jian-Hong Pan , Stefan Rehm , "linux-arm-kernel@lists.infradead.org" To: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Rob Herring , "linux-serial@vger.kernel.org" , linux-usb@vger.kernel.org Return-path: In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> Content-Language: de-DE List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: netdev.vger.kernel.org QW0gMTQuMDguMjAxOCB1bSAwNDoyOCBzY2hyaWViIEFuZHJlYXMgRsOkcmJlcjoKPiBIaSBSb2Ig ZXQgYWwuLAo+IAo+IEZvciBteSBMb1JhIG5ldHdvcmsgZHJpdmVyIHByb2plY3QgWzFdIEkgaGF2 ZSBmb3VuZCB5b3VyIHNlcmRldgo+IGZyYW1ld29yayB0byBiZSBhIHZhbHVhYmxlIGhlbHAgZm9y IGRlYWxpbmcgd2l0aCBoYXJkd2FyZSBtb2R1bGVzCj4gZXhwb3Npbmcgc29tZSB0ZXh0dWFsIG9y IGJpbmFyeSBVQVJUIGludGVyZmFjZS4KPiAKPiBJbiBwYXJ0aWN1bGFyIG9uIGFybSg2NCkgYW5k IG1pcHMgdGhpcyBhbGxvd3MgdG8gZGVmaW5lIGFuIHVubGltaXRlZAo+IG51bWJlciBvZiBzZXJk ZXYgZHJpdmVycyBbMl0gdGhhdCBhcmUgYXNzb2NpYXRlZCB2aWEgdGhlaXIgRGV2aWNlIFRyZWUK PiBjb21wYXRpYmxlIHN0cmluZyBhbmQgY2FuIG9wdGlvbmFsbHkgYmUgY29uZmlndXJlZCB2aWEg RFQgcHJvcGVydGllcy4KPiAKPiBBbmQgaW4gdGhlb3J5IGl0IHNlZW1zIHNlcmRldiBoYXMgYWxz byBncm93biBzdXBwb3J0IGZvciBBQ1BJLgo+IAo+IE5vdywgYSBncm93aW5nIG51bWJlciBvZiB2 ZW5kb3JzIGFyZSBwbGFjaW5nIHN1Y2ggbW9kdWxlcyBvbiBhIFVTQiBzdGljawo+IGZvciBlYXN5 IGV2YWx1YXRpb24gb24geDg2XzY0IFBDIGhhcmR3YXJlLCBvciBhcmUgZGVzaWduaW5nIG1QQ0ll IG9yIE0uMgo+IGNhcmRzIHVzaW5nIHRoZWlyIFVTQiBwaW5zLiBXaGlsZSBJIGRvIG5vdCB5ZXQg aGF2ZSBhY2Nlc3MgdG8gc3VjaCBhCj4gZGV2aWNlIG15c2VsZiwgaXQgaXMgbXkgdW5kZXJzdGFu ZGluZyB0aGF0IGRldmljZXMgd2l0aCBVU0ItVUFSVCBicmlkZ2UKPiBjaGlwc2V0cyAoZS5nLiwg RlRESSkgd2lsbCBzaG93IHVwIGFzIC9kZXYvdHR5VVNCeCBhbmQgZGV2aWNlcyB3aXRoIGFuCj4g TUNVIGltcGxlbWVudGluZyB0aGUgQ0RDIFVTQiBwcm90b2NvbCAoZS5nLiwgUGljby1jZWxsIGdh dGV3YXkgPSBwaWNvR1cpCj4gd2lsbCBzaG93IHVwIGFzIC9kZXYvdHR5QUNNeC4KPiBPbiB0aGUg UmFzcGJlcnJ5IFBpIEkndmUgc2VlbiB0aGF0IERldmljZSBUcmVlIG5vZGVzIGNhbiBiZSB1c2Vk IHRvIHBhc3MKPiBpbmZvcm1hdGlvbiB0byBvbi1ib2FyZCBkZXZpY2VzIHN1Y2ggYXMgTUFDIGFk ZHJlc3MgdG8gRXRoZXJuZXQgY2hpcHNldCwKPiBidXQgdGhhdCBkb2VzIG5vdCBzZWVtIGFsbCB0 aGF0IHVzZWZ1bCBmb3IgcGFzc2luZyBhIHNlcmRldiBjaGlsZCBub2RlCj4gdG8gaG90LXBsdWdn ZWQgZGV2aWNlcyBhdCB1bnByZWRpY3RhYmxlIGh1Yi9wb3J0IGxvY2F0aW9uICh3aGVyZSBpdAo+ IHNob3VsZCBub3QgaW50ZXJmZXJlIHdpdGggcmVndWxhciBVU0ItVUFSVCBjYWJsZXMgZm9yIGRl YnVnZ2luZyksIG5vcgo+IHdvdWxkIGl0IGhlbHAgQUNQSSBiYXNlZCBwbGF0Zm9ybXMgc3VjaCBh cyB4ODZfNjQuCj4gCj4gTXkgaWRlYSB0aGVuIHdhcyB0aGF0IGlmIHdlIGhhZCBzb21lIHVuaXF1 ZSBjcml0ZXJpYSBsaWtlIHZlbmRvciBhbmQKPiBwcm9kdWN0IElEcyAob3Igd2hhdGV2ZXIgaXMg c3VwcG9ydGVkIGluIHVzYl9kZXZpY2VfaWQpLCB3ZSBjb3VsZCB3cml0ZQo+IGEgdXNiX2RyaXZl ciB3aXRoIHN1aXRhYmxlIFVTQl9ERVZJQ0UqKCkgbWFjcm8uIEluIGl0cyBwcm9iZSBmdW5jdGlv biB3ZQo+IGNvdWxkIGNhbGwgaW50byB0aGUgZXhpc3RpbmcgdHR5IGRyaXZlcidzIHByb2JlIGZ1 bmN0aW9uIGFuZCBhZnRlcndhcmRzCj4gdHJ5IGNyZWF0aW5nIGFuZCBhdHRhY2hpbmcgdGhlIGFw cHJvcHJpYXRlIHNlcmRldiBkZXZpY2UsIGkuZS4gYSBmaXhlZAo+IFVTQi10by1zZXJkZXYgZHJp dmVyIG1hcHBpbmcuIFByb2JsZW0gaXMgdGhhdCBtb3N0IGRldmljZXMgZG9uJ3Qgc2VlbSB0bwo+ IGltcGxlbWVudCBhbnkgdW5pcXVlIGlkZW50aWZpZXIgSSBjb3VsZCBtYWtlIHRoaXMgZGVwZW5k IG9uIC0gZWl0aGVyIGJ5Cj4gdXNpbmcgYSBzdGFuZGFyZCBGVDIzMi9GVDIyMzIvQ0gzNDBHIGNo aXAgb3IgYnkgdXNpbmcgU1RNaWNyb2VsZWN0cm9uaWNzCj4gdmlydHVhbCBjb20gcG9ydCBpZGVu dGlmaWVycyBpbiBDREMgZmlybXdhcmUgYW5kIG9ubHkgZGlmZmVyaW5nIGluIHRoZQo+IHRleHR1 YWwgZGVzY3JpcHRpb24gWzNdIHRoZSB1c2JfZGV2aWNlX2lkIGRvZXMgbm90IHNlZW0gdG8gbWF0 Y2ggb24uCj4gCj4gVGhlIG9idmlvdXMgc29sdXRpb24gd291bGQgb2YgY291cnNlIGJlIGlmIGhh cmR3YXJlIHZlbmRvcnMgY291bGQgcmV2aXNlCj4gdGhlaXIgZGVzaWducyB0byBjb25maWd1cmUg RlRESS9ldGMuIGNoaXBzIHVuaXF1ZWx5LiBJIGhlYXIgdGhhdCB0aGF0Cj4gbWF5IGludm9sdmUg ZXhjaGFuZ2luZyB0aGUgY2hpcHNldCwgaW5jcmVhc2luZyBjb3N0cywgYW5kIG1heSBpbXBhY3QK PiBleGlzdGluZyBkcml2ZXJzLiBXb3VsZG4ndCBoZWxwIGZvciBkZXZpY2VzIG91dCB0aGVyZSB0 b2RheSBlaXRoZXIuCgpUaGV5IG5lZWQgdG8gcHV0IGFuIGV4dHJhIGVlcHJvbSAoY2VudHMpIGlu dG8gdGhlaXIgZGVzaWduIGFuZCBwcm9ncmFtIGl0LgoKPiAKPiBGb3IgdGhlIHBpY29HVyBDREMg ZmlybXdhcmUsIFNlbXRlY2ggZG9lcyBhcHBlYXIgdG8gb3duIGEgVVNCIHZlbmRvciBJRCwKPiBz byBpdCB3b3VsZCBzZWVtIHBvc3NpYmxlIHRvIGFsbG9jYXRlIHRoZWlyIG93biBwcm9kdWN0IElE cyBmb3IgU1gxMzAxCj4gYW5kIFNYMTMwOCByZXNwZWN0aXZlbHkgdG8gcmVwbGFjZSB0aGUgZ2Vu ZXJpYyBTVE1pY3JvZWxlY3Ryb25pY3MgSURzLAo+IHdoaWNoIHRoZSB2YXJpb3VzIHZlbmRvcnMg Y291bGQgb2ZmZXIgYXMgZmlybXdhcmUgdXBkYXRlcy4KPiAKPiBBbGwgb3V0c2lkZSBteSBjb250 cm9sIHRob3VnaC4KPiAKPiBPbGl2ZXIgdGhlcmVmb3JlIHN1Z2dlc3RlZCB0byBub3QgbWVzcyB3 aXRoIFVTQiBkcml2ZXJzIGFuZCBpbnN0ZWFkIHVzZQo+IGEgbGluZSBkaXNjaXBsaW5lIChsZGlz YykuIEl0IHNlZW1zIHRoYXQgZm9yIGV4YW1wbGUgdGhlIHVzZXJzcGFjZSB0b29sCj4gc2xhdHRh Y2ggdGFrZXMgYSB0dHkgZGV2aWNlIGFuZCBwZXJmb3JtcyBhbiBpb2N0bCB0byBzd2l0Y2ggdGhl IGdlbmVyaWMKPiB0dHkgZGV2aWNlIGludG8gYSBzcGVjaWFsIE5fU0xJUCBwcm90b2NvbCBtb2Rl LCBpbXBsZW1lbnRlZCBpbiBbNF0uCj4gCj4gSG93ZXZlciwgdGhlIGV4aXN0aW5nIG51bWJlciBv ZiBzdWNoIGxkaXNjIG1vZGVzIGFwcGVhcnMgdG8gYmUgYmVsb3cgMzAsCj4gd2l0aCBoYXJkbHkg YW55IHZlbmRvci1zcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiwgc28gcG9sbHV0aW5nIGl0cyBudW1i ZXIKPiBzcGFjZSBzZWVtcyB1bmRlc2lyYWJsZT8gQW5kIGluIHNvbWUgY2FzZXMgSSB3b3VsZCBs aWtlIHRvIHVzZSB0aGUgc2FtZQo+IHByb3RvY29sIGltcGxlbWVudGF0aW9uIG92ZXIgZGlyZWN0 IFVBUlQgYW5kIG92ZXIgVVNCLCBzbyB3b3VsZCBsaWtlIHRvCj4gYXZvaWQgZHVwbGljYXRlIHNl cmRldl9kZXZpY2VfZHJpdmVyIGFuZCB0dHlfbGRpc2Nfb3BzIGltcGxlbWVudGF0aW9ucy4KPiAK PiBMb25nIHN0b3J5IHNob3J0LCBoYXMgdGhlcmUgYmVlbiBhbnkgdGhpbmtpbmcgYWJvdXQgYSB1 c2Vyc3BhY2UKPiBpbnRlcmZhY2UgdG8gYXR0YWNoIGEgZ2l2ZW4gc2VyZGV2IGRyaXZlciB0byBh IHR0eSBkZXZpY2U/Cj4gCj4gT3IgaXMgdGhlcmUsIG9uIE9GX0RZTkFNSUMgcGxhdGZvcm1zLCBh IHdheSBmcm9tIHVzZXJzcGFjZSB0byBhc3NvY2lhdGUKPiBhIERUIGZyYWdtZW50ICghPSBEVCBP dmVybGF5KSB3aXRoIGEgZ2l2ZW4gVVNCIGRldmljZSBkeW5hbWljYWxseSwgdG8KPiBhdHRhY2gg YSBzZXJkZXYgbm9kZSB3aXRoIHN1Yi1ub2Rlcz8KPiAKPiBBbnkgb3RoZXIgaWRlYXMgaG93IHRv IGNsZWFubHkgc29sdmUgdGhpcz8KPiAKPiBJbiBzb21lIGNhc2VzIHdlJ3JlIHRhbGtpbmcgYWJv dXQgYSAic2ltcGxlIiBBVC1saWtlIGNvbW1hbmQgaW50ZXJmYWNlOwo+IHRoZSBwaWNvR1cgaW1w bGVtZW50cyBhIHNlbWktZ2VuZXJpYyBVU0ItU1BJIGJyaWRnZSB0aGF0IG1heSBob3N0IGEKPiBj aG9pY2Ugb2YgMisgY2hpcHNldHMsIHdoaWNoIGluIHR1cm4gaGFzIHR3byBmdXJ0aGVyIHN1Yi1k ZXZpY2VzIHdpdGggMysKPiBjaGlwc2V0IGNob2ljZXMgKHRoZW9yZXRpY2FsbHkgY2xrIG91dHB1 dCBhbmQgcngvdHggb3B0aW9ucyBldGMuKSBlYWNoLgo+IChGb3IgdGhlIGxhdHRlciBJJ20gdGhp bmtpbmcgd2UnbGwgbmVlZCBhIHNlcmRldiBkcml2ZXIgZXhwb3NpbmcgYQo+IHJlZ21hcF9idXMg YW5kIHRoZW4gaW1wbGVtZW50IHJlZ21hcF9idXMgYmFzZWQgdmVyc2lvbnMgb2YgdGhlIFNQSQo+ IGRyaXZlcnMgbGlrZSBCZW4gYW5kIEkgcmVmYWN0b3JlZCBTWDEyNTcgaW4gWzJdIGxhc3Qgd2Vl a2VuZC4pPgoKVGhlcmUgaXMgYSBtUENJZSBtb2R1bGUgKFJBSzgzMykgYXZhaWxhYmxlIGJ5IFJB SyB3aXJlbGVzcyB0aGF0IHVzZXMgYQpGVDIyMzIgYXMgVVNCLVNQSSBicmlkZ2UsIG5vdCB1YXJ0 LiBJIGhhdmUgb25lIGhlcmUgZm9yIGV4cGVyaW1lbnRzLiBJdAppcyBkZXRlY3RlZCBhcyBnZW5l cmljIEZUMjIzMiBkZXZpY2Ugb24gdXNiLiBBcyBmYXIgYXMgSSB1bmRlcnN0b29kIHNvCmZhciB0 aGUgc2VyZGV2IGRvZXMgb25seSBzdXBwb3J0IHVhcnQgYmFzZWQgY29tbXVuaWNhdGlvbiwgaXMg dGhlcmUgYQpjaGFuY2UgdG8gZ2V0IFVTQi1TUEkgYnJpZGdlZCBtb2R1bGVzIGFsc28gd29ya2lu Zz8KCkJyLApGcmFuawoKPiBUaGFua3MsCj4gQW5kcmVhcwo+IAo+IFsxXSBodHRwczovL3BhdGNo d29yay5vemxhYnMub3JnL2NvdmVyLzkzNzU0NS8KPiBbMl0KPiBodHRwczovL2dpdC5rZXJuZWwu b3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9hZmFlcmJlci9saW51eC1sb3JhLmdpdC90cmVl L2RyaXZlcnMvbmV0L2xvcmE/aD1sb3JhLW5leHQKPiBbM10KPiBodHRwczovL2dpdGh1Yi5jb20v TG9yYS1uZXQvcGljb0dXX21jdS9ibG9iL21hc3Rlci9zcmMvdXNiX2NkYy9TcmMvdXNiZF9kZXNj LmNwcCNMNTkKPiBbNF0KPiBodHRwczovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2Vy bmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9kcml2ZXJzL25ldC9zbGlwL3NsaXAuYyNu MTI4MQo+IAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZy YWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGlu dXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Aug 2018 18:32:48 +0200 (CEST) Received: from server1044-han.de-nserver.de ([77.75.251.205]:17793 "EHLO server1044-han.de-nserver.de" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993016AbeHUQcpUdx8D (ORCPT ); Tue, 21 Aug 2018 18:32:45 +0200 Received: (qmail 11766 invoked from network); 21 Aug 2018 18:32:44 +0200 X-Fcrdns: Yes Received: from p5B2C7149.dip0.t-ipconnect.de (HELO [192.168.0.56]) (91.44.113.73) (smtp-auth username mailinglists@kunz-im-inter.net, mechanism plain) by server1044-han.de-nserver.de (qpsmtpd/0.92) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Tue, 21 Aug 2018 18:32:44 +0200 Subject: Re: serdev: How to attach serdev devices to USB based tty devices? To: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Rob Herring , "linux-serial@vger.kernel.org" , linux-usb@vger.kernel.org Cc: "linux-arm-kernel@lists.infradead.org" , Linux-MIPS , Stefan Rehm , Xue Liu , "LoRa_Community_Support@semtech.com" , Oliver Neukum , Alexander Graf , Ben Whitten , devicetree@vger.kernel.org, Jian-Hong Pan , "netdev@vger.kernel.org" References: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> From: Frank Kunz Openpgp: preference=signencrypt Autocrypt: addr=mailinglists@kunz-im-inter.net; prefer-encrypt=mutual; keydata= xsDiBEBcTn4RBADTVXx2rxejOvpg+K3IuzBCTeDBxoyCE5hGWjWhPhVFGVNzuXUvJtrz53Gc 8tasoTb28cOTR5RFA+ZccEqr+Utl+x32uNcAUge8GvfCezQ/m/FzkjFIBHO/PwvRVl5Httut Q0JAyhYTyWQXh6meGeLF0nbeV7TrOwVBfIex6c7QRwCgmIwD6CfTLDAiPVCoFCh8EBo0fvMD /3W/ZaaAghqD00eK3YNndWVJRskijld744k4cmAIFl67rDU2B3GpslyKxBC3sPgcgZ2yL8Fa k4EYG+HL+odvrnjMnB3QZ4oPTdkw2gwWay0EljQ7K7f3Y7hACvWE3GBbVoKaRhsWtuQkQQUo DvRVnp5iV609nkpIhyMf4F0wCyoqA/sHPsQYjnwyCsQmb0NCvWIxUgX9rB94Q/TXG0xgCEwt 1fenftJY+AePPu1e6Qd8BkkJ+ooSWAfP4aXlXEJfvmEIcMa5Yo8j5F4cQpifTV57H+M1MFiJ RWPBYCWLATJ2b3R1Mevxi+KTuMXc275YNHA5YiPDXKBdt6/qLHS1a4N/MM0kRnJhbmsgS3Vu eiA8ZnJhbmtAa3Vuei1pbS1pbnRlci5uZXQ+wlsEExECABsFAkBcTn4GCwkIBwMCAxUCAwMW AgECHgECF4AACgkQZ1DjqcEsjXn+LQCeM8JNYhD7DCig8SZEKXIkpZZxjZgAnRy3EgJ5h1FJ w+4CZoNCFKAcrIe9zsBNBEBcToAQBACpwIdSn7xurAlTHg77yDzpAiKMLLwbd3jpNE+T6zN3 5uoYhpAwYrcrtTydSihFzznNAKAG2sd229EUY4LkkrlIK7pAd6PMBH9Ji3KqDARB1Rngh1dM BcQkg2roJq1z2mnMLF2+wM3+IgD6KGbO0scU8oQ4Onju5k7CZspGaGA+xwADBQQApuZHYBSy 7R2G7SzzEesr721SmrdXPo6zOC7DV3+A/oka1ZRWDkHpDxLsy5s/vTaNsLbVcodnItdrgsYQ mIUQhLDnp+0dVPpeyHLZ8cR8jK2IxlIrsIREc4P7EkZVVc9EfL9RvAGEckZxvtxMPAtfXwxu BYxXsWJuFPOdPybeoFnCRgQYEQIABgUCQFxOgAAKCRBnUOOpwSyNeQzyAJwIcdKVplSqfZy7 Fdv1LRVZy3uDFACdHdyyhm0xvjG5iJJtWCBJRzeUovQ= Message-ID: Date: Tue, 21 Aug 2018 18:32:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-User-Auth: Auth by mailinglists@kunz-im-inter.net through 91.44.113.73 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 65682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mailinglists@kunz-im-inter.net Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips Am 14.08.2018 um 04:28 schrieb Andreas Färber: > Hi Rob et al., > > For my LoRa network driver project [1] I have found your serdev > framework to be a valuable help for dealing with hardware modules > exposing some textual or binary UART interface. > > In particular on arm(64) and mips this allows to define an unlimited > number of serdev drivers [2] that are associated via their Device Tree > compatible string and can optionally be configured via DT properties. > > And in theory it seems serdev has also grown support for ACPI. > > Now, a growing number of vendors are placing such modules on a USB stick > for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2 > cards using their USB pins. While I do not yet have access to such a > device myself, it is my understanding that devices with USB-UART bridge > chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an > MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW) > will show up as /dev/ttyACMx. > On the Raspberry Pi I've seen that Device Tree nodes can be used to pass > information to on-board devices such as MAC address to Ethernet chipset, > but that does not seem all that useful for passing a serdev child node > to hot-plugged devices at unpredictable hub/port location (where it > should not interfere with regular USB-UART cables for debugging), nor > would it help ACPI based platforms such as x86_64. > > My idea then was that if we had some unique criteria like vendor and > product IDs (or whatever is supported in usb_device_id), we could write > a usb_driver with suitable USB_DEVICE*() macro. In its probe function we > could call into the existing tty driver's probe function and afterwards > try creating and attaching the appropriate serdev device, i.e. a fixed > USB-to-serdev driver mapping. Problem is that most devices don't seem to > implement any unique identifier I could make this depend on - either by > using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics > virtual com port identifiers in CDC firmware and only differing in the > textual description [3] the usb_device_id does not seem to match on. > > The obvious solution would of course be if hardware vendors could revise > their designs to configure FTDI/etc. chips uniquely. I hear that that > may involve exchanging the chipset, increasing costs, and may impact > existing drivers. Wouldn't help for devices out there today either. They need to put an extra eeprom (cents) into their design and program it. > > For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID, > so it would seem possible to allocate their own product IDs for SX1301 > and SX1308 respectively to replace the generic STMicroelectronics IDs, > which the various vendors could offer as firmware updates. > > All outside my control though. > > Oliver therefore suggested to not mess with USB drivers and instead use > a line discipline (ldisc). It seems that for example the userspace tool > slattach takes a tty device and performs an ioctl to switch the generic > tty device into a special N_SLIP protocol mode, implemented in [4]. > > However, the existing number of such ldisc modes appears to be below 30, > with hardly any vendor-specific implementation, so polluting its number > space seems undesirable? And in some cases I would like to use the same > protocol implementation over direct UART and over USB, so would like to > avoid duplicate serdev_device_driver and tty_ldisc_ops implementations. > > Long story short, has there been any thinking about a userspace > interface to attach a given serdev driver to a tty device? > > Or is there, on OF_DYNAMIC platforms, a way from userspace to associate > a DT fragment (!= DT Overlay) with a given USB device dynamically, to > attach a serdev node with sub-nodes? > > Any other ideas how to cleanly solve this? > > In some cases we're talking about a "simple" AT-like command interface; > the picoGW implements a semi-generic USB-SPI bridge that may host a > choice of 2+ chipsets, which in turn has two further sub-devices with 3+ > chipset choices (theoretically clk output and rx/tx options etc.) each. > (For the latter I'm thinking we'll need a serdev driver exposing a > regmap_bus and then implement regmap_bus based versions of the SPI > drivers like Ben and I refactored SX1257 in [2] last weekend.)> There is a mPCIe module (RAK833) available by RAK wireless that uses a FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It is detected as generic FT2232 device on usb. As far as I understood so far the serdev does only support uart based communication, is there a chance to get USB-SPI bridged modules also working? Br, Frank > Thanks, > Andreas > > [1] https://patchwork.ozlabs.org/cover/937545/ > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next > [3] > https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59 > [4] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281 > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from server1044-han.de-nserver.de ([77.75.251.205]:17793 "EHLO server1044-han.de-nserver.de" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993016AbeHUQcpUdx8D (ORCPT ); Tue, 21 Aug 2018 18:32:45 +0200 Subject: Re: serdev: How to attach serdev devices to USB based tty devices? References: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> From: Frank Kunz Message-ID: Date: Tue, 21 Aug 2018 18:32:42 +0200 MIME-Version: 1.0 In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: =?UTF-8?Q?Andreas_F=c3=a4rber?= , Rob Herring , "linux-serial@vger.kernel.org" , linux-usb@vger.kernel.org Cc: "linux-arm-kernel@lists.infradead.org" , Linux-MIPS , Stefan Rehm , Xue Liu , "LoRa_Community_Support@semtech.com" , Oliver Neukum , Alexander Graf , Ben Whitten , devicetree@vger.kernel.org, Jian-Hong Pan , "netdev@vger.kernel.org" Message-ID: <20180821163242.4_c-WVu2gv2WJ4fos_IsPZGIAfBOa-v4HTTMLLwMJCU@z> Am 14.08.2018 um 04:28 schrieb Andreas Färber: > Hi Rob et al., > > For my LoRa network driver project [1] I have found your serdev > framework to be a valuable help for dealing with hardware modules > exposing some textual or binary UART interface. > > In particular on arm(64) and mips this allows to define an unlimited > number of serdev drivers [2] that are associated via their Device Tree > compatible string and can optionally be configured via DT properties. > > And in theory it seems serdev has also grown support for ACPI. > > Now, a growing number of vendors are placing such modules on a USB stick > for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2 > cards using their USB pins. While I do not yet have access to such a > device myself, it is my understanding that devices with USB-UART bridge > chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an > MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW) > will show up as /dev/ttyACMx. > On the Raspberry Pi I've seen that Device Tree nodes can be used to pass > information to on-board devices such as MAC address to Ethernet chipset, > but that does not seem all that useful for passing a serdev child node > to hot-plugged devices at unpredictable hub/port location (where it > should not interfere with regular USB-UART cables for debugging), nor > would it help ACPI based platforms such as x86_64. > > My idea then was that if we had some unique criteria like vendor and > product IDs (or whatever is supported in usb_device_id), we could write > a usb_driver with suitable USB_DEVICE*() macro. In its probe function we > could call into the existing tty driver's probe function and afterwards > try creating and attaching the appropriate serdev device, i.e. a fixed > USB-to-serdev driver mapping. Problem is that most devices don't seem to > implement any unique identifier I could make this depend on - either by > using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics > virtual com port identifiers in CDC firmware and only differing in the > textual description [3] the usb_device_id does not seem to match on. > > The obvious solution would of course be if hardware vendors could revise > their designs to configure FTDI/etc. chips uniquely. I hear that that > may involve exchanging the chipset, increasing costs, and may impact > existing drivers. Wouldn't help for devices out there today either. They need to put an extra eeprom (cents) into their design and program it. > > For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID, > so it would seem possible to allocate their own product IDs for SX1301 > and SX1308 respectively to replace the generic STMicroelectronics IDs, > which the various vendors could offer as firmware updates. > > All outside my control though. > > Oliver therefore suggested to not mess with USB drivers and instead use > a line discipline (ldisc). It seems that for example the userspace tool > slattach takes a tty device and performs an ioctl to switch the generic > tty device into a special N_SLIP protocol mode, implemented in [4]. > > However, the existing number of such ldisc modes appears to be below 30, > with hardly any vendor-specific implementation, so polluting its number > space seems undesirable? And in some cases I would like to use the same > protocol implementation over direct UART and over USB, so would like to > avoid duplicate serdev_device_driver and tty_ldisc_ops implementations. > > Long story short, has there been any thinking about a userspace > interface to attach a given serdev driver to a tty device? > > Or is there, on OF_DYNAMIC platforms, a way from userspace to associate > a DT fragment (!= DT Overlay) with a given USB device dynamically, to > attach a serdev node with sub-nodes? > > Any other ideas how to cleanly solve this? > > In some cases we're talking about a "simple" AT-like command interface; > the picoGW implements a semi-generic USB-SPI bridge that may host a > choice of 2+ chipsets, which in turn has two further sub-devices with 3+ > chipset choices (theoretically clk output and rx/tx options etc.) each. > (For the latter I'm thinking we'll need a serdev driver exposing a > regmap_bus and then implement regmap_bus based versions of the SPI > drivers like Ben and I refactored SX1257 in [2] last weekend.)> There is a mPCIe module (RAK833) available by RAK wireless that uses a FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It is detected as generic FT2232 device on usb. As far as I understood so far the serdev does only support uart based communication, is there a chance to get USB-SPI bridged modules also working? Br, Frank > Thanks, > Andreas > > [1] https://patchwork.ozlabs.org/cover/937545/ > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next > [3] > https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59 > [4] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: mailinglists@kunz-im-inter.net (Frank Kunz) Date: Tue, 21 Aug 2018 18:32:42 +0200 Subject: serdev: How to attach serdev devices to USB based tty devices? In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> References: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Am 14.08.2018 um 04:28 schrieb Andreas F?rber: > Hi Rob et al., > > For my LoRa network driver project [1] I have found your serdev > framework to be a valuable help for dealing with hardware modules > exposing some textual or binary UART interface. > > In particular on arm(64) and mips this allows to define an unlimited > number of serdev drivers [2] that are associated via their Device Tree > compatible string and can optionally be configured via DT properties. > > And in theory it seems serdev has also grown support for ACPI. > > Now, a growing number of vendors are placing such modules on a USB stick > for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2 > cards using their USB pins. While I do not yet have access to such a > device myself, it is my understanding that devices with USB-UART bridge > chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an > MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW) > will show up as /dev/ttyACMx. > On the Raspberry Pi I've seen that Device Tree nodes can be used to pass > information to on-board devices such as MAC address to Ethernet chipset, > but that does not seem all that useful for passing a serdev child node > to hot-plugged devices at unpredictable hub/port location (where it > should not interfere with regular USB-UART cables for debugging), nor > would it help ACPI based platforms such as x86_64. > > My idea then was that if we had some unique criteria like vendor and > product IDs (or whatever is supported in usb_device_id), we could write > a usb_driver with suitable USB_DEVICE*() macro. In its probe function we > could call into the existing tty driver's probe function and afterwards > try creating and attaching the appropriate serdev device, i.e. a fixed > USB-to-serdev driver mapping. Problem is that most devices don't seem to > implement any unique identifier I could make this depend on - either by > using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics > virtual com port identifiers in CDC firmware and only differing in the > textual description [3] the usb_device_id does not seem to match on. > > The obvious solution would of course be if hardware vendors could revise > their designs to configure FTDI/etc. chips uniquely. I hear that that > may involve exchanging the chipset, increasing costs, and may impact > existing drivers. Wouldn't help for devices out there today either. They need to put an extra eeprom (cents) into their design and program it. > > For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID, > so it would seem possible to allocate their own product IDs for SX1301 > and SX1308 respectively to replace the generic STMicroelectronics IDs, > which the various vendors could offer as firmware updates. > > All outside my control though. > > Oliver therefore suggested to not mess with USB drivers and instead use > a line discipline (ldisc). It seems that for example the userspace tool > slattach takes a tty device and performs an ioctl to switch the generic > tty device into a special N_SLIP protocol mode, implemented in [4]. > > However, the existing number of such ldisc modes appears to be below 30, > with hardly any vendor-specific implementation, so polluting its number > space seems undesirable? And in some cases I would like to use the same > protocol implementation over direct UART and over USB, so would like to > avoid duplicate serdev_device_driver and tty_ldisc_ops implementations. > > Long story short, has there been any thinking about a userspace > interface to attach a given serdev driver to a tty device? > > Or is there, on OF_DYNAMIC platforms, a way from userspace to associate > a DT fragment (!= DT Overlay) with a given USB device dynamically, to > attach a serdev node with sub-nodes? > > Any other ideas how to cleanly solve this? > > In some cases we're talking about a "simple" AT-like command interface; > the picoGW implements a semi-generic USB-SPI bridge that may host a > choice of 2+ chipsets, which in turn has two further sub-devices with 3+ > chipset choices (theoretically clk output and rx/tx options etc.) each. > (For the latter I'm thinking we'll need a serdev driver exposing a > regmap_bus and then implement regmap_bus based versions of the SPI > drivers like Ben and I refactored SX1257 in [2] last weekend.)> There is a mPCIe module (RAK833) available by RAK wireless that uses a FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It is detected as generic FT2232 device on usb. As far as I understood so far the serdev does only support uart based communication, is there a chance to get USB-SPI bridged modules also working? Br, Frank > Thanks, > Andreas > > [1] https://patchwork.ozlabs.org/cover/937545/ > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next > [3] > https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59 > [4] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281 >