I've done USB descriptors dump for MC7304 with two firmware variants: - modem SWI9X15C_05.05.67.00 - voice enambled SWI9X15C_06.03.32.02
as well as descriptors for EM/MC7455 modem firmware. Denis On 8/15/2018 5:41 PM, Mark Kettenis wrote: >> Date: Wed, 15 Aug 2018 09:56:50 +0100 >> From: Stuart Henderson <[email protected]> >> >> On 2018/08/14 18:43, Bryan Vyhmeister wrote: >>> On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: >>>> Most of modern modems have serial discipline ports and USB Mobile >>>> Broadband Interface Model (MBIM) interface in some port compositions >>>> simultaneously. It seems very useful to have different disciplines >>>> supported by umsm(4) and umb(4) drivers on the same device. >>>> >>> <snip> >>>> >>>> Does it possible to have simultaneously operated AT + NMEA ports by >>>> umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 >>>> device in 6.3? >>> >>> What is the advantage in having a device attach to both umsm(4) and >>> umb(4)? What are you trying to accomplish? The EM7455 worked perfectly >>> with umb(4) until your previous umsm(4) diff and now it only attaches as >>> umsm(4). Are you wanting to send SMS messages or something like that >>> with your devices? >>> >>> Bryan >>> >> >> Denis has a good point because umsm is needed for GPS and as you >> suggest SMS. >> >> What determines which driver attaches when a device is supported by >> multiple drivers? Perhaps the simplest option without more complex work >> to support different interfaces on different drivers would be to have >> the device attach to umb by default but attach to umsm instead if umb is >> disabled in the kernel. Then at least a standard kernel could be used >> with "disable umb" from boot config. > > The return value from the "match" function determines which driver > attaches. The driver that returns the highest value wins. > > However, matching for USB devices is complicated. Drivers already use > different return values (the UMATCH_* constants). On top of that > drivers can claim a whole device or claim just a particular interface > of a device. This requires some careful though to make sure the right > driver attaches. > > What we really need is a full dump of the usb device descriptors, > preferably in all the different UDUSBCOMP modes. >
