lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 Aug 2014 20:59:43 +0000
From:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>
To:	Doug Anderson <dianders@...omium.org>
CC:	Kever Yang <kever.yang@...k-chips.com>,
	"heiko@...ech.de" <heiko@...ech.de>,
	"olof@...om.net" <olof@...om.net>,
	"sonnyrao@...omium.org" <sonnyrao@...omium.org>,
	"addy.ke@...k-chips.com" <addy.ke@...k-chips.com>,
	"cf@...k-chips.com" <cf@...k-chips.com>,
	"xjq@...k-chips.com" <xjq@...k-chips.com>,
	"wulf@...k-chips.com" <wulf@...k-chips.com>,
	"lyz@...k-chips.com" <lyz@...k-chips.com>,
	"hj@...k-chips.com" <hj@...k-chips.com>,
	"huangtao@...k-chips.com" <huangtao@...k-chips.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 2/4] usb: dwc2: add compatible data for rockchip soc

> From: dianders@...gle.com [mailto:dianders@...gle.com] On Behalf Of Doug Anderson
> Sent: Thursday, August 07, 2014 1:53 PM
> 
> On Thu, Aug 7, 2014 at 11:26 AM, Paul Zimmerman
> <Paul.Zimmerman@...opsys.com> wrote:
> >> From: Kever Yang [mailto:kever.yang@...il.com] On Behalf Of Kever Yang
> >> Sent: Thursday, August 07, 2014 2:35 AM
> >>
> >> This patch add compatible data for dwc2 controller found on
> >> rk3066, rk3188 and rk3288 processors from rockchip.
> >>
> >> Signed-off-by: Kever Yang <kever.yang@...k-chips.com>
> >> Acked-by: Paul Zimmerman <paulz@...opsys.com>
> >> ---
> >>
> >> Changes in v4:
> >> - max_transfer_size change to 65536, this should be enough
> >>   for most transfer, the hardware auto-detect will set this
> >>   to 0x7ffff which may make dma_alloc_coherent fail when
> >>   non-dword aligned buf from driver like usbnet happen.
> >
> > Hi Kever,
> >
> > Did you test this change thoroughly? I have vague memories of any
> > value above 65535 causing problems, at least on my hardware. And I
> > see it is set to 65535 in both pci.c and platform.c. I could be
> > wrong, but I thought I should mention it.
> 
> Certainly it is documented in the header file to have a max of 65535:
> 
>  * @max_transfer_size:  The maximum transfer size supported, in bytes
>  *                       2047 to 65,535
>  *                      Actual maximum value is autodetected and also
>  *                      the default.
> 
> ...but looking at the register definition that I see, the size can be
> up to 19 bits.  A 19-bit transfer far exceeds 65535.  Do you remember
> what the error was?  Certainly I can imagine there being errors with
> large calls to dma_alloc_coherent()...

It's pretty fuzzy. I think a certain type of transfer (Isoc?) didn't
work. But I may be misremembering, the problem could have been with
max_packet_count > 255 instead. If you have tested it thoroughly with
different types of devices then it's probably OK.

-- 
Paul

Powered by blists - more mailing lists