netdev - Re: serdev: How to attach serdev devices to USB based tty devices?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1534231386.31827.3.camel@suse.com>
Date:   Tue, 14 Aug 2018 09:23:06 +0200
From:   Oliver Neukum <oneukum@...e.com>
To:     Andreas Färber <afaerber@...e.de>,
        Rob Herring <robh@...nel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        linux-usb@...r.kernel.org
Cc:     Jian-Hong Pan <starnight@...cu.edu.tw>,
        Xue Liu <liuxuenetmail@...il.com>,
        Ben Whitten <ben.whitten@...rdtech.com>,
        Linux-MIPS <linux-mips@...ux-mips.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Stefan Rehm <rehm@...omico.ch>,
        "LoRa_Community_Support@...tech.com" 
        <LoRa_Community_Support@...tech.com>,
        Alexander Graf <agraf@...e.de>, devicetree@...r.kernel.org,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: serdev: How to attach serdev devices to USB based tty devices?

On Di, 2018-08-14 at 04:28 +0200, Andreas Färber  wrote:
> 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.

If you really must do this you can benignly fail probe(). Thus you
can compare strings within your probe() method.
This sucks because you need to make sure your drivers are always
loaded in a certain order and you really rely on undocumented
properties, but it can be done.

	Regards
		Oliver