Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1237840img; Tue, 19 Mar 2019 03:29:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqwrfxSdFLWh5puL7ye2DwhlAd5Aqu55YHTQm0UhzAnqpb+H3hY6yZ43RfJIRCIDtiezs3s3 X-Received: by 2002:a17:902:765:: with SMTP id 92mr1259181pli.95.1552991387436; Tue, 19 Mar 2019 03:29:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552991387; cv=none; d=google.com; s=arc-20160816; b=mH0JxHjt9d0Yag3HGst/ZG9nyybGI2aHZpACI9PP2EemsTl8WNHCG6Raor0Y2leDVk 8SV4JfdnyUODXhIvvxrO478MHntpTTe2I10g6ckLnjc5VjCy6d1MR22Zkeb8bp/HLQP4 KEETARBy9LN8kA/bUzg2onvq7rRFXEUeqyfJl8sxC/Xeg3+UABtGY0FDSNGYspu1vt9C OpLA7hVeAS4Dy0QJzATnB//KSqw4kkFgErWoZValEcyYNEmA+4qgrHzW7m7T6hlsnxi5 mHDKmKIY7voT858IW+q8UQLiW6Tfg105u+g8I36Ym9/WwB0lXVByCZ7HfftSq5FReFqP ZFzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=tyI6rgnC+UpX8sancHSdmZtqijH+Q9qbvNjNb20gOVI=; b=Lgx2LwwtWtzuJjtnoSsdqUD2cwOCdmyNpxP19HGucI+UzYccHrdB8j10BtUcLw96QJ eItOvcCPDsCg1HDiq0zOFTSbPccq1olzNUef6DKfLYh6GryOEos8HZaaC8epsiymWPlc kQE3tQg2CtKI8j5pq+DbT8SduO8VyZ1kTRblHTibW5cnHcSNcir5SLZHAD8aizOKyKjW MsJ4pWVgmlXgmiHM0DEw+SnXFCEF/3/NoeIIS9ll7Nb82yIWHnoT3PZpCVrvFlXE/KrV 2TxeCeRh0hpE13Vc+Vs02BTgR+r6TLgQa7g37RLtvESzzaPQOp0MMRGd+5+hm3K6ziN7 zVQA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l11si3913071plb.159.2019.03.19.03.29.31; Tue, 19 Mar 2019 03:29:47 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727366AbfCSK2u (ORCPT + 99 others); Tue, 19 Mar 2019 06:28:50 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:45353 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbfCSK2t (ORCPT ); Tue, 19 Mar 2019 06:28:49 -0400 Received: by mail-lj1-f196.google.com with SMTP id y6so8586647ljd.12; Tue, 19 Mar 2019 03:28:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=tyI6rgnC+UpX8sancHSdmZtqijH+Q9qbvNjNb20gOVI=; b=nixmaBxyfT1n7djg0LLYAUDpjS62z2LxGgamLkZlkcHmbOvDeUC5/YeKG/g0ea5yoL 1w8KzS2CLFR73naXGMeNiV/EJMbyVgb3yM3Ik4TYmxHef+l2Z0YpEnwdk8OmAQyPEPUl DUITOugqObpDdpnCrTAgqKeh2+O8SwSqHCG9tkGAEhme3DkVB92r21SsvLcoda+f/RRj q6cAfncfwiUsw4uLzqYZ+z9kEfS/DgeTgPEggZlh/JvyVTvf15p/cBphVx+e5W+3i7ZJ En6uMF1Jop5LLK+yBnRNR9ly6EHNpFbjPdjb0mIwGIODpR9nDLy8dWdxwW3eputza4bD bB5g== X-Gm-Message-State: APjAAAVgjnUEMUyeofeRNMTV+TwzFWS8l8nN/nf+zgwxqkxe7IZEFNej 5wKinqpoqbGYe3la1/xcc9s= X-Received: by 2002:a2e:5b44:: with SMTP id p65mr13515470ljb.182.1552991327510; Tue, 19 Mar 2019 03:28:47 -0700 (PDT) Received: from xi.terra (c-74bee655.07-184-6d6c6d4.bbcust.telenor.se. [85.230.190.116]) by smtp.gmail.com with ESMTPSA id t18sm2730737ljg.64.2019.03.19.03.28.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 03:28:46 -0700 (PDT) Received: from johan by xi.terra with local (Exim 4.91) (envelope-from ) id 1h6Bz6-0007yw-Q5; Tue, 19 Mar 2019 11:28:41 +0100 Date: Tue, 19 Mar 2019 11:28:40 +0100 From: Johan Hovold To: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= Cc: Johan Hovold , =?iso-8859-1?Q?Bj=F8rn?= Mork , 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 Message-ID: <20190319102840.GI6124@localhost> References: <20190226170710.12709-1-mans@mansr.com> <20190227083342.GJ4747@localhost> <20190227131315.GO4747@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 27, 2019 at 02:32:58PM +0000, M?ns Rullg?rd wrote: > Johan Hovold writes: > > > Adding Bj?rn. > > > > On Wed, Feb 27, 2019 at 11:57:16AM +0000, M?ns Rullg?rd wrote: > >> Johan Hovold writes: > >> > >> > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: > >> >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 > >> >> of which are serial ports. The fifth is a network interface supported > >> >> by the qmi-wwan driver. Furthermore, the serial ports do not support > >> >> modem control signals. Add driver_info flags to reflect this. > >> >> > >> >> Signed-off-by: Mans Rullgard > >> >> --- > >> >> drivers/usb/serial/option.c | 3 ++- > >> >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> >> > >> >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > >> >> index fb544340888b..af4cbfecc3ff 100644 > >> >> --- a/drivers/usb/serial/option.c > >> >> +++ b/drivers/usb/serial/option.c > >> >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { > >> >> .driver_info = RSVD(3) }, > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ > >> >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ > >> >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ > >> >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, > >> >> /* Quectel products using Qualcomm vendor ID */ > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), > >> > > >> > Could you please provide the output of usb-devices (or lsusb -v) for > >> > this device? > >> > >> lsusb -v: > >> [...] > > > So the patch looks fine to me. The fifth interface is QMI, but hasn't > > been available for use until now then, and this seems to have been the > > vendors idea from the start: > > > > http://www.microchip.ua/simcom/WCDMA/APPNOTES/SIMCom_3G_Linux_driver_Application%20Note_V1.00.pdf > > That document predates the qmi-wwan driver in the kernel. Note that > this driver has an ID table entry for interface 4 of this device. Right > now, whichever driver is probed first claims that interface. I haven't > actually tried using the QMI interface, though. I didn't say it was correct, just that the vendor proposed binding to it anyway. > > And you're seeing errors when opening ports 0-3 due to the DTR calls > > which I guess no one noticed or cared about before? > > Right, some userspace tools complain about this. Hmm. You shouldn't see any errors on open (they're not even logged), but I guess your user space tools complains on receiving -EPROTO instead of -EINVAL when trying to manage these signals directly? > > Before you sent me the lsusb I searched for it and came across the below > > thread where Bj?rn's having a go at SIMCom. In it there's output from a > > second device using the same id but with entirely different descriptors. > > > > https://forum.openwrt.org/t/lte-wireless-module-support-by-openwrt-led-on-tplink/13586?page=3 > > > > If this is a common theme with this vendor we may need to be extra > > careful when making changes. > > Isn't this a common theme with most USB vendors, especially wireless things? > > Regardless, setting the NCTRL flag should be harmless. Well, there are devices that depend on getting these requests, at least for the QMI interface. But we can always revert if anyone complains. Now applied, thanks. Johan