On 27/09/16 17:23, Robin Murphy wrote:
On 27/09/16 17:13, Hanjun Guo wrote:
On 09/27/2016 05:07 PM, Sudeep Holla wrote:
[...]
As I mentioned in private, I do get the same error if I drop _CCA in
USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?
Sure, will try with
On 27/09/16 09:55, Sajjan, Vikas C wrote:
Hi Sudeep,
-Original Message-
From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
Sent: Tuesday, September 27, 2016 2:21 PM
To: Vikas Sajjan ; linux-usb@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org
Cc: Sudeep
Hi Vikas,
On 27/09/16 09:14, Vikas Sajjan wrote:
Adding USB mailing list.
On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
wrote:
Hi All,
I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get below
USB EHCI probe error while booting with acpi=force.
Are you using the late
Hi Laurent,
On 20/03/15 14:20, Laurent Pinchart wrote:
Hi Sudeep,
Thank you for the patch.
On Friday 20 March 2015 11:42:17 Sudeep Holla wrote:
Commit a124820de5fd ("usb: isp1760: fix possible deadlock in
isp1760_udc_irq") replaced spin_{un,}lock with
spin_{un,}lock_irq{sa
consistent
returns 'irqsave:flags'.
Locked on: line 1207
Unlocked on: line 1199
This patch fixes the spin unlock in the error path in isp1760_udc_start
thereby removing the smatch warning mentioned above.
Reported-by: Dan Carpenter
Cc: Laurent Pinchart
Cc: Felipe Balbi
Signed-
Hi Filipe,
On 09/03/15 15:49, Felipe Balbi wrote:
On Wed, Mar 04, 2015 at 03:56:12PM +, Sudeep Holla wrote:
On 26/02/15 18:53, Laurent Pinchart wrote:
Hi Sudeep,
Thank you for the patch.
On Thursday 26 February 2015 11:47:57 Sudeep Holla wrote:
As per the SAF1761 data sheet[0], the
On 05/03/15 10:49, Laurent Pinchart wrote:
Hi Sudeep,
Thank you for the patch.
On Wednesday 04 March 2015 17:07:57 Sudeep Holla wrote:
Use spin_{un,}lock_irq{save,restore} in isp1760_udc_{start,stop} to
prevent following potentially deadlock scenario between
isp1760_udc_{start,stop} and
elp us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&udc->lock)->rlock);
lock(&(&udc->lock)->rlock);
*** DEADLOCK ***
1 lock held by in:imklog/2118:
#0: (&f->f_pos_lock){+.+.+.}, at: [] __fdget_pos+0x31/0x34
Signed-off-by:
On 04/03/15 16:11, Laurent Pinchart wrote:
Hi Sudeep,
On Wednesday 04 March 2015 15:56:12 Sudeep Holla wrote:
[...]
Also I don't see any message on the host side. Let me know if there's
something wrong in my config or test commands.
Looks like a driver bug to me, .udc_s
On 26/02/15 18:53, Laurent Pinchart wrote:
Hi Sudeep,
Thank you for the patch.
On Thursday 26 February 2015 11:47:57 Sudeep Holla wrote:
As per the SAF1761 data sheet[0], the DcChipID register represents
the hardware version number (0001h) and the chip ID (1582h) for the
Peripheral
the Peripheral Controller.
This patch adds support for both the chip ID values.
[0] http://www.nxp.com/documents/data_sheet/SAF1761.pdf
[1] http://pdf.datasheetcatalog.com/datasheets2/74/742102_1.pdf
Cc: Felipe Balbi
Cc: Laurent Pinchart
Signed-off-by: Sudeep Holla
---
drivers/usb/isp1760
Hi Laurent,
On 25/02/15 22:27, Laurent Pinchart wrote:
Hi Sudeep,
Thank you for the patch.
On Tuesday 24 February 2015 17:53:42 Sudeep Holla wrote:
As per the ISP1761 data sheet, the DcChipID register represents
the hardware version number (0015h) and the chip ID (8210h) for the
Peripheral
As per the ISP1761 data sheet, the DcChipID register represents
the hardware version number (0015h) and the chip ID (8210h) for the
Peripheral Controller.
This patch fixes the chip ID value used to verify the controller.
Cc: Felipe Balbi
Cc: Laurent Pinchart
Signed-off-by: Sudeep Holla
13 matches
Mail list logo
