linux-kernel - Re: [PATCH] USB: serial: option: set driver

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: <878sxa9ag7.fsf@miraculix.mork.no>
Date:   Tue, 19 Mar 2019 15:59:36 +0100
From:   Bjørn Mork <bjorn@...k.no>
To:     Måns Rullgård <mans@...sr.com>
Cc:     Dan Williams <dcbw@...hat.com>, Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: serial: option: set driver_info for SIM5218 and compatibles

Måns Rullgård <mans@...sr.com> writes:
> Dan Williams <dcbw@...hat.com> writes:
>
>> TLDR; some firmware uses the DTR signal as an indicator to come out of
>> low-power mode. Without doing so you cannot talk to the modem over any
>> of it's ports, QMI, net, or serial.
>
> I must be missing something, but how does a network interface have a DTR
> signal?

It does not.  But the network function is (ab)using the Comm class USB
control message "SetControlLineState" to signal "wake up" from the host
to the device.  Which is perfectly fine since the USB function in
question is vendor specific.  The vendor can define any USB control
message to mean anything they want. Reusing a Comm class message
probably made sense to the firmware engineer designing this.  We can
only note and adapt.

It doesn't have anything to do with DTR.

Bjørn