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 a
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 UDC name
> at any time
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\:shel
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
[0.
Hi!
On Mon 2017-01-23 14:44:54, Tony Lindgren wrote:
> * Pavel Machek [170123 14:26]:
> > [25392.239837] Unhandled fault: external abort on non-linefetch (0x1028) at
> > 0xfa0ab060
> > [25392.239868] pgd = c0004000
> > [25392.239898] [fa0ab060] *pgd=48011452(bad)
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 t
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
> >> >
> >> > This commit adds a new trigg
On Thu 2016-09-15 15:33:19, Rafał Miłecki wrote:
> On 15 September 2016 at 14:56, Pavel Machek wrote:
> > 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
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 b
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
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 by
> > + * the Free Softwa
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 06:44:49AM +0200, Rafał Miłecki wrote:
> >> >> On 18 Ju
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
> >
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
> >
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
(e.g. /dev/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
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
>
Hi!
On Sun 2016-08-14 18:17:39, Tom Yan wrote:
> On 14 August 2016 at 18:07, Tom Yan wrote:
> > On 14 August 2016 at 18:01, Pavel Machek wrote:
> >>
> >> Since SATA support was merged, certainly since v2.4, and from way
> >> before /dev/disk/by-id exist
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
> > > > >
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
> >
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
> > >
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
> >
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
> >>>
> >>>This commit adds a new trigger responsible for t
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
> >>
>
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 s
On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
> On 29 August 2016 at 10:05, Pavel Machek wrote:
> >> >2) Having "ports" subdir with RW files, one per each existing physical
> >> >port
> >> >In this situation we don't need "new_port&q
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:
> - changed printf format
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 enab
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 LED_DEV_CAP_RGB
> v3:
> -
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.
> >>
>
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 requi
Hi!
> >Ok, so:
> >
> >a) Do we want RGB leds to be handled by existing subsystem, or do we
> >need separate layer on top of that?
> >
> >b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> >and it is what hardware implements. (But we'd need to do gamma
> >correction).
> >
> >c)
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 individu
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
> >quite
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
> separate
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
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
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
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
> >>behin
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
>
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 trigger
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
> >
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 separ
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
>
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 d
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 do
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
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 few
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. led_trigger_e
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 h
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 at
On Mon 2016-04-18 13:30:54, Felipe Balbi wrote:
>
> Hi,
>
> Pavel Machek 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 be
> &g
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 conti
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 not, at least in c
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
On Mon 2016-04-18 14:42:58, Felipe Balbi wrote:
>
> Hi,
>
> Pavel Machek writes:
> > On Mon 2016-04-18 13:55:17, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Felipe Balbi writes:
> >> >> But cellphone user knows what he con
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.
>
> th
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,
> +
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.
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,
Hi!
> Is this possible to mix various entries in a list assigned to single
> property?
> Let's say:
> trigger-sources =
> <&ohci_port1>,
> <&ehci_port1>,
> <&gpio 1 GPIO_ACTIVE_HIGH>;
Actually... I'm not sure I like the "multiple sources". It is somehow
jus
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: Intel
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 when
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
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
On Fri 2017-02-03 08:30:48, Tony Lindgren wrote:
> * Pavel Machek [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 consider
> > > &g
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 ker
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
On Tue 2017-02-14 11:12:26, Linus Torvalds wrote:
> On Feb 14, 2017 9:59 AM, "Pavel Machek" wrote:
>
> Hi!
>
> > >
> > > Booting to grub, then hitting ctrl-alt-del is enough to make it work.
> Ouch.
> > >
> > > It happens with curre
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" wrote:
> >
> > Hi!
> >
> > > >
> > > > Booting to grub, then hitting ctrl-alt-del is enou
Hi!
On Wed 2017-02-15 15:34:27, Linus Torvalds wrote:
> On Wed, Feb 15, 2017 at 3:20 PM, Pavel Machek 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 or USB.
>
&g
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 isn
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.
>
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 the discussion but th
On Thu 2017-02-16 12:21:13, Linus Torvalds wrote:
> On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote:
> >
> > Hmm, that would explain problems at boot _and_ problems during
> > suspend/resume.
>
> I've committed the revert, and I'm just assuming that
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:
> >
On Thu 2017-02-16 12:21:13, Linus Torvalds wrote:
> On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote:
> >
> > Hmm, that would explain problems at boot _and_ problems during
> > suspend/resume.
>
> I've committed the revert, and I'm just assuming that
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
> > > > > ...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
> > > > > start
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
> > an
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 O
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,
di
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 {} w
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!
> >> > 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
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
> >> > an
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
f to do than babysitting grown ups.
>
> ..even if it could have been communicated in a gentler way.
>
> Anyway 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. Thank
Hi!
> > Pavel, Felipe's remark was valid..
> >
> > > > No, I'll not polish patch for hardware I don't have and have little
> > > > interest in. wanted to help you, but according to your first reply,
> > > > you do not really want help.
> > >
> > > that's your call. Now how about you stop being
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
> > >
> > > diff --git a/drivers/u
On Wed 2013-11-20 11:52:05, Ulf Hansson wrote:
> On 19 November 2013 16:35, Alan Stern 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.
> >
> > Sure.
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
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 kerne
Hi!
> > +#define S3C_PHYPWR (0x00)
...
> > +#define S3C_PHYCLK (0x04)
> > +
> > +#define S3C_PHYCLK_MODE_SERIAL (1 << 6)
> > +#define S3C_PHYCLK_EXT_OSC (1 << 5)
> > +#define S3C_PHYCLK_COMMON_ON_N
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
> > >
> > > NAK for
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
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.
> > >
power_state is scheduled for removal, and it is used only write-only
by USB. Remove it.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 801b6f1..eeb8115 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/us
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
Hi!
> > From: Felipe Balbi
>
> 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 is t
1 - 100 of 150 matches
Mail list logo
