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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=UqeDWQiA7sAS6CuM74B0GS+5HcJD9Bd8FfF7awsdG7Vg@mail.gmail.com>
Date:	Thu, 7 Aug 2014 13:52:33 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>
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

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.

...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.

-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/