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]
Date:	Thu, 26 May 2016 15:22:23 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Peter Chen <Peter.Chen@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Jon Hunter <jonathanh@...dia.com>, linux-usb@...r.kernel.org,
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 03:17 PM, Stephen Warren wrote:
> On 05/26/2016 09:40 AM, Thierry Reding wrote:
>> From: Thierry Reding <treding@...dia.com>
>>
>> All of these Tegra SoC generations have a ChipIdea UDC IP block that can
>> be used for device mode communication with a host. Implement rudimentary
>> support that doesn't allow switching between host and device modes.
>
> Are you sure this is correct for Tegra20? I ask because for the /host/
> mode driver, there's a "has_hostpc" flag which is set to false for
> Tegra20 and true for all other SoCs. In the U-Boot device mode driver
> (if not in the kernel driver; I didn't check), there's a concept of "has
> hostpc" too. I might expect that flag to be set the same way for both
> drivers. That said, I /think/ the host and device HW are unrelated, so
> it's possible has_hostpc might be set differently for them.
> Unfortunately, we haven't enabled the device mode driver for any Tegra20
> system in U-Boot so I can't tell whether we should enable has_hostpc for
> Tegra20's device mode driver.
>
> Still, if this code works then I guess it's likely correct...

On the other hand, it looks like the kernel device mode driver might 
auto-detect this; in core.c:hw_device_init(), I see:

         reg = hw_read(ci, CAP_HCCPARAMS, HCCPARAMS_LEN) >>
                 __ffs(HCCPARAMS_LEN);
         ci->hw_bank.lpm  = reg;

... and in host.c:host_start(), I see:

	ehci->has_hostpc = ci->hw_bank.lpm;

Powered by blists - more mailing lists