linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: "Måns Rullgård" <mans@mansr.com>
Cc: "Johan Hovold" <johan@kernel.org>, "Bjørn Mork" <bjorn@mork.no>,
	"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
Date: Tue, 19 Mar 2019 11:28:40 +0100	[thread overview]
Message-ID: <20190319102840.GI6124@localhost> (raw)
In-Reply-To: <yw1xlg21uwrp.fsf@mansr.com>

On Wed, Feb 27, 2019 at 02:32:58PM +0000, Måns Rullgård wrote:
> Johan Hovold <johan@kernel.org> writes:
> 
> > Adding Bjørn.
> >
> > On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote:
> >> Johan Hovold <johan@kernel.org> 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 <mans@mansr.com>
> >> >> ---
> >> >>  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

  parent reply	other threads:[~2019-03-19 10:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 17:07 [PATCH] USB: serial: option: set driver_info for SIM5218 and compatibles Mans Rullgard
2019-02-27  8:33 ` Johan Hovold
2019-02-27 11:57   ` Måns Rullgård
2019-02-27 13:13     ` Johan Hovold
2019-02-27 14:32       ` Måns Rullgård
2019-03-18 14:32         ` Måns Rullgård
2019-03-19 10:28         ` Johan Hovold [this message]
2019-03-19 10:54           ` Måns Rullgård
2019-03-19 11:08             ` Johan Hovold
2019-03-19 12:25               ` Måns Rullgård
2019-03-19 12:27                 ` Johan Hovold
2019-03-19 12:43                   ` Johan Hovold
2019-03-19 14:30                     ` Dan Williams
2019-03-19 14:35                       ` Måns Rullgård
2019-03-19 14:59                         ` Bjørn Mork
2019-03-19 16:26                           ` Måns Rullgård
2019-03-19 17:15                             ` Bjørn Mork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190319102840.GI6124@localhost \
    --to=johan@kernel.org \
    --cc=bjorn@mork.no \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mans@mansr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).