Re: staging:DWC2 USB driver issues

On Tue 2013-08-27 12:22:59, Matthijs Kooijman wrote: Hi Dinh, Any chance anyone has a similar experience with this DWC2 driver, any help will greatly appreciated. Of course, I will go back and verify the initialization between the DWC2 and the old driver to see if I can spot anything.

Re: staging:DWC2 USB driver issues

Hi! I was wondering if anyone has come across the problem I am experiencing with the staging DWC2 driver. The problem is that the driver is failing to detect a device when connected. I know that HW works because I have an older version of the driver for this IP and it seems to work OK,

Fix style in s3c-hsotg.c

Hi! checkpatch.pl has some valid complaints about style in s3c-hsotg.c : macro with if should be really enclosed in do {} while, and puts is going to be slightly faster. Here's suggested patch. I don't have the hardware, so it is completely untested. Signed-off-by: Pavel Machek, pa...@denx.de

Re: Fix style in s3c-hsotg.c

On Tue 2013-09-17 10:42:30, Felipe Balbi wrote: Hi, On Mon, Sep 02, 2013 at 03:58:32PM +0200, Pavel Machek wrote: Hi! checkpatch.pl has some valid complaints about style in s3c-hsotg.c : macro with if should be really enclosed in do {} while, and puts is going to be slightly faster

Re: Fix style in s3c-hsotg.c

On Tue 2013-09-17 20:45:39, Felipe Balbi wrote: On Wed, Sep 18, 2013 at 12:04:27AM +0200, Pavel Machek wrote: On Tue 2013-09-17 10:42:30, Felipe Balbi wrote: Hi, On Mon, Sep 02, 2013 at 03:58:32PM +0200, Pavel Machek wrote: Hi! checkpatch.pl has some valid complaints

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi! So will you do that? Or it is needed to resend this one line hunk again in new email again? new patch, new email Guys, WHY ARE YOU SO STUPID AND ARROGANT? Sorry but, need to copy full isolated patch/hunk from one mail to another is hassling. So what you want from me? Do

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi! So will you do that? Or it is needed to resend this one line hunk again in new email again? new patch, new email Guys, WHY ARE YOU SO STUPID AND ARROGANT? Sorry but, need to copy full isolated patch/hunk from one mail to another is hassling. So what you want from

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi! gave feedback. If the sender doesn't want to take his feedback into account and prefer to send pretty insulting emails instead that is his choice but I would say that is this not the greatest approach to get your code merged (to say the least). Clearly not. But Pali found bug in

Re: Fix style in s3c-hsotg.c

is a driver for our hardware so I'm going to pick this patch up, polish it and then re-submit it later. Thanks. Here's version that should compile. Thanks, Pavel Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/drivers/usb/gadget

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

On Wed 2013-09-25 15:33:33, Felipe Balbi wrote: Hi, On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote: On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote: twl-phy.notifier is not initalized Signed-off-by: Pali Rohár pali.ro...@gmail.com diff --git

Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia

On Mon 2013-01-21 10:05:06, Felipe Balbi wrote: Hi, On Sun, Jan 20, 2013 at 11:17:31AM +0100, Pali Rohár wrote: On Sunday 20 January 2013 10:25:37 Felipe Balbi wrote: On Sun, Jan 20, 2013 at 03:58:13AM +0100, Pali Rohár wrote: Signed-off-by: Pali Rohár pali.ro...@gmail.com NAK

Re: power_state: remove it from usb

On Thu 2008-02-21 16:50:36, Alan Stern wrote: On Thu, 21 Feb 2008, Pavel Machek wrote: power_state is scheduled for removal, and it is used only write-only by USB. Remove it. Unfortunately some of the things you changed turn out not to be write-only. (You also missed a usage

Re: [PATCH] usb: musb: Fix obex in g_nokia.ko causing kernel panic

Hi! From: Felipe Balbi ba...@ti.com This patch, which is present in 3.14-rc4 as 30a70b026 (usb: musb: fix obex in g_nokia.ko causing kernel panic), breaks USB gadget support on my Pandaboard. Bisecting points to this commit, reverting it makes USB gadget support work again. The problem

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On Wed 2013-11-20 11:52:05, Ulf Hansson wrote: On 19 November 2013 16:35, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 19 Nov 2013, Ulf Hansson wrote: At the moment, system PM is already affecting behaviour of runtime PM since it is preventing runtime suspend during system suspend.

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

On Wed 2013-11-20 11:58:31, Alan Stern wrote: On Wed, 20 Nov 2013, Ulf Hansson wrote: Do note that, the intent with my RFC is also to simplify for drivers in general using runtime PM. No matter how you put it, the consequences of preventing runtime suspend during system suspend are

Re: BUG: usb: obex in g_nokia.ko causing kernel panic

On Tue 2013-11-26 18:17:49, Sebastian Reichel wrote: On Tue, Nov 26, 2013 at 06:10:22PM +0100, Pali Rohár wrote: On Tuesday 19 November 2013 11:51:12 Pali Rohár wrote: For a long time (since 3.5 or 3.8? - I do not remember) obex subdriver in g_nokia usb gadget module causing kernel panic

Re: [RFC/PATCH 1/3] pm: make PM macros more smart

On Thu 2013-12-12 21:18:23, David Cohen wrote: This patch makes SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS() more smart. Despite those macros check for '#ifdef CONFIG_PM_SLEEP/RUNTIME' to avoid setting the callbacks when such #ifdef's aren't defined, they don't handle compiler to

Re: [RFC/PATCH 1/3] pm: make PM macros more smart

On Sun 2013-12-15 11:25:08, David Cohen wrote: On Sun, Dec 15, 2013 at 06:51:12PM +0100, Pavel Machek wrote: On Thu 2013-12-12 21:18:23, David Cohen wrote: This patch makes SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS() more smart. Despite those macros check for '#ifdef

Re: [PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels

On Thu 2014-06-12 23:34:12, Janne Kanniainen wrote: This driver adds support for USB controlled led panels that exists in MSI GT683R laptop Hi! --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r @@ -0,0 +1,10 @@ +What:

Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls

On Tue 2015-02-03 13:18:59, Felipe Balbi wrote: On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi

Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls

In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step, figure why it's broken. Working just fine here on AM335x which has the same musb IP. Why is broken? That is

Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls

On Fri 2015-02-20 08:39:06, Felipe Balbi wrote: On Fri, Feb 20, 2015 at 09:27:51AM +0100, Pavel Machek wrote: In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step

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

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

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

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

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 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: 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: 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)]

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

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

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

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

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

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

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

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

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

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

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

  1   2   >