Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
> On 29 August 2016 at 10:05, Pavel Machek <pa...@ucw.cz> wrote:
> >> >2) Having "ports" subdir with RW files, one per each existing physical 
> >> >port
> >> >In this situation we don't need "new_port" or "remove_port". If we
> >> >want port to be observable we just do:
> >> >echo 1 > 1-1
> >> >Implementing this solution needs reading more details from USB subsystem.
> >>
> >> The situation here is clear IMO - the number of USB ports in the system
> >> can change dynamically. I'm not sure if this can be handled easily with
> >> sysfs, where we usually expose an interface for known set of settings.
> >> struct attribute arrays are usually defined statically at the compile
> >> time and filled with the variables, that are created with DEVICE_ATTR
> >> macro.
> >
> > sysfs already exposes current view of all usb devices. Just use it.
> 
> We're talking about USB ports not devices, but this is still true. You
> can find them in
> /sys/bus/usb/devices/*/*-port*
> 
> I can't see how we could use them. How could I develop sysfs interface
> in /sys/class/leds/*/ to allow userspace assigning USB ports to the
> LED trigger?

Create /sys/bus/usb/devices/*/*-port*/led_trigger file?

(Do you plan one USB trigger, or multiple ones?)
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> This commit adds a new trigger responsible for turning on LED when USB
> device gets connected to the specified USB port. This can can useful for
> various home routers that have USB port(s) and a proper LED telling user
> a device is connected.
> 
> The trigger gets its documentation file but basically it just requires
> specifying USB port in a Linux format (e.g. echo 1-1 > new_port).
> 
> During work on this trigger there was a plan to add DT bindings for it,
> but there wasn't an agreement on the format yet. This can be worked on
> later, a sysfs interface is needed anyway for platforms not using DT.
> 
> Another planned feature is support for LED reacting to the USB activity.
> This can be implemented with another sysfs file for setting mode. The
> default mode wouldn't change so there won't be ABI breakage and such
> feature can be safely implemented later.

Actually... USB device plugs/unplugs are pretty rare events... Can we
just do this in userspace using udevd?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Wed 2016-08-31 14:23:13, Alan Stern wrote:
> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
> 
> > >> As you quite often need more complex LED management, there are
> > >> triggers that were introduced in 2006 by c3bc9956ec52f ("[PATCH] LED:
> > >> add LED trigger tupport"). Some triggers are trivial and could be
> > >> implemented in userspace as well (e.g. "timer"). Some had to be
> > >> implemented in kernelspace (CPU activity, MTD activity, etc.). Having
> > >> few triggers compiled, you can assign them to LEDs at it pleases you.
> > >> Your hardware may have generic LED (not labeled) and you can
> > >> dynamically assign various triggers to it, depending e.g. on user
> > >> actions. E.g. if user (using GUI or whatever) wants to see flash
> > >> activity, your userspace script should do:
> > >> echo mtd > /sys/class/leds/foo/trigger
> > >
> > > So for example, you might want to do:
> > >
> > > echo usb1-4 >/sys/class/leds/foo/trigger
> > >
> > > and then have the "foo" LED toggle whenever an URB was submitted or
> > > completed for a device attached to the 1-4 port.  Right?
> > 
> > Not really as it won't cover some pretty common use cases. Many home
> > routers have few USB ports (2-5) and only 1 USB LED. It has to be
> > possible to assign few USB ports to a single LED (trigger). That way
> > LED should be turned on (and kept on) if there is at least 1 USB
> > device connected. You obviously can't do:
> > echo "usb1-1 usb1-2 usb2-1" > /sys/class/leds/foo/trigger
> > 
> > This was already brought up by Rob (who mentioned CPU trigger) and I
> > replied him pretty much the same way in:
> > https://lkml.org/lkml/2016/7/29/38
> > (reply starts with "Anyway, the serious limitation I see").
> 
> The code for a bunch of triggers must already be written.  What would 
> the user do if he wanted to flash a single LED in response to both
> CPU activity and MTD activity?  If not
> 
>   echo "cpu mtd" >/sys/class/leds/foo/trigger

Lets not overcomplicate this... What if user wanted to blink only when
there's both cpu and mtd activity?

I mean, there are way too many possible combinations, but we should
not implement everything. "Heartbeat" for example is nice demo and
nice test case, but ...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

[Pavel Machek]

On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote:
> On Thu, 1 Dec 2016 17:56:07 +0100
> Rafał Miłecki  wrote:
> 
> > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote:
> > > Below the oops with your debug patch applied.
> > >
> > > (...)
> > >
> > > root@wrt1900acs:/# cd sys/class/leds/pca963x\:shelby\:white\:usb2/
> > > root@wrt1900acs:/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:shelby:white:usb2#
> > > echo usbport > trigger [  124.727665] leds
> > > pca963x:shelby:white:usb2: [usbport_trig_add_port] port:dd708240
> > > [  124.735266] leds pca963x:shelby:white:usb2:
> > > [usbport_trig_add_port] port->port_name:usb1-port1
> > > port->data:dd708140 [  124.745671] leds pca963x:shelby:white:usb2:
> > > [usbport_trig_add_port] port:dd7083c0 [  124.753194] leds
> > > pca963x:shelby:white:usb2: [usbport_trig_add_port]
> > > port->port_name:usb2-port1 port->data:dd708140 [  124.763594] leds
> > > pca963x:shelby:white:usb2: [usbport_trig_add_port] port:dd708300
> > > [  124.771114] leds pca963x:shelby:white:usb2:
> > > [usbport_trig_add_port] port->port_name:usb3-port1
> > > port->data:dd708140
> > > root@wrt1900acs:/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:shelby:white:usb2#
> > > echo 1 > ports/usb2-port1[  171.649751] leds
> > > pca963x:shelby:white:usb2: [usbport_trig_port_store] buf:1
> > > [  171.649751]  size:2
> > >
> > > [  171.660160] leds pca963x:shelby:white:usb2:
> > > [usbport_trig_port_store] port:dd7083c0 [  171.668103] leds
> > > pca963x:shelby:white:usb2: [usbport_trig_port_store]
> > > port->port_name:usb2-port1 port->data:dd708140 [  171.678678]
> > > [usbport_trig_update_count] usbport_data->count:0 [  171.684457]
> > > [usbport_trig_update_count] usbport_data->count:0 [  171.690253]
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > >   
> > 
> > Oh, so this happens a bit later than I expected or I could read from
> > the backtrace. Anyway this debugging was still helpful, I think I can
> > see a possible problem.
> > 
> > So most likely the crash happens at the:
> > led_cdev->brightness_set(led_cdev, ...);
> > call. I'm not sure what I was thinking when writing that code. It
> > looks wrong.
> > 
> > The thing is some LEDs (drivers) don't provide brightness_set op.
> > It's fine, we should just use brightness_set_blocking op when that
> > happens. Of course kernel has proper helpers for that, we don't have
> > to worry about the choice of op or scheduling the work. I have no
> > idea why I didn't use a proper helper in the first place.
> > 
> > So we should simply replace above call with one of following ones:
> > 1) led_set_brightness(led_cdev, ...);
> > 2) led_set_brightness_nosleep(led_cdev, ...);
> > 3) led_set_brightness_sync(led_cdev, ...);
> > 
> > I still have to check which one is correct. In theory we don't deal
> > blinking at this point so we shouldn't need to use led_set_brightness.
> > 
> > led_set_brightness_nosleep looks like the most likely correct choice.
> > 
> > led_set_brightness_sync requires brightness_set_blocking which is not
> > always present so most likely we don't want this one.
> > 
> > 
> > If you have some free time and you want to play with this, please
> > replace led_cdev->brightness_set
> > with
> > led_set_brightness_nosleep
> > and give it a try. This should fix crashes for you.
> > 
> > I'll look at this again during next days.
> 
> Hi Rafał
> 
> I just gave 2) led_set_brightness_nosleep a try. The kernel no longer
> crashes and the led does work as expected.

Do you have any patch that needs to be applied?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

> > > > > ...1d.7: PCI fixup... pass 2
> > > > > ...1d.7: PCI fixup... pass 3
> > > > > ...1d.7: PCI fixup... pass 3 done
> > > > > 
> > > > > ...followed by hang. So yes, it looks USB related.
> > > > > 
> > > > > (Sometimes it hangs with some kind backtrace involving secondary CPU
> > > > > startup, unfortunately useful info is off screen at that point).
> > > > 
> > > > Forgot to say, 1d.7 is EHCI controller.
> > > > 
> > > > 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
> > > > Controller (rev 01)
> > > 
> > > Ok, I should have access soon to a EeePc 1015CX (which seem to have this 
> > > controller).
> > > I hope I'll be able to reproduce the issue there. If not, I'm sorry but 
> > > I'll have to
> > > burden you again :-)
> > 
> > Go through more mails. It is only reproducible after cold boot. .. so
> > I doubt it will be easy to reproduce on another machine.
> > 
> > Now... I do have serial port, and I even might have serial cable
> > somewhere, but Giving how sensitive it is, it is probably going to
> > go away with console on ttyS...
> 
> I also tried on an eeepc (which has ICH7/NM10 as well), with your config.
> I even plugged a usb keyboard but even then I have been unable to
> reproduce either :-(

Ok, give me some time. I'm no longer using the affected machine, so no
promises.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Wed 2017-04-12 17:08:35, Frederic Weisbecker wrote:
> On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote:
> > > > > > > ...1d.7: PCI fixup... pass 2
> > > > > > > ...1d.7: PCI fixup... pass 3
> > > > > > > ...1d.7: PCI fixup... pass 3 done
> > > > > > > 
> > > > > > > ...followed by hang. So yes, it looks USB related.
> > > > > > > 
> > > > > > > (Sometimes it hangs with some kind backtrace involving secondary 
> > > > > > > CPU
> > > > > > > startup, unfortunately useful info is off screen at that point).
> > > > > > 
> > > > > > Forgot to say, 1d.7 is EHCI controller.
> > > > > > 
> > > > > > 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
> > > > > > Controller (rev 01)
> > > > > 
> > > > > Ok, I should have access soon to a EeePc 1015CX (which seem to have 
> > > > > this controller).
> > > > > I hope I'll be able to reproduce the issue there. If not, I'm sorry 
> > > > > but I'll have to
> > > > > burden you again :-)
> > > > 
> > > > Go through more mails. It is only reproducible after cold boot. .. so
> > > > I doubt it will be easy to reproduce on another machine.
> > > > 
> > > > Now... I do have serial port, and I even might have serial cable
> > > > somewhere, but Giving how sensitive it is, it is probably going to
> > > > go away with console on ttyS...
> > > 
> > > I also tried on an eeepc (which has ICH7/NM10 as well), with your config.
> > > I even plugged a usb keyboard but even then I have been unable to
> > > reproduce either :-(
> > 
> > Ok, give me some time. I'm no longer using the affected machine, so no
> > promises.
> 
> Actually someone reported me a very similar issue than yours lately. It's 
> probably
> the same. And I have a potential fix.

Got the machine back to work -- I guess it will be useful for distcc.

And yes, you seem to have right fix :-). 

Tested-by: Pavel Machek <pa...@ucw.cz>

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

v4.13-rc2: usb mouse stopped working?

[Pavel Machek]

Hi!

On thinkpad x220, USB mouse stopped working in v4.13-rc2. v4.12 was
ok, iirc.

Now, USB mouse is so common hw that I may have something wrong in my
config...? But I did not change anything there.

In v4.9:

[   87.064408] input: Logitech USB Optical Mouse as
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
[   87.065951] hid-generic 0003:046D:C05A.0005: input,hidraw0: USB HID
v1.11 Mouse [Logitech USB Optical Mouse] on
usb-:00:1d.0-1.1.1.1/input0
pavel@duo:~$

v4.13-rc2:

[   87.886810] usb 2-1.1.1.1: new low-speed USB device number 10 using ehci-pci
[   88.019543] usb 2-1.1.1.1: New USB device found, idVendor=046d, 
idProduct=c05a
[   88.019561] usb 2-1.1.1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   88.019572] usb 2-1.1.1.1: Product: USB Optical Mouse
[   88.019581] usb 2-1.1.1.1: Manufacturer: Logitech
[   88.027276] input: Logitech USB Optical Mouse as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
[   88.027825] hid-generic 0003:046D:C05A.0005: input,hidraw1: USB HID
v1.11 Mouse [Logitech USB Optical Mouse] on
usb-:00:1d.0-1.1.1.1/input0
...

Any ideas?

Did something change in Kconfig and I answered wrong?

Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.13-rc2: usb mouse stopped working?

[Pavel Machek]

Hi!

> > On thinkpad x220, USB mouse stopped working in v4.13-rc2. v4.12 was
> > ok, iirc.
> > 
> > Now, USB mouse is so common hw that I may have something wrong in my
> > config...? But I did not change anything there.
> 
> Well, your particular USB mouse requires an always-poll quirk, so it's not 
> *that* common; therefore ...

Aha, was not aware of that brokennes.

> > [   88.027825] hid-generic 0003:046D:C05A.0005: input,hidraw1: USB HID
> > v1.11 Mouse [Logitech USB Optical Mouse] on
> > usb-:00:1d.0-1.1.1.1/input0
> 
> ... this is most likely caused by e399396a6b0, and fix for that is queued 
> in hid.git as cf601774c9f ("HID: usbhid: fix "always poll" quirk"); I'm 
> planning to send it to Linus' tomorrow, but if you can double-check that 
> it does fix your issue as well, that'd be appreciated.

Thanks for very quick reply. You saved me from some debugging.

I guess I can wait for tommorows' pull. Should be sleeping not
debugging kernels at the moment.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.13-rc2: usb mouse stopped working?

[Pavel Machek]

Hi!

> > In v4.9:
> > 
> > [   87.064408] input: Logitech USB Optical Mouse as
> > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
> > [   87.065951] hid-generic 0003:046D:C05A.0005: input,hidraw0: USB HID
> > v1.11 Mouse [Logitech USB Optical Mouse] on
> > usb-:00:1d.0-1.1.1.1/input0
> > pavel@duo:~$
> > 
> > v4.13-rc2:
> > 
> > [   87.886810] usb 2-1.1.1.1: new low-speed USB device number 10 using 
> > ehci-pci
> > [   88.019543] usb 2-1.1.1.1: New USB device found, idVendor=046d, 
> > idProduct=c05a
> > [   88.019561] usb 2-1.1.1.1: New USB device strings: Mfr=1, Product=2, 
> > SerialNumber=0
> > [   88.019572] usb 2-1.1.1.1: Product: USB Optical Mouse
> > [   88.019581] usb 2-1.1.1.1: Manufacturer: Logitech
> > [   88.027276] input: Logitech USB Optical Mouse as 
> > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1.1/2-1.1.1.1:1.0/0003:046D:C05A.0005/input/input18
> > [   88.027825] hid-generic 0003:046D:C05A.0005: input,hidraw1: USB HID
> > v1.11 Mouse [Logitech USB Optical Mouse] on
> > usb-:00:1d.0-1.1.1.1/input0
> 
> ... this is most likely caused by e399396a6b0, and fix for that is queued 
> in hid.git as cf601774c9f ("HID: usbhid: fix "always poll" quirk"); I'm 
> planning to send it to Linus' tomorrow, but if you can double-check that 
> it does fix your issue as well, that'd be appreciated.

I pulled newer git, and now it seems to work. Thanks! (Tested with
same mouse but different PC).
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

[Pavel Machek]

On Thu 2017-11-09 11:40:28, Greg Kroah-Hartman wrote:
> On Thu, Nov 09, 2017 at 10:51:48AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > It's good to have SPDX identifiers in all files to make it easier to
> > > audit the kernel tree for correct licenses.
> > > 
> > > Update the drivers/usb/ and include/linux/usb* files with the correct
> > > SPDX license identifier based on the license text in the file itself.
> > > The SPDX identifier is a legally binding shorthand, which can be used
> > > instead of the full boiler plate text.
> > > 
> > > This work is based on a script and data from Thomas Gleixner, Philippe
> > > Ombredanne, and Kate Stewart.
> > > 
> > > Cc: Thomas Gleixner <t...@linutronix.de>
> > > Cc: Kate Stewart <kstew...@linuxfoundation.org>
> > > Cc: Philippe Ombredanne <pombreda...@nexb.com>
> > > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > > ---
> > > v2: Use the "standard" format of putting the identifier at the top of
> > > the file, and use // for .c and .h files.
> > > Removed the files already marked in Linus's tree.
> > > 
> > > Unless someone really complains, I'm going to add this to my tree for
> > > 4.15-rc1.
> > 
> > as you said in some other email... this stands out a bit too
> > much.
> 
> That is the goal, sorry.

Then it is bad goal.

Automated tools can pick it up whereever it is. No need to grab
attention with poor placing.

> > What about using normal c comments, and put it near the original
> > license text? It is not exactly the most important thing...
> > 
> > Or maybe near the MODULE_LICENSE, so the two don't get out of sync?
> 
> No, the top of the file is best, thanks.

No, it is not, thanks.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

[Pavel Machek]

Hi!

> It's good to have SPDX identifiers in all files to make it easier to
> audit the kernel tree for correct licenses.
> 
> Update the drivers/usb/ and include/linux/usb* files with the correct
> SPDX license identifier based on the license text in the file itself.
> The SPDX identifier is a legally binding shorthand, which can be used
> instead of the full boiler plate text.
> 
> This work is based on a script and data from Thomas Gleixner, Philippe
> Ombredanne, and Kate Stewart.
> 
> Cc: Thomas Gleixner 
> Cc: Kate Stewart 
> Cc: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 
> ---
> v2: Use the "standard" format of putting the identifier at the top of
> the file, and use // for .c and .h files.
> Removed the files already marked in Linus's tree.
> 
> Unless someone really complains, I'm going to add this to my tree for
> 4.15-rc1.

as you said in some other email... this stands out a bit too
much. What about using normal c comments, and put it near the original
license text? It is not exactly the most important thing...

Or maybe near the MODULE_LICENSE, so the two don't get out of sync?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

v4.15-rc5: resume took way too long, warning in syslog

[Pavel Machek]

Hi!

v4.15-rc5.. resume took _way_ too long, and I have warn_on in dmesg as
a bonus. It looks like USB problem...? I never seen this before.


Pavel

[42266.070103] PM: Syncing filesystems ... done.
[42266.948883] Freezing user space processes ... (elapsed 0.003 seconds) done.
[42266.952336] OOM killer disabled.
[42266.952338] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) 
done.
[42266.956273] Suspending console(s) (use no_console_suspend to debug)
[42267.148227] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[42267.148629] sd 0:0:0:0: [sda] Stopping disk
[42267.225212] e1000e: EEE TX LPI TIMER: 0011
[42267.723975] PM: suspend devices took 0.764 seconds
[42267.796905] ACPI: Preparing to enter system sleep state S3
[42268.140237] ACPI: EC: event blocked
[42268.140242] ACPI: EC: EC stopped
[42268.140247] PM: Saving platform NVS memory
[42268.140275] Disabling non-boot CPUs ...
[42268.159546] smpboot: CPU 1 is now offline
[42268.183574] smpboot: CPU 2 is now offline
[42268.213618] IRQ 19: no longer affine to CPU3
[42268.214663] smpboot: CPU 3 is now offline
[42268.217690] ACPI: Low-level resume complete
[42268.217757] ACPI: EC: EC started
[42268.217758] PM: Restoring platform NVS memory
[42268.218070] Enabling non-boot CPUs ...
[42268.219625] x86: Booting SMP configuration:
[42268.219629] smpboot: Booting Node 0 Processor 1 APIC 0x1
[42268.220144] Disabled fast string operations
[42268.317954]  cache: parent cpu1 should not be sleeping
[42268.318395] CPU1 is up
[42268.320852] smpboot: Booting Node 0 Processor 2 APIC 0x2
[42268.321562] Disabled fast string operations
[42268.421952]  cache: parent cpu2 should not be sleeping
[42268.422447] CPU2 is up
[42268.424900] smpboot: Booting Node 0 Processor 3 APIC 0x3
[42268.425607] Disabled fast string operations
[42268.521949]  cache: parent cpu3 should not be sleeping
[42268.522594] CPU3 is up
[42268.527660] ACPI: Waking up from system sleep state S3
[42269.202432] sdhci-pci :0d:00.0: MMC controller base frequency changed to 
50Mhz.
[42269.239534] iwlwifi :03:00.0: RF_KILL bit toggled to disable radio.
[42269.240825] ACPI: EC: event unblocked
[42269.244977] sd 0:0:0:0: [sda] Starting disk
[42269.489765] usb 1-1.3: reset full-speed USB device number 3 using ehci-pci
[42269.577806] ata2: SATA link down (SStatus 0 SControl 300)
[42269.577851] ata5: SATA link down (SStatus 0 SControl 300)
[42269.677809] usb 1-1.6: reset high-speed USB device number 4 using ehci-pci
[42270.167923] psmouse serio1: synaptics: queried max coordinates: x [..5472], 
y [..4448]
[42270.361825] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[42270.363396] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[42270.363404] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[42270.363409] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[42270.366202] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[42270.366209] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[42270.366215] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[42270.367116] ata1.00: configured for UDMA/133
[42273.571626] e1000e: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow Control: 
Rx/Tx
[42273.571638] e1000e :00:19.0 eth2: 10/100 speed: disabling TSO
[42274.421868] usb 2-1.1.4: reset high-speed USB device number 55 using ehci-pci
[42279.541849] usb 2-1.1.4: device descriptor read/64, error -110
[42295.157864] usb 2-1.1.4: device descriptor read/64, error -110
[42295.345865] usb 2-1.1.4: reset high-speed USB device number 55 using ehci-pci
[42300.533867] usb 2-1.1.4: device descriptor read/64, error -110
[42316.149843] usb 2-1.1.4: device descriptor read/64, error -110
[42316.337864] usb 2-1.1.4: reset high-speed USB device number 55 using ehci-pci
[42327.029859] usb 2-1.1.4: device not accepting address 55, error -110
[42327.113863] usb 2-1.1.4: reset high-speed USB device number 55 using ehci-pci
[42337.781888] usb 2-1.1.4: device not accepting address 55, error -110
[42337.785431] PM: resume devices took 68.544 seconds
[42337.785436] [ cut here ]
[42337.785441] Component: resume devices, time: 68544
[42337.785467] WARNING: CPU: 1 PID: 30277 at kernel/power/suspend_test.c:55 
suspend_test_finish+0x73/0x80
[42337.785471] Modules linked in:
[42337.785483] CPU: 1 PID: 30277 Comm: systemd-sleep Not tainted 4.15.0-rc5 #146
[42337.785487] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET73WW (1.43 ) 
10/12/2016
[42337.785495] RIP: 0010:suspend_test_finish+0x73/0x80
[42337.785500] RSP: :c9000f617cf8 EFLAGS: 00010292
[42337.785509] RAX: 0026 RBX: 84f9320a RCX: 4566332b
[42337.785514] RDX: 0b0ce99a RSI: 8801835a11f8 RDI: 85246380
[42337.785518] RBP: c9000f617d08 R08: 8801835a11d0 R09: 
[42337.785523] R10: 

Re: v4.15-rc5: resume took way too long, warning in syslog

[Pavel Machek]

On Fri 2017-12-29 11:23:36, Alan Stern wrote:
> On Fri, 29 Dec 2017, Pavel Machek wrote:
> 
> > Hi!
> > 
> > v4.15-rc5.. resume took _way_ too long, and I have warn_on in dmesg as
> > a bonus. It looks like USB problem...? I never seen this before.
> 
> Is this problem very repeatable?  Is there any possibility of bisecting 
> to find the cause?

It is first time this happened.. Let me see if it reappears.

But I start to get feeling, that something like this is simply going
to happen from time to time... USB hubs are not exactly high-quality
parts, EMI, ...

Pavel



> > [42269.489765] usb 1-1.3: reset full-speed USB device number 3 using 
> > ehci-pci
> > [42269.577806] ata2: SATA link down (SStatus 0 SControl 300)
> > [42269.577851] ata5: SATA link down (SStatus 0 SControl 300)
> > [42269.677809] usb 1-1.6: reset high-speed USB device number 4 using 
> > ehci-pci
> > [42270.167923] psmouse serio1: synaptics: queried max coordinates: x 
> > [..5472], y [..4448]
> > [42270.361825] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [42270.363396] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) 
> > succeeded
> > [42270.363404] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE 
> > LOCK) filtered out
> > [42270.363409] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) 
> > filtered out
> > [42270.366202] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) 
> > succeeded
> > [42270.366209] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE 
> > LOCK) filtered out
> > [42270.366215] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) 
> > filtered out
> > [42270.367116] ata1.00: configured for UDMA/133
> > [42273.571626] e1000e: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow 
> > Control: Rx/Tx
> > [42273.571638] e1000e :00:19.0 eth2: 10/100 speed: disabling TSO
> > [42274.421868] usb 2-1.1.4: reset high-speed USB device number 55 using 
> > ehci-pci
> > [42279.541849] usb 2-1.1.4: device descriptor read/64, error -110
> > [42295.157864] usb 2-1.1.4: device descriptor read/64, error -110
> > [42295.345865] usb 2-1.1.4: reset high-speed USB device number 55 using 
> > ehci-pci
> > [42300.533867] usb 2-1.1.4: device descriptor read/64, error -110
> > [42316.149843] usb 2-1.1.4: device descriptor read/64, error -110
> > [42316.337864] usb 2-1.1.4: reset high-speed USB device number 55 using 
> > ehci-pci
> > [42327.029859] usb 2-1.1.4: device not accepting address 55, error -110
> > [42327.113863] usb 2-1.1.4: reset high-speed USB device number 55 using 
> > ehci-pci
> > [42337.781888] usb 2-1.1.4: device not accepting address 55, error -110
> 
> > [42337.913753] usb 2-1.1.4: new high-speed USB device number 56 using 
> > ehci-pci
> > [42338.395078] e1000e: eth2 NIC Link is Down
> > [42338.732172] systemd-journald[2470]: Received SIGTERM from PID 1 
> > (systemd).
> > [42339.679602] systemd[1]: Unit systemd-journald.service entered failed 
> > state.
> > [42340.426957] systemd-journald[30462]: Received request to flush runtime 
> > journal from PID 1
> > [42343.029871] usb 2-1.1.4: device descriptor read/64, error -110
> > [42344.483918] e1000e: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow 
> > Control: Rx/Tx
> > [42344.483927] e1000e :00:19.0 eth2: 10/100 speed: disabling TSO
> > [42358.645164] usb 2-1.1.4: device descriptor read/64, error -110
> > [42358.833023] usb 2-1.1.4: new high-speed USB device number 57 using 
> > ehci-pci
> > [42364.018463] usb 2-1.1.4: device descriptor read/64, error -110
> > [42379.626669] usb 2-1.1.4: device descriptor read/64, error -110
> > [42379.735177] usb 2-1.1-port4: attempt power cycle
> > [42380.338299] usb 2-1.1.4: new high-speed USB device number 58 using 
> > ehci-pci
> 
> It sure looks like that USB device (or maybe the hub it was connected 
> to) decided to stop working during the suspend.
> 
> Alan Stern

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> It is used on some Motorola Mapphone series of phones and tablets such
> as Droid 4.
...
> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver. This patch does get us to the point where modem
> data and GPS are usable with libqmi and ModemManager for example.
> Voice calls need more audio driver work.

Thanks for the good work. Looks like I'll need to get droid
4... fortunately it is not available in czech republic so I don't get
excuse to get another toy.

Oh.. no. It is available in Czech republic. Is Motorola Droid 4 XT894
the right one? Hmm, and LTE modem is useless in Europe, while the GSM
one does not work, right?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> > Does ofonod work for you? I could not get that one to work...
> 
> Because it's looking for a Gobi modem but the MDM6600 isn't one and
> doesn't expose that layout (and doesn't really need to anyway).  I
> don't think ofono has a generic QMI driver, so you'd either need to for
> ce it to use the telitqmi or quectelqmi drivers, or write your own
> generic QMI one.

You are right, it is detected as gobi now:

user@devuan:/my/ofono$ sudo python2 test/list-modems
[ /gobi_0 ]
SystemPath =
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
 Features =
 Emergency = 0
 Powered = 0
 Lockdown = 0
 Interfaces =
 Online = 0
 Type = hardware

...and nothing works.

commit db9b292f9290b97c87a8d4b4836af4763c06a39c
Author: Bassem Boubaker 
Date:   Mon Mar 19 17:57:31 2018 +0100

I tried this:

diff --git a/plugins/udevng.c b/plugins/udevng.c
index ff5d41af..6b103254 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1578,8 +1578,6 @@ static struct {
{ "mbm","cdc_ether","0930"  },
{ "mbm","cdc_ncm",  "0930"  },
{ "hso","hso"   },
-   { "gobi",   "qmi_wwan"  },
-   { "gobi",   "qcserial"  },
{ "sierra", "qmi_wwan", "1199"  },
{ "sierra", "qcserial", "1199"  },
{ "sierra", "sierra"},
@@ -1602,6 +1600,8 @@ static struct {
{ "telit",  "cdc_acm",  "1bc7", "0021"  },
{ "telitqmi",   "qmi_wwan", "1bc7", "1201"  },
{ "telitqmi",   "option",   "1bc7", "1201"  },
+   { "telitqmi",   "qmi_wwan", "22b8", "2a70"  },
+   { "telitqmi",   "option",   "22b8", "2a70"  },
{ "nokia",  "option",   "0421", "060e"  },
{ "nokia",  "option",   "0421", "0623"  },
{ "samsung","option",   "04e8", "6889"  },

But no luck:

ofonod[15879]: plugins/udevng.c:create_modem()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[15879]: plugins/udevng.c:create_modem() driver=telitqmi
ofonod[15879]: src/modem.c:ofono_modem_create() name: (null), type:
telitqmi
ofonod[15879]: plugins/udevng.c:setup_telitqmi()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm0
255/251/255 05 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan0 255/251/255 05
(null) net
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm1
255/251/255 06 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan1 255/251/255 06
(null) net
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm2
255/251/255 07 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan2 255/251/255 07
(null) net
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm3
255/251/255 08 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan3 255/251/255 08
(null) net
ofonod[15879]: plugins/udevng.c:destroy_modem()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[15879]: src/modem.c:ofono_modem_remove() 0x596480
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm0
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan0
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm1
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan1
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm2
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan2
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm3
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan3
ofonod[15879]: plugins/upower.c:upower_connect() upower connect
ofonod[15879]: plugins/hfp_hf_bluez5.c:connect_handler() Registering
External Profile handler ...

With quectelqmi result was similar.

I know there are AT commands available at /dev/ttyUSB4. Is there easy
way to make ofonod connect to that?

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

On Sat 2018-03-24 07:25:17, Tony Lindgren wrote:
> * Dan Williams <d...@redhat.com> [180324 14:00]:
> > On Fri, 2018-03-23 at 21:13 +0100, Pavel Machek wrote:
> > > Does ofonod work for you? I could not get that one to work...
> > 
> > Because it's looking for a Gobi modem but the MDM6600 isn't one and
> > doesn't expose that layout (and doesn't really need to anyway).  I
> > don't think ofono has a generic QMI driver, so you'd either need to for
> > ce it to use the telitqmi or quectelqmi drivers, or write your own
> > generic QMI one.
> 
> We also get five USB uarts if we add the device id with something
> like the patch below. I don't quite get why we get five UARTS?

Not sure, either. Often more than one uart is useful, you get AT
commands on one, while GPRS data flow on some other. 

> Also not sure if we should be using drivers/usb/serial/qcaux.c
> instead of qcserial.c?
> 
> And from what I recall trying it out, adding the USB UARTs
> somehow confused ModemManager I think, that needs to be retested
> though :)
> 
> And the USB UARTs added do not offer the same set of AT commands
> as the n_gsm serial mux.

Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it seems
to react to AT commands, and in particular reacts to ADT123; (; is
important).

AT+CMGF=1
AT+CMGS="123"
foo^Z

Works for SMS sending. Good.

(And... Thanks!)

Now, if someone knows what needs to be done to get GSM audio working,
let me know. That's something I'd really like.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> > > > Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it seems
> > > > to react to AT commands, and in particular reacts to ADT123; (; is
> > > > important).
> > > 
> > > Is that to dial a voice call?
> > 
> > Yes. And it is ATD123; not ATD.
> 
> Strange, no semicolon is needed when using /dev/gsmtty to
> dial a voice call with my current pile of pending changes,
> just doing ATD123 dials..

Interesting. Maybe I made some mistake in experiment.

> Anyways, looks like qmi_wwan needs to be loaded before
> qcserial module, otherwise we get nine ttyUSB instances
> and ModemManager can't find any modems.
> 
> With qcserial module loaded after qmi_wwan, it still takes
> a long time for ModemManager to find the modem.
> 
> Then unrelated to the qcserial module, also looks like I can
> no longer use the GPS with ModemManager:
> 
> $ mmcli -m 0 --enable
> $ mmcli -m 0 --location-enable-gps-raw
> 
> And then chmod a+r /dev/cdc-wdm0 and pointing gpsd to use
> /dev/cdc-wdm0 used to work, but now it seems that gpsd
> can no longer read it. Trying to start gpsd manually produces:

Thanks for hints, it would not be bad to get gps working. But .. voice
calls. Those are important :-).

> # gpsd -b -n -N /dev/cdc-wdm0
> gpsd:ERROR: SER: /dev/cdc-wdm0 already opened by another process
> gpsd:ERROR: initial GPS device /dev/cdc-wdm0 open failed
> gpsd:ERROR: can't run with neither control socket nor devices open
> 
> And lsof shows /usr/libexec/qmi-proxy having it open.
> 
> Anybody know what I might be doing wrong? Sounds like something
> now needs to be done with qmi-proxy to get access to GPS?

Maybe kill the proxy and then look at cdc-wdm0 by hand? NMEA can be
parsed by hand... quite easily.

Good night,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> > Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it seems
> > to react to AT commands, and in particular reacts to ADT123; (; is
> > important).
> 
> Is that to dial a voice call?

Yes. And it is ATD123; not ATD.

> > AT+CMGF=1
> > AT+CMGS="123"
> > foo^Z
> > 
> > Works for SMS sending. Good.
> 
> So what do you use for reading notifying and reading sms?

Well, did not try that, but they should just be displayed in the
serial terminal.

Anyway, "good" solution is to get ofonod running, then use ofone from
here: https://github.com/pavelmachek/unicsy_demo

But parsing AT commands is easy enough that I can probably hack it
together in few days if neccessary.

> > Now, if someone knows what needs to be done to get GSM audio working,
> > let me know. That's something I'd really like.
> 
> I think it's the cpcap based config to route voice call audio
> to SoC, Sebastian knows the details :)
> 
> The way to figure that one out is to dump the cpcap registers
> before and during voice call on android with cpcaprw, then
> diff the output for the audio registers. Probably some SoC
> registers need to be diffed too with rwmem or similar tool
> for the mcbsp instance(s) used.

That sounds like hard way to do it. There's source available, I'm now
trying to understand it / fit it into Sebastian's driver.

https://raw.githubusercontent.com/NotKit/android_kernel_motorola_omap4-common/hybris-11.0/sound/soc/codecs/cpcap.c

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> idle lcd off  phy-mapphone-mdm6600ohci-platform
> 153mW 284mW   344mW
> 
> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver. This patch does get us to the point where modem
> data and GPS are usable with libqmi and ModemManager for example.
> Voice calls need more audio driver work.

Ok, let me try. I believe I should see the modem device on lsusb, but
I don't.

user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
sudo lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
zcat /proc/config.gz | grep MAPPH
CONFIG_PHY_MAPPHONE_MDM6600=y
user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
zcat /proc/config.gz | grep OHCI_
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_OMAP3=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$

As far as I can tell,

+CONFIG_USB_WDM=y
+CONFIG_USB_SERIAL=y
+CONFIG_USB_SERIAL_QUALCOMM=y
+CONFIG_USB_SERIAL_WWAN=y

should be enabled to enable the drivers (and I did that), but without
device showing on the bus...

Any ideas?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> > sudo lsusb
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> > zcat /proc/config.gz | grep MAPPH
> > CONFIG_PHY_MAPPHONE_MDM6600=y
> > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> > zcat /proc/config.gz | grep OHCI_
> > CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> > CONFIG_USB_OHCI_HCD=y
> > CONFIG_USB_OHCI_HCD_OMAP3=y
> > CONFIG_USB_OHCI_HCD_PLATFORM=y
> > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> > 
> > As far as I can tell,
> > 
> > +CONFIG_USB_WDM=y
> > +CONFIG_USB_SERIAL=y
> > +CONFIG_USB_SERIAL_QUALCOMM=y
> > +CONFIG_USB_SERIAL_WWAN=y
> > 
> > should be enabled to enable the drivers (and I did that), but without
> > device showing on the bus...
> > 
> > Any ideas?
> 
> Do you have the related dts patches picked from next?
> 
> fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
> e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
> 
> But yeah all you need to do is have phy-mapphone-mdm6600 and
> ohci-platform loaded and then ifconfig should show four wwan
> interfaces being added.

ifconfig? I thought I should get /dev/ttyUSB0..3?

Anyway, that does not seem to work. Something is detected now:

[   10.819549] ALSA device list:
[   10.831787]   #0: HDMI 58006000.encoder
[   10.841186] Waiting 10 sec before mounting root device...
[   10.887573] usb 2-1: New USB device found, idVendor=22b8,
idProduct=2a70
[   10.897521] usb 2-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   10.907684] usb 2-1: Product: Flash MZ600
[   10.914611] usb 2-1: Manufacturer: Motorola, Incorporated
[   20.967193] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to
feature incompatibilities

But qcserial driver does not bind to that. If I attempt to force it:

root@devuan:/sys/bus/usb-serial/drivers/qcserial# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 22b8:2a70 Motorola PCS
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@devuan:/sys/bus/usb-serial/drivers/qcserial# echo "22b8 2a70" >
new_id
[ 2059.267730] usb 2-1: unknown number of interfaces: 9
[ 2059.272949] usb 2-1: unknown number of interfaces: 9
[ 2059.278045] usb 2-1: unknown number of interfaces: 9
[ 2059.283233] usb 2-1: unknown number of interfaces: 9
[ 2059.288330] usb 2-1: unknown number of interfaces: 9
[ 2059.293457] usb 2-1: unknown number of interfaces: 9
[ 2059.298553] usb 2-1: unknown number of interfaces: 9
[ 2059.303680] usb 2-1: unknown number of interfaces: 9
[ 2059.308776] usb 2-1: unknown number of interfaces: 9

I don't get anything useful. Do I need to boot android before booting
Linux or something? How does your lsusb look like?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

Hi!

> > > Do you have the related dts patches picked from next?
> > > 
> > > fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
> > > e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
> > > 
> > > But yeah all you need to do is have phy-mapphone-mdm6600 and
> > > ohci-platform loaded and then ifconfig should show four wwan
> > > interfaces being added.
> > 
> > ifconfig? I thought I should get /dev/ttyUSB0..3?
> 
> I believe they are QMI via qmi_wwan, not TTYs.

Well, qmicli expects device path... and I see nothing on ifconfig. Any
idea how the device would be named?

But I believe it just does not work, see the qcserial experiment with
new_id below.

Best regards,
Pavel

> > But qcserial driver does not bind to that. If I attempt to force it:
> > 
> > root@devuan:/sys/bus/usb-serial/drivers/qcserial# lsusb
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 002 Device 002: ID 22b8:2a70 Motorola PCS
> > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > root@devuan:/sys/bus/usb-serial/drivers/qcserial# echo "22b8 2a70" >
> > new_id
> > [ 2059.267730] usb 2-1: unknown number of interfaces: 9
> > [ 2059.272949] usb 2-1: unknown number of interfaces: 9
> > [ 2059.278045] usb 2-1: unknown number of interfaces: 9
> > [ 2059.283233] usb 2-1: unknown number of interfaces: 9
> > [ 2059.288330] usb 2-1: unknown number of interfaces: 9
> > [ 2059.293457] usb 2-1: unknown number of interfaces: 9
> > [ 2059.298553] usb 2-1: unknown number of interfaces: 9
> > [ 2059.303680] usb 2-1: unknown number of interfaces: 9
> > [ 2059.308776] usb 2-1: unknown number of interfaces: 9
> > 
> > I don't get anything useful. Do I need to boot android before booting
> > Linux or something? How does your lsusb look like?
> > 
> > Thanks,
> > Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Pavel Machek]

On Fri 2018-03-23 12:35:21, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Mar 23, 2018 at 11:54:55AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > Do you have the related dts patches picked from next?
> > > > > 
> > > > > fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
> > > > > e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
> > > > > 
> > > > > But yeah all you need to do is have phy-mapphone-mdm6600 and
> > > > > ohci-platform loaded and then ifconfig should show four wwan
> > > > > interfaces being added.
> > > > 
> > > > ifconfig? I thought I should get /dev/ttyUSB0..3?
> > > 
> > > I believe they are QMI via qmi_wwan, not TTYs.
> > 
> > Well, qmicli expects device path... and I see nothing on ifconfig. Any
> > idea how the device would be named?
> > 
> > But I believe it just does not work, see the qcserial experiment with
> > new_id below.
> 
> Dan is right, you need qmi_wwan driver. qmicli expects
> /dev/cdc-wdm device. I use this on Droid 4:
> 
> qmicli -d /dev/cdc-wdm0 --some-other-option

Aha, there's ./drivers/usb/serial/usb_wwan.c and there's
./drivers/net/usb/qmi_wwan.o . That confused me.

qmicli now works for me, thanks!

Tested-by: Pavel Machek <pa...@ucw.cz>

Does ofonod work for you? I could not get that one to work...

ofonod[4083]: plugins/udevng.c:create_modem()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[4083]: plugins/udevng.c:create_modem() driver=gobi
ofonod[4083]: src/modem.c:ofono_modem_create() name: (null), type:
gobi
ofonod[4083]: plugins/udevng.c:setup_gobi()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm0 255/251/255
05 (null) (null) usbmisc
ofonod[4083]: plugins/udevng.c:setup_gobi() wwan0 255/251/255 05
(null) (null) net
ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm1 255/251/255
06 (null) (null) usbmisc
ofonod[4083]: plugins/udevng.c:setup_gobi() wwan1 255/251/255 06
(null) (null) net
ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm2 255/251/255
07 (null) (null) usbmisc
ofonod[4083]: plugins/udevng.c:setup_gobi() wwan2 255/251/255 07
(null) (null) net
ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm3 255/251/255
08 (null) (null) usbmisc
ofonod[4083]: plugins/udevng.c:setup_gobi() wwan3 255/251/255 08
(null) (null) net
ofonod[4083]: plugins/udevng.c:destroy_modem()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[4083]: src/modem.c:ofono_modem_remove() 0x5eb380
ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm0
ofonod[4083]: plugins/udevng.c:destroy_modem() wwan0
ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm1
ofonod[4083]: plugins/udevng.c:destroy_modem() wwan1
ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm2
ofonod[4083]: plugins/udevng.c:destroy_modem() wwan2
ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm3
ofonod[4083]: plugins/udevng.c:destroy_modem() wwan3
ofonod[4083]: plugins/upower.c:upower_connect() upower connect
ofonod[4083]: plugins/hfp_hf_bluez5.c:connect_handler() Registering
External Profile handler ...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature