Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1526164img; Tue, 19 Mar 2019 09:27:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqxofDmv/N85R1mwRx0fEgLCOZocd94P1e3b7zlUPJLn8NKzk3/3AkbtOhAEUk5PKokqrY6g X-Received: by 2002:a17:902:f095:: with SMTP id go21mr25805657plb.199.1553012860315; Tue, 19 Mar 2019 09:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553012860; cv=none; d=google.com; s=arc-20160816; b=g0tkdfCGD6X1P0PPf3cMf4uEg808E9U2PKdECE4etjubYxIyYtsehNtKt7c1yV2gOr uJ4GTWDNsoEHDtzDlCWtiajXjNtv70QT+RmSiyuTO4roEbJ1Et2Z5cnuz6eUc5Lc4LtA UPuauwFSuPE46uHB5kMxkpf5EGcPHQrSD4DKeK3kFFdtelAvjQZJt2EMRHs1UEvtp/ey TiIjD1RE5uD1sW8J5Z3LskAQogLdwUsUnZVKrRaIun4hYkUmhPE3AcngyL/tMzcdBbCF KfrNZakynguUOlgdG7WJG6N3nRE+VkpUllhPFxHVR6yXVOwLG44D7FTR6wezs3ln+RsP spUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=iGyubLQTIfs+ggJtxbcANdQrfhAAwkGYUZqW4ONEC0g=; b=uaZN5rmuCcO3yd9WY4SBFVPlqFVVk0haH7RsiwMY9XP2tPMHKnTxvQglO94uGou0ME Y/TXZ86PL8agE6l1jbLrH/7xK2gefcC+N4moZ7jiHQykRuqLZ0mCbKdLXNm6/QIBbaKo X8D1JRSjAOkk9NPeFxAScKH3D8SgYvIQW6tU2v0Gi8AKgK/8cuOOjWv6TQY6rSaox0wB nTqsLtVJaivAy38+J1inCgOQkdJR1bHDsfVonajyn5W73DbAXiCvM7hefkqDGHoFJRv5 9tSdJFVSfp1A2TFR4EVjWhmN1i9qVO3foSxt7FrrxAuQPcE88emnuoxCWrFJTGT4WknK QnEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a7si11582410pgq.429.2019.03.19.09.27.24; Tue, 19 Mar 2019 09:27:40 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727725AbfCSQ0l convert rfc822-to-8bit (ORCPT + 99 others); Tue, 19 Mar 2019 12:26:41 -0400 Received: from unicorn.mansr.com ([81.2.72.234]:40196 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726839AbfCSQ0l (ORCPT ); Tue, 19 Mar 2019 12:26:41 -0400 Received: by unicorn.mansr.com (Postfix, from userid 51770) id 6A1A114CEB; Tue, 19 Mar 2019 16:26:39 +0000 (GMT) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: =?iso-8859-1?Q?Bj=F8rn?= Mork Cc: Dan Williams , Johan Hovold , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] USB: serial: option: set driver_info for SIM5218 and compatibles References: <20190226170710.12709-1-mans@mansr.com> <20190227083342.GJ4747@localhost> <20190227131315.GO4747@localhost> <20190319102840.GI6124@localhost> <20190319110819.GB3178@localhost> <20190319122719.GC3178@localhost> <20190319124358.GK6124@localhost> <6c89938b00ad289e1802f675bd00e288b1458d73.camel@redhat.com> <878sxa9ag7.fsf@miraculix.mork.no> Date: Tue, 19 Mar 2019 16:26:39 +0000 In-Reply-To: <878sxa9ag7.fsf@miraculix.mork.no> (=?iso-8859-1?Q?=22Bj=F8rn?= Mork"'s message of "Tue, 19 Mar 2019 15:59:36 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bj?rn Mork writes: > M?ns Rullg?rd writes: >> Dan Williams 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. Every time you think USB can't get any worse, it does. -- M?ns Rullg?rd