linux-kernel - Re: [PATCH v4 2/4] usb: dwc2: add compatible data for rockchip soc

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 08 Aug 2014 09:42:54 +0800
From:	"Kever.Yang" <kever.yang@...k-chips.com>
To:	Doug Anderson <dianders@...omium.org>,
	Paul Zimmerman <Paul.Zimmerman@...opsys.com>
CC:	"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


On 08/08/2014 04:52 AM, Doug Anderson wrote:
> Paul,
>
> 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.
Sorry for didn't check the header file, I'll change it to 65535 and 
resubmit.
>
> ...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()...
>
> I know that with Kever's change I can do USB Ethernet downloads, so it
> is at least working to some degree.  ...to me it feels like Kever
> should resubmit with 65535 (to match the documentation) and then work
> in the background to figure out what the max_transfer_size really
> ought to be.
You are right.
> -Doug
>
>
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/