Fix the following sparse warning:
drivers/usb/phy/phy-samsung-usb2.c:50:26: sparse: incorrect type in argument 1
(different address spaces)
drivers/usb/phy/phy-samsung-usb2.c:50:26:expected void const volatile
[noderef] *addr
drivers/usb/phy/phy-samsung-usb2.c:50:26:got void *
Cc: Vivek
Here's an updated series of fixes for 3.9-final.
The first four patches and the mos7840 broken-TIOCMIWAIT-patch are
unchanged from previous postings, and the remaining patches fix two
use-after-free in all usb-serial TIOCMIWAIT implementations: the private
wait-queue along with any other data may
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Make sure waiting processes are woken on modem-status changes.
Currently processes are only woken on termios changes regardless of
whether the modem status has changed.
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7840.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletio
Unregister tty device in disconnect as is required by the USB stack.
By deferring unregistration to when the last tty reference is dropped,
the parent interface device can get unregistered before the child
resulting in broken hotplug events being generated when the tty is
finally closed:
KERNEL[2
Add missing get_icount field to two-port driver.
The two-port driver was not updated when switching to the new icount
interface in commit 0bca1b913aff ("tty: Convert the USB drivers to the
new icount interface").
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 1 +
1 fi
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Add modem-status-change wait queue to struct usb_serial_port that
subdrivers can use to implement TIOCMIWAIT.
Currently subdrivers use a private wait queue which may have been
released when waking up after device disconnected.
Note that we're adding a new wait queue rather than reusing the tty-po
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Remove bogus disconnect test introduced by 95bef012e ("USB: more serial
drivers writing after disconnect") which prevented queued data from
being freed on disconnect.
The possible IO it was supposed to prevent is long gone.
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/garmin_g
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Also remove bogus test for private data point
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Make sure the interface is not released before our serial device.
Note that drivers are still not allowed to access the interface in
any way that may interfere with another driver that may have gotten
bound to the same interface after disconnect returns.
Cc: stable
Signed-off-by: Johan Hovold
-
On Mon, Mar 18, 2013 at 09:25:34AM -0600, Stephen Warren wrote:
> On 03/18/2013 02:02 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Mar 15, 2013 at 03:12:08PM -0600, Stephen Warren wrote:
> >> On 03/15/2013 03:12 AM, Felipe Balbi wrote:
> >>> PHY layer no longer returns NULL, we must switch from
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
When switching to tty ports, some lifetime as
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable
Signed-off-by: Johan Hovold
---
xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw p
This patch is to bind xhci root hub usb port with its acpi node.
The port num in the acpi table matches with the sequence in the xhci
extended capabilities table. So call usb_hcd_find_raw_port_number() to
transfer hub port num into raw port number which associates with
the sequence in the xhci exte
On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WR
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > > void
> > > intel_i2c_reset(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
Fixing the following sparse warning:
sparse warnings: (new ones prefixed by >>)
>> drivers/usb/phy/phy-samsung-usb2.c:50:26: sparse: incorrect type in argument
>> 1 (different address spaces)
drivers/usb/phy/phy-samsung-usb2.c:50:26:expected void const volatile
[noderef] *addr
drivers
Hi,
On Mon, Mar 18, 2013 at 10:16 PM, Alan Stern wrote:
> On Mon, 18 Mar 2013, Felipe Balbi wrote:
>
>> On Mon, Mar 18, 2013 at 06:06:18PM +0800, Yuan-Hsin Chen wrote:
>> > Hi,
>> >
>> > I tried to modify fusbh200 hcd driver following ehci-platform.c.
>> > However, the register definition of fusb
Hi,
On Tue, Mar 19, 2013 at 09:22:23AM +, Vivek Gautam wrote:
>
>
>
>
>--- Original Message ---
>
>Sender : Felipe Balbi
>
>Date : Mar 19, 2013 13:48 (GMT+05:30)
>
>Title : [PATCH] usb: phy: samsung: fix sparse warning
>
>
>
>Fix the following
Hi,
This is patch version 2. Besides review I hope to get some feed-back on what
the preferred solution is.
Background:
When going through our patches to be mainlined I stumbled on this one which
we have fixed in many different ways internally.
The problem is a NULL pointer dereference that can
From: Truls Bengtsson
The udc_irq service runs the isr_tr_complete_handler which in turn
"nukes" the endpoints, including a call to rndis_response_complete,
if appropriate. If the rndis_msg_parser fails here, an error will
be printed using a dev_err call (through the ERROR() macro).
However, if
On Tue, Mar 19, 2013 at 09:34:54AM +0800, Peter Chen wrote:
> On Mon, Mar 18, 2013 at 03:28:26PM +0100, Michael Grzeschik wrote:
> > On Fri, Mar 08, 2013 at 05:54:37PM +0200, Alexander Shishkin wrote:
> > > Michael Grzeschik writes:
> > >
> > > > A static count of transfer descriptors was used ev
On 08.03.2013 17:44, Daniel Mack wrote:
> On 07.03.2013 13:51, Daniel Mack wrote:
>> On 04.03.2013 00:53, Daniel Mack wrote:
>>> Hi Peter,
>>>
>>> On 03.03.2013 23:24, Peter Korsgaard wrote:
> "Daniel" == Daniel Mack writes:
Hi,
Daniel> On my board, the USB is purely u
On Tue, Mar 19 2013, oskar.and...@sonymobile.com wrote:
> The udc_irq service runs the isr_tr_complete_handler which in turn
> "nukes" the endpoints, including a call to rndis_response_complete,
> if appropriate. If the rndis_msg_parser fails here, an error will
> be printed using a dev_err call (t
> "Daniel" == Daniel Mack writes:
Hi,
>> I know this patch reintroduces bits that have been intentionally
>> removed before, in particular by 032ec49f53 ("usb: musb: drop
>> useless board_mode usage"), but I don't know how this usb driver is
>> supposed to work in host mode without takin
While going over the suggested changes for the ehci-mv separation patch,
we noticed that the driver uses a variable number of clock names it gets
passed from the platform code, which is highly unusual behavior and adds
a lot of extra complexity.
Even though there is a comment in the mv_udc driver
Register a device tree clock provider for AUX clocks
on the OMAP4 SoC. Also provide the binding information.
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/clock/omap4-clock.txt | 32 ++
arch/arm/boot/dts/omap4.dtsi |5 +++
arch/arm/mach
The USB PHY needs AUXCLK3 to operate. Provide this information
in the device tree.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda.dts |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
i
On 03/19/2013 04:26 PM, Roger Quadros wrote:
> Hi,
>
> Based on the discussion in [1], I've implemented device tree
> provider for the AUXCLKs on OMAP4.
[1] - https://lkml.org/lkml/2013/3/12/241
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
Hi,
Based on the discussion in [1], I've implemented device tree
provider for the AUXCLKs on OMAP4.
Please let me know if there are any issues.
This is important to get USB Host support working on Panda with
device tree boot on 3.10.
Roger Quadros (2):
ARM: OMAP4: clock: Add device tree suppo
On 03/19/2013 04:26 PM, Roger Quadros wrote:
> Register a device tree clock provider for AUX clocks
> on the OMAP4 SoC. Also provide the binding information.
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/clock/omap4-clock.txt | 32 ++
> arch/arm/boot/dts
On Mon, 18 Mar 2013, Greg KH wrote:
> On Mon, Mar 18, 2013 at 12:05:54PM -0400, Alan Stern wrote:
> > This patch (as1638) makes several changes to the ehci-hcd driver, all
> > related to the qh_refresh() function. This function must be called
> > whenever an idle QH gets linked back into either t
Hi,
On Tue, Mar 19, 2013 at 02:44:46PM +0100, Arnd Bergmann wrote:
> While going over the suggested changes for the ehci-mv separation patch,
> we noticed that the driver uses a variable number of clock names it gets
> passed from the platform code, which is highly unusual behavior and adds
> a lo
On 3/18/2013 1:35 PM, Greg KH wrote:
On Mon, Mar 18, 2013 at 01:30:47PM -0700, Waskiewicz Jr, Peter P wrote:
I have an Atom-based machine (N450) with an ICH8 running Ubuntu LTS
12.04.2. This has the latest updates installed, kernel 3.5.0-23.35.
I put the machine into S3, then woke it from the n
On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote:
> On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote:
> > > Why can't you just revert this in userspace? Isn't that easier than
> > > doing a kernel patch and providing an option that we need to now
> > > maintain for pretty much forever?
On Tue, Mar 19, 2013 at 7:56 AM, Alan Stern wrote:
>
> On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote:
>
> > On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote:
> > > > Why can't you just revert this in userspace? Isn't that easier than
> > > > doing a kernel patch and providing an opti
On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson wrote:
>> > How about just using:
>> > if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
>> > and the existing wait loop?
>>
>> I explicitly wanted to avoid touching GMBUS4 register, as the real cause
>> of the failure is not clear.
>>
>> But, a
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> For reference below the updated commit message.
>
> Cheers, Daniel
>
> Author: Jiri Kosina
> Date: Tue Mar 19 09:56:57 2013 +0100
>
> drm/i915: stop using GMBUS IRQs on Gen4 chips
>
> Commit 28c70f162 ("drm/i915: use the gmbus irq for wai
On Tue, 19 Mar 2013, Vincent Palatin wrote:
> > The races mentioned above don't seem to be very dangerous. How likely
> > is it that the system will be suspended within a few milliseconds of
> > probing a new USB device?
>
> For laptops, if the suspend/resume is triggered by the lid open/close
>
On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote:
> > What about the port_status registers? They're not between command and
> > async_next. If they aren't consistent with EHCI, it makes things a lot
> > more complicated.
>
> fusbh200 has only one port_status register with different offset,
> 0x30, and
On Tue, 19 Mar 2013, Noone Nowhere wrote:
> > That depends on where the bug is. If it is in the stick then testing
> > a different brand of flash drive would help.
>
> Does it need an unusual dev entry to limit max sectors? It is the
> first USB stick that arrived here back in 2003(?) and uses S
On Mon, 18 Mar 2013, Bruce Guenter wrote:
> On Mon, Mar 11, 2013 at 02:48:50PM -0400, Alan Stern wrote:
> > Okay; if it happens again, collect the information and we'll go on from
> > there.
>
> Well, it's happened again, but it's obviously not a boot issue.
> Something happens after boot that i
Felipe,
I see the following Kconfig warnings in next-20130319:
> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI which has
> unmet direct dependencies (USB_SUPPORT && USB_PHY && ARM)
> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SO
This message is a repost. I did not include the complete original message
in my initial reply, and I am doing so now.
> On Mon, 11 Mar 2013, Frank Peters wrote:
>
> > When I boot my x64 Linux system to the console a continuous series
> > of "USB disconnect/reconnect" messages appears in the kern
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
>> drm/i915: stop using GMBUS IRQs on Gen4 chips
>>
> Yes, okay, that's true. If a new USB device is plugged in while the
> lid is shut, and then the lid is opened very briefly, it's possible
> that the system could suspend again before the new device's "persist"
> attribute is updated. Does that case really matter? The device isn't
> likely to b
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> > That might be misleading. It's possible that the erroneous IRQs _are_
> > being issued but you're simply not aware of them. If the kernel thinks
> > that no device is using IRQ 16 then it will leave that IRQ disabled.
>
> I guess I should have phras
On Mon, 18 Mar 2013, Stephen Warren wrote:
> Alan,
>
> In v3.9-rc3, I find that "reboot" and "shutdown" hang on Tegra. I
> bisected it to commit 6402c79 "USB: EHCI: work around silicon bug in
> Intel's EHCI controllers", and confirmed that running v3.9-rc3 with just
> that one patch reverted does
On Tue, Mar 19, 2013 at 09:45:38AM +0800, Peter Chen wrote:
> On Mon, Mar 18, 2013 at 08:48:15AM -0700, Sarah Sharp wrote:
> > You moved the check for out-of-range port_id further down in the code,
> > and it really needs to be before the line above. Otherwise the host
> > could give us a garbage
Hi Felipe,
* Roger Quadros [130315 08:20]:
> Hi Tony,
>
> These patches provide the SoC side code required to support
> the changes in the OMAP USB Host drivers done in [1], [2] & [3].
>
> Device tree support is added for Beagleboard and Panda.
>
> NOTE: The first patch needs to be shared betw
On 03/19/2013 12:34 PM, Alan Stern wrote:
> On Mon, 18 Mar 2013, Stephen Warren wrote:
>
>> Alan,
>>
>> In v3.9-rc3, I find that "reboot" and "shutdown" hang on Tegra. I
>> bisected it to commit 6402c79 "USB: EHCI: work around silicon bug in
>> Intel's EHCI controllers", and confirmed that running
On Mon, 18 Mar 2013, Greg KH wrote:
> This patch fails to apply to my usb-next branch, after the 4 previous
> patches were applied:
>
> checking file drivers/usb/host/ehci-q.c
> Hunk #2 FAILED at 123.
> Hunk #3 succeeded at 545 (offset -8 lines).
> Hunk #4 succeeded at 557
Ok, this looks sane, and our Intel testers report it doesn't oops like
v2. The patch description on the first patch is better as well.
Tianyu, I know this introduces a new API to the host controller driver
structure, and we would normally queue these two patches for 3.10.
However, I know a lot o
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disabled
On Thu, Mar 07, 2013 at 03:38:46PM +0530, Vivek Gautam wrote:
> Hi Sarah,
>
>
> While going through the code for Handling Transfer Events
> (drivers/usb/host/xhci-ring.c), i hit upon this problem.
> As defined in "drivers/usb/host/xhci.h"
>
> /* Normal TRB fields */
> /* transfer
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> Check return values from all GPIO APIs and handle errors accordingly.
> Remove clk_disable_unprepare which is no more needed.
Patches 6 and 7 each fail checkpatch with "WARNING: line over 80
characters".
--
To unsubscribe from this list: send the li
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> As part of this series, apart from patch containing changes to register TEGRA
> USB PHY driver as platform driver, prepared below patches:
> 1. Re-arranging & adding new DT properties.
> 2. Getting various params from DT properties added.
> 3. code c
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> This patch updates all Tegra board files so that they contain all the
> properties required by the updated USB DT binding. Note that this patch
> only adds the new properties and does not yet remove the old properties,
> in order to maintain bisectab
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> Added a new PHY mode to support OTG.
> Obtained Tegra USB PHY mode using DT property.
> diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
> @@ -713,6 +712,16 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device
>
On Tue, Mar 19, 2013 at 10:58:26AM +0100, humanshu bhatia wrote:
> Hello Sebastian,
Hi humanshu,
> I have compiled linux-2.6.38.6.tar.bz2 on fedora 15.
>
> make menuconfig (Selecting PLX support and gadget zero option )
> make rpm
>
> But after including latest PLX_USB338x_Linux_Driver_v_1_3_1:
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> As GPIO information is avail through DT, used it to get Tegra ULPI
> reset GPIO number. Added a new member to tegra_usb_phy structure to
> store this number.
> diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
> - g
On Tue, 19 Mar 2013, Stephen Warren wrote:
> Yes, sysrq seems to work over the serial console:-)
>
> > * Will now restart
> >
> > *** break sent ***
> > [ 180.765213] SysRq : Show Blocked State
> > [ 180.768963] taskPC stack pid father
> > [ 180.774182] khubd D
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> Check return values from all GPIO APIs and handle errors accordingly.
> Remove clk_disable_unprepare which is no more needed.
The call to clk_disable_unprepare is incorrect in the current code. The
way you worded that, it sounds like it's no longer
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> Registered tegra USB PHY as a separate platform driver.
>
> To synchronize host controller and PHY initialization, used deferred
> probe mechanism. As PHY should be initialized before EHCI starts running,
> deferred probe of Tegra EHCI driver till P
On 3/18/2013 1:35 PM, Greg KH wrote:
On Mon, Mar 18, 2013 at 01:30:47PM -0700, Waskiewicz Jr, Peter P wrote:
I have an Atom-based machine (N450) with an ICH8 running Ubuntu LTS
12.04.2. This has the latest updates installed, kernel 3.5.0-23.35.
I put the machine into S3, then woke it from the n
On Fri, Mar 08, 2013 at 09:15:07PM -0500, Alan Stern wrote:
> On Fri, 8 Mar 2013, Sarah Sharp wrote:
>
> > On Fri, Mar 08, 2013 at 11:14:38AM -0500, Alan Stern wrote:
> > > On Thu, 7 Mar 2013, Sarah Sharp wrote:
> > > You might want to go farther than this. I haven't read the driver code
> > > e
On 03/19/2013 02:07 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Stephen Warren wrote:
>
>> Yes, sysrq seems to work over the serial console:-)
>>
>>> * Will now restart
>>>
>>> *** break sent ***
>>> [ 180.765213] SysRq : Show Blocked State
>>> [ 180.768963] taskPC stack pi
On 03/19/2013 04:48 PM, Stephen Warren wrote:
> On 03/19/2013 02:07 PM, Alan Stern wrote:
...
>> A dmesg log with CONFIG_USB_DEBUG enabled would be helpful. We ought
>> to be able to tell where khubd is getting stuck.
>
> Hmmm. Enabling CONFIG_USB_DEBUG appears to mask the problem. I assume
> thi
The named commit (6402c796d3) causes a process to hang indefinitely in
usb_kill_urb(). Reverting it fixes the problem. The bug also prevents
suspend/shutdown/reboot from completing, presumably due to the hanging
process.
(Cc'ing Stephen Warren because I only found his report after I bisected
it my
On Tue, Mar 19, 2013 at 01:02:59PM +0100, Michael Grzeschik wrote:
> On Tue, Mar 19, 2013 at 09:34:54AM +0800, Peter Chen wrote:
> > On Mon, Mar 18, 2013 at 03:28:26PM +0100, Michael Grzeschik wrote:
> > > On Fri, Mar 08, 2013 at 05:54:37PM +0200, Alexander Shishkin wrote:
> > > > Michael Grzeschik
On 03/19/2013 06:03 PM, Andreas Bombe wrote:
> The named commit (6402c796d3) causes a process to hang indefinitely in
> usb_kill_urb(). Reverting it fixes the problem. The bug also prevents
> suspend/shutdown/reboot from completing, presumably due to the hanging
> process.
>
> (Cc'ing Stephen Warr
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In
function ‘handle_port_status’:
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580:
warning: ‘hcd’ may be used uninitialized in this function
Signed-off-by: Peter Chen
---
Changes for v1:
- Put
On 2013年03月20日 03:06, Sarah Sharp wrote:
> Ok, this looks sane, and our Intel testers report it doesn't oops like
> v2. The patch description on the first patch is better as well.
>
> Tianyu, I know this introduces a new API to the host controller driver
> structure, and we would normally queue t
Hi,
On Wed, Mar 20, 2013 at 12:51 AM, Sarah Sharp
wrote:
> On Thu, Mar 07, 2013 at 03:38:46PM +0530, Vivek Gautam wrote:
>> Hi Sarah,
>>
>>
>> While going through the code for Handling Transfer Events
>> (drivers/usb/host/xhci-ring.c), i hit upon this problem.
>> As defined in "drivers/usb/host/
From: Fabio Estevam
Use 'unsigned int' for indexes, in order to fix the following build warnings
with W=1 option:
drivers/usb/core/usb.c: In function 'usb_find_alt_setting':
drivers/usb/core/usb.c:89:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
drive
On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote:
>
>> > What about the port_status registers? They're not between command and
>> > async_next. If they aren't consistent with EHCI, it makes things a lot
>> > more complicated.
>>
>> fusbh200 has only
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:22 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger
Due to recent changes to regulator API, all
users which don't check regulator_{en,dis}able()'s
return value will generate compile warnings.
Add such checks to gpio-vbus.
Cc: Mark Brown
Signed-off-by: Felipe Balbi
---
it would've been better to actually return regulator
API's to upper layers, b
90 matches
Mail list logo
