Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   =?utf-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
To:     =?utf-8?Q?M=C3=A5ns_Rullg=C3=A5rd?= <mans@mansr.com>
Cc:     Dan Williams <dcbw@redhat.com>, Johan Hovold <johan@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: serial: option: set driver_info for SIM5218 and compatibles
Organization: m
References: <20190226170710.12709-1-mans@mansr.com>
        <20190227083342.GJ4747@localhost> <yw1xpnrdv3z7.fsf@mansr.com>
        <20190227131315.GO4747@localhost> <yw1xlg21uwrp.fsf@mansr.com>
        <20190319102840.GI6124@localhost> <yw1xd0mn16ev.fsf@mansr.com>
        <20190319110819.GB3178@localhost> <yw1x8sxb125q.fsf@mansr.com>
        <20190319122719.GC3178@localhost> <20190319124358.GK6124@localhost>
        <6c89938b00ad289e1802f675bd00e288b1458d73.camel@redhat.com>
        <yw1xr2b3ylsp.fsf@mansr.com>
Date:   Tue, 19 Mar 2019 15:59:36 +0100
In-Reply-To: <yw1xr2b3ylsp.fsf@mansr.com> (=?utf-8?Q?=22M=C3=A5ns_Rullg?=
 =?utf-8?Q?=C3=A5rd=22's?= message of "Tue,
        19 Mar 2019 14:35:18 +0000")
Message-ID: <878sxa9ag7.fsf@miraculix.mork.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

M=C3=A5ns Rullg=C3=A5rd <mans@mansr.com> writes:
> Dan Williams <dcbw@redhat.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=C3=B8rn