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

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

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

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

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

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

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

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 fo

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

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? > > > > > > > > > &

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

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 > > >

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

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$ >

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

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

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

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

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

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. >

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

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

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

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. &g

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

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

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

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

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

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

v4.13-rc2: usb mouse stopped working?

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

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

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:

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

> > > > > ...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 > > > > >

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

On Thu 2017-02-23 17:28:26, Frederic Weisbecker wrote: > On Tue, Feb 14, 2017 at 08:27:43PM +0100, Pavel Machek wrote: > > On Tue 2017-02-14 18:59:56, Pavel Machek wrote: > > > Hi! > > > > > > > > > > Hmm. I moved keyboard between USB

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

On Thu 2017-02-16 12:21:13, Linus Torvalds wrote: > On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek <pa...@ucw.cz> wrote: > > > > Hmm, that would explain problems at boot _and_ problems during > > suspend/resume. > > I've committed the revert, and I'm just assu

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

On Fri 2017-02-17 17:37:47, Thomas Gleixner wrote: > On Fri, 17 Feb 2017, Frederic Weisbecker wrote: > > On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote: > > > On Thu, 16 Feb 2017, Frederic Weisbecker wrote: > > > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote: >

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

On Thu 2017-02-16 12:21:13, Linus Torvalds wrote: > On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek <pa...@ucw.cz> wrote: > > > > Hmm, that would explain problems at boot _and_ problems during > > suspend/resume. > > I've committed the revert, and I'm just assu

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

On Thu 2017-02-16 20:34:45, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Frederic Weisbecker wrote: > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote: > > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker > > > wrote: > > > > > > > > I haven't followed

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

On Thu 2017-02-16 18:25:35, Pavel Machek wrote: > Hi! > > > > > 4.10-rc4 broken > > > > 4.10-rc3 ok > > > > > > Hmm. If those actually end up being reliable, then there's not a whole > > > lot in between them wrt PCI or USB. >

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

Hi! > > > 4.10-rc4 broken > > > 4.10-rc3 ok > > > > Hmm. If those actually end up being reliable, then there's not a whole > > lot in between them wrt PCI or USB. > > > > What looked like the most likely candidate seems to be xhci-specific, > > though. > > > > But maybe it's something that

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

Hi! On Wed 2017-02-15 15:34:27, Linus Torvalds wrote: > On Wed, Feb 15, 2017 at 3:20 PM, Pavel Machek <pa...@ucw.cz> wrote: > > 4.10-rc4 broken > > 4.10-rc3 ok > > Hmm. If those actually end up being reliable, then there's not a whole > lot in between them wrt PCI

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

On Wed 2017-02-15 18:23:03, Pavel Machek wrote: > On Tue 2017-02-14 11:12:26, Linus Torvalds wrote: > > On Feb 14, 2017 9:59 AM, "Pavel Machek" <pa...@ucw.cz> wrote: > > > > Hi! > > > > > > > > > > Booting to

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

On Tue 2017-02-14 11:12:26, Linus Torvalds wrote: > On Feb 14, 2017 9:59 AM, "Pavel Machek" <pa...@ucw.cz> wrote: > > Hi! > > > > > > > Booting to grub, then hitting ctrl-alt-del is enough to make it work. > Ouch. > > > > > > I

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

On Tue 2017-02-14 18:59:56, Pavel Machek wrote: > Hi! > > > > > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer > > > > > boots. v4.6 works ok. Let me try with keyboard unplugged... no, I > > > > > could not get it

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

Hi! > > > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer > > > > boots. v4.6 works ok. Let me try with keyboard unplugged... no, I > > > > could not get it to work. I believe v4.9 and some v4.10-rc's worked, > > > > but I'll have to double check. > > > > > > But all the

Re: v4.9 to v4.10 regression: oops when USB cable is plugged in.

On Fri 2017-02-03 08:30:48, Tony Lindgren wrote: > * Pavel Machek <pa...@ucw.cz> [170203 00:00]: > > Hi! > > > > > On Fri, Jan 27, 2017 at 10:55:12PM +0100, Pavel Machek wrote: > > > > Ok, I can try. But so far even -rc1 is a lot of fun. But... I

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

On Fri 2017-02-03 16:59:05, Alan Stern wrote: > On Fri, 3 Feb 2017, Pavel Machek wrote: > > > Hi! > > > > > > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer > > > > > boots. v4.6 works ok. Let me try with keyboard unplugge

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

Hi! > > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer > > > boots. v4.6 works ok. Let me try with keyboard unplugged... no, I > > > could not get it to work. I believe v4.9 and some v4.10-rc's worked, > > > but I'll have to double check. > > > > But all the kernel

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

Hi! > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer > > boots. v4.6 works ok. Let me try with keyboard unplugged... no, I > > could not get it to work. I believe v4.9 and some v4.10-rc's worked, > > but I'll have to double check. > > But all the kernel versions worked

v4.10-rc6 boot regression on Intel desktop, maybe related to EHCI hadnoff?

Hi! Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer boots. v4.6 works ok. Let me try with keyboard unplugged... no, I could not get it to work. I believe v4.9 and some v4.10-rc's worked, but I'll have to double check. Machine is small Intel desktop: 00:00.0 Host bridge:

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

Hi! > Is this possible to mix various entries in a list assigned to single > property? > Let's say: > trigger-sources = > <_port1>, > <_port1>, > < 1 GPIO_ACTIVE_HIGH>; Actually... I'm not sure I like the "multiple sources". It is somehow justified for

Re: v4.9 to v4.10 regression: oops when USB cable is plugged in.

Hi! > On Fri, Jan 27, 2017 at 10:55:12PM +0100, Pavel Machek wrote: > > Ok, I can try. But so far even -rc1 is a lot of fun. But... I consider > > phone calls core feature of a phone. I'd very much like to get that to > > work. Unfortunately, that means real-time audio, and a

Re: v4.9 to v4.10 regression: oops when USB cable is plugged in.

Hi! > > > Can I get the copy of the patch? > > > > > > http://www.spinics.net/lists/linux-usb/msg152542.html > > > > > > ...but it is html mangled with no obvious way to unmangle it. > > Bounced it to you. FYI, patchwork.kernel.org should have it too, the > "mbox" option there works the best.

Re: v4.9 to v4.10 regression: oops when USB cable is plugged in.

Hi! On Mon 2017-01-23 14:44:54, Tony Lindgren wrote: > * Pavel Machek <pa...@ucw.cz> [170123 14:26]: > > [25392.239837] Unhandled fault: external abort on non-linefetch (0x1028) at > > 0xfa0ab060 > > [25392.239868] pgd = c0004000 > > [25392.239898] [fa0ab060] *pg

v4.9 to v4.10 regression: oops when USB cable is plugged in.

Hi! v4.9 was ok (this is annoying enought that I'd notice). v4.10-rc5 is not. (And yes, I probably [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.10.0-rc5-142127-g41f2839-dirty (pavel@amd) (gcc version 4.7.2 (GCC) ) #222 Mon Jan 23 15:13:11 CET 2017 [

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

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

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

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

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

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

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

On Thu 2016-09-15 15:33:19, Rafał Miłecki wrote: > On 15 September 2016 at 14:56, Pavel Machek <pa...@ucw.cz> wrote: > > On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: > >> On 9 September 2016 at 13:05, Greg KH <gre...@linuxfoundation.org> wrote: > >> >

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: > On 9 September 2016 at 13:05, Greg KH wrote: > > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: > >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: > >> > From: Rafał Miłecki

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Hi! > > That's not actually 100% clear to me - for what the wm831x is doing it > > probably *does* want the higher limit. This is a system inflow limit > > (as it should be for this), at least the charger will adapt to voltage > > variations though other users in the system are much less likely

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

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

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

Hi! > >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

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

On Thu 2016-08-25 20:48:04, Jacek Anaszewski wrote: > On 08/25/2016 04:30 PM, Alan Stern wrote: > >On Thu, 25 Aug 2016, Jacek Anaszewski wrote: > > > >>I'd see it as follows: > >> > >>#cat available_ports > >>#1-1 1-2 2-1 > >> > >>#echo "1-1" > new_port > >> > >>#cat observed_ports > >>#1-1 > >> >

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

On Thu 2016-08-25 11:04:38, Jacek Anaszewski wrote: > On 08/25/2016 10:29 AM, Rafał Miłecki wrote: > >On 25 August 2016 at 10:03, Jacek Anaszewski > >wrote: > >>On 08/24/2016 07:52 PM, Rafał Miłecki wrote: > >>> > >>>From: Rafał Miłecki > >>> >

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun 2016-08-14 18:06:53, Pavel Machek wrote: > On Sun 2016-08-14 12:14:38, Pavel Machek wrote: > > On Sun 2016-08-14 11:20:44, Pavel Machek wrote: > > > Hi! > > > > > > > It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun 2016-08-14 10:56:54, Alan Stern wrote: > On Sun, 14 Aug 2016, Pavel Machek wrote: > > > > That being said, it would be great if the original reporter could use > > > 'git bisect' and let the linux-usb and linux-scsi mailing list know what > > > the of

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun 2016-08-14 12:14:38, Pavel Machek wrote: > On Sun 2016-08-14 11:20:44, Pavel Machek wrote: > > Hi! > > > > > It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices > > > are probed before SATA drivers. That is pretty anti-social. It > >

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Hi! > > > > I have no idea how "SATA before USB" had been done in the past (if it > > > > was ever a thing in the kernel), but that has not been the case since > > > > at least v3.0 AFAIR. > > > > > > > > > > > > > > People may not run udev, and you can't use /dev/disk/by-id on kernel > > > > >

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Hi! On Sun 2016-08-14 18:17:39, Tom Yan wrote: > On 14 August 2016 at 18:07, Tom Yan <tom.t...@gmail.com> wrote: > > On 14 August 2016 at 18:01, Pavel Machek <pa...@ucw.cz> wrote: > >> > >> Since SATA support was merged, certainly since v2.4, and from

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun 2016-08-14 11:20:44, Pavel Machek wrote: > Hi! > > > It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices > > are probed before SATA drivers. That is pretty anti-social. It > > broke my boot on my primary machine, and unfortunately due to BIOS >

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

v/disk/by-id/*). Since SATA support was merged, certainly since v2.4, and from way before /dev/disk/by-id existed. People may not run udev, and you can't use /dev/disk/by-id on kernel command line. Pavel > On 14 August 2016 at 17:20, P

Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Hi! > It seems that in v4.8-rc0, /dev/sdX got reordered, and now USB devices > are probed before SATA drivers. That is pretty anti-social. It > broke my boot on my primary machine, and unfortunately due to BIOS > problems (keyboard does not work when connected through a hub) it is > less fun than

Re: Is it ok if ModemManager process is killed AFTER network-interface is brought up and IP-Address assigned?

Hi! > > We are using Sierra's USB-to-WWAN driver on Ubuntu-14 for Sierra's > > MC8090 modem, and we have a requirement wherein we need to have access > > to the modem-serial-port (from our user-application that is). > > > > Right now, we see that /usr/sbin/ModemManager is always connected to > >

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

Hi! > > With these boards, you will not see anything on the screen that is > > attached to a Type-C connector until the OS has booted to the point > > where it has negotiated the power contract and entered a mode. > > > > If the system has BIOS/FW/EC capable of negotiating the power contract > >

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

On Mon 2016-07-18 08:55:52, Rafał Miłecki wrote: > On 18 July 2016 at 07:53, Peter Chen wrote: > > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote: > >> On 18 July 2016 at 07:40, Peter Chen wrote: > >> > On Mon, Jul 18, 2016 at

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

Hi! > > @@ -0,0 +1,206 @@ > > +/* > > + * USB port LED trigger > > + * > > + * Copyright (C) 2016 Rafał Miłecki > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published

Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote: > From: "Du, Changbin" > > On most platforms, there is only one device controller available. > In this case, we desn't care the UDC's name. So let's ignore the > name by setting 'UDC' to 'any'. And also we can change

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote: > The purpose of this class is to provide unified interface for user > space to get the status and basic information about USB Type-C > Connectors in the system, control data role swapping, and when USB PD > is available, also power role swapping

Re: [PATCH v8 1/4] gadget: Introduce the usb charger framework

Hi! > +/* > + * Sysfs attributes: > + * > + * These sysfs attributes are used for showing and setting different type > + * (SDP/DCP/CDP/ACA) chargers' current limitation. > + */ > +static ssize_t sdp_limit_show(struct device *dev, > + struct device_attribute *attr, > +

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! > > Of course, we may do something sensible by default. But manual > > controls should still be present. You called them "stupid" but they > > are not. > > > > Note that just because you detected wall charger does not even mean > > you are connected to wall charger. See the link below. > >

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

On Mon 2016-04-18 14:42:58, Felipe Balbi wrote: > > Hi, > > Pavel Machek <pa...@ucw.cz> writes: > > On Mon 2016-04-18 13:55:17, Felipe Balbi wrote: > >> > >> Hi, > >> > >> Felipe Balbi <ba...@kernel.org> writes: > >&g

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! On Mon 2016-04-18 10:59:23, David Laight wrote: > From: Pavel Machek > > Sent: 18 April 2016 11:40 > ... > > > >> > Actually, less is not stupid. Charging li-ion battery from li-ion > > > >> > battery might > > > >> > b

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

On Mon 2016-04-18 13:55:17, Felipe Balbi wrote: > > Hi, > > Felipe Balbi writes: > >> But cellphone user knows what he connected his charger to, and that's > >> why it is useful to be able to lower the current. Even when you said > >> "less is just stupid" I demonstrated it is

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! > >> manually ??? Hell no! Charger IC should be able to do this no > >> problem. I would be surprised if there's any charger IC out there which > >> blindly connects a 1.8A load from the start. What these ICs do is that > >> they slowly increment the load and check voltage level. They'll

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

On Mon 2016-04-18 13:30:54, Felipe Balbi wrote: > > Hi, > > Pavel Machek <pa...@ucw.cz> writes: > >> > Very often, you want to charge using 1.8A from an old desktop PC. > >> > >> if that old desktop's port is not a charging port, you shouldn't b

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! > >> > a) you are connected to a dedicated charger > >> > > >> > In this case, you can get up to 2000mA depending on the charger. > >> > > >> > If $this charger can give you or not 2000mA is not detectable, > >> > so what do charging ICs do ? They slowly increase the

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! > >> >>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT) > >> >> > >> >> According to the spec we should always be talking about unit loads (1 > >> >> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not > >> >> work for SS capable ports and SS gadgets (we

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>How about implementing patterns as a specific typer of triggers? > >>Let's say we have ledtrig-rgb-pattern: > > > >Well, we'd need ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, ... , as we > >can have more than one rgb led. But yes. > > Triggers can have many listeners, i.e.

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! > > It's your HW :-) You tell me if it's really necessary. But, hey, if you > > get enumerated @500mA, this is the host telling you it _CAN_ give you > > 500mA. In that case, why wouldn't you ? Dunno, perhaps not to drain battery in host too quickly? Or perhaps you are charging from external

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

Hi! > >>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT) > >> > >> According to the spec we should always be talking about unit loads (1 > >> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not > >> work for SS capable ports and SS gadgets (we have quite a

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

Hi! > >> Also, because soon enough we will have to support USB Power Delivery > >> with Type C connector, this is bound to change in the coming months. > >> > >> Frankly, I wanted all of this to be decided in userland with the > >> kernel just providing notification and basic safety checks (we

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>>What's tricky about patterns is that you need to control 3 (or more) > >>>leds at a time. Problem you are trying to solve here is ... control of > >>>3 leds, at the same time. > >>> > >>>So let's solve them together. > >> > >>OK, now I've got your point. So we'd need to have a means for

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>The "color" attribute would contain "R G B" values. Setting the "color" > >>attribute of any of the three LED class devices would affect brightness > >>properties (i.e. constituent colors) of the remaining two ones. > >>It would result in disabling any active triggers and writing all the

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >As I see it the current blinking support then would be one special case of a > >pattern. > >As a consequence once having pattern support we might be able to switch > >users of blinking > >to pattern and remove the blinking support. > > Let's split patterns related discussion into a

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > > We would probably need additional op in the LED core : color_set. > > > > Having the color set to nonzero value would signify the the three LED > > class devices are in sync and that setting a trigger on any of them > > applies to the remaining two ones. It would have to be considered >

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >Lets say we have > > > >/sys/class/pattern/lp5533::0 > >/sys/class/pattern/software::0 > > > >/sys/class/led/n900::red ; default trigger "lp5533::0:0" > >/sys/class/led/n900::green ; default trigger "lp5533::0:1" > >/sys/class/led/n900::blue ; default

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > It would have the same downsides as in case of having r, g and b in > separate attributes, i.e. - problems with setting LED colour in > a consistent way. This way LED blinking in whatever colour couldn't > be supported reliably. It was one of your primary rationale standing

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>It would have the same downsides as in case of having r, g and b in > >>separate attributes, i.e. - problems with setting LED colour in > >>a consistent way. This way LED blinking in whatever colour couldn't > >>be supported reliably. It was one of your primary rationale standing >

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>The main drawback is that you can't set the colour at one go, > >>but have to set brightness of each LED class device (R,G,B) > >>separately. It incurs delays between setting each colour component. > > > >Yeah. Well, on some hardware, that's just the way it is. If the leds > >are separate

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>>pavel@duo:~$ ls -1 /sys/class/leds/ > >>>tpacpi:green:batt > >>>tpacpi:orange:batt > >>> > >>>This is physically 2 leds but hidden under one indicator, so you got > >>>"off", "green", "orange" and "green+orange". > >> > >>That's a good example. As long as you can recognize green+orange

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote: > Hi Heiner and Pavel, > > On 03/29/2016 10:38 PM, Heiner Kallweit wrote: > >Am 29.03.2016 um 12:02 schrieb Pavel Machek: > >>Hi! > >> > >>First, please Cc me on RGB color support. > &g

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > > pavel@duo:~$ ls -1 /sys/class/leds/ > > tpacpi:green:batt > > tpacpi:orange:batt > > > > This is physically 2 leds but hidden under one indicator, so you got > > "off", "green", "orange" and "green+orange". > > That's a good example. As long as you can recognize green+orange as >

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >Ideally, I'd like to have "triggers", but different ones. As in: if > >charging, do yellow " .xX" pattern. If fully charged, do green steady > >light. If message is waiting, do blue " x x" pattern. If none of > >above, do slow white blinking. (Plus priorities of events). But that's >

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > > To be fair... they _are_ separate LED devices. In N900 case, you can > > even see light comming from slightly different places if you look closely. > > > I mainly work with encapsulated USB HID LED devices like Thingm blink(1). > Due to the diffuse plastic cover you don't see the

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > > One driver for this extension was the idea of triggers using color > > to visualize states etc. > > Therefore it's not only about userspace controlling the color. > > As a trigger is bound to a led_classdev we need a led_classdev > > representing a RGB LED device. > > > > And ok: If

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > > First, please Cc me on RGB color support. > > > >> Add generic support for RGB Color LED's. > >> > >> Basic idea is to use enum led_brightness also for the hue and saturation > >> color components.This allows to implement the color extension w/o > >> changes to struct led_classdev. > >>

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

On Tue 2016-03-01 22:36:12, Heiner Kallweit wrote: > Export a function to convert HSV color values to RGB. > It's intended to be called by drivers for RGB LEDs. > > Signed-off-by: Heiner Kallweit > --- > v2: > - move hsv -> rgb conversion to separate file > - remove flag

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! First, please Cc me on RGB color support. > Add generic support for RGB Color LED's. > > Basic idea is to use enum led_brightness also for the hue and saturation > color components.This allows to implement the color extension w/o > changes to struct led_classdev. > > Select LEDS_RGB to

Re: [PATCH v5 2/4] leds: core: add color LED sysfs extension

On Tue 2016-03-01 22:28:00, Heiner Kallweit wrote: > Extend brightness sysfs property handling to deal with monochrome > and color mode as well. > > Signed-off-by: Heiner Kallweit > --- > v2: > - split from patch 1 > v3: > - moved one change (led_is_off) to patch 1 > v4: >

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

HI! > > + int ret; > > + > > + mutex_lock(>lock); > > + ret = raw_notifier_chain_unregister(>nh, nb); > > Greg, this is the kind of thing I wanted to avoid adding more of. > > I was wondering if you would accept subsystems using kdbus for > this sort of notification. I'm okay waiting for

Re: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework

Hi! > On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote: > > On 14 August 2015 at 23:27, Greg KH wrote: > >> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: > >>> + * > >>> + * This program is free software; you can redistribute it and/or

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

Hi! > > What's the advantage of pushing this to userspace? By the time we > > provide enough discoverability to enable userspace to configure itself > > it seems like we'd have enough information to do the job anyway. > > you're going to be dealing with a setup where each vendor does one thing

Re: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework

Hi! > > > * This program is free software; you can redistribute it and/or modify > > > * it under the terms of the GNU General Public License version 2 as > > > * published by the Free Software Foundation. > > > > Please, keep it V2 or later, if you can. It makes sharing code with U-Boot > >

Re: [PATCH 0/2] Allow twl4030_charger to find phy reliably.

-by: Pavel Machek pa...@ucw.cz -- Signature Smiley -- (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

  1   2   >