linux-kernel - Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

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:	Wed, 22 Jun 2016 12:07:25 -0500
From:	David Lechner <david@...hnology.com>
To:	Sekhar Nori <nsekhar@...com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	khilman@...nel.org
Cc:	petr@...ix.com, Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Stern <stern@...land.harvard.edu>, Bin Liu <b-liu@...com>,
	Lee Jones <lee.jones@...aro.org>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform
 declaration.

On 05/25/2016 06:15 AM, Sekhar Nori wrote:
> On Tuesday 10 May 2016 10:14 PM, David Lechner wrote:
>> On 05/10/2016 06:26 AM, Sergei Shtylyov wrote:
>>> On 5/10/2016 2:46 AM, David Lechner wrote:
>>>
>>>> The CFGCHIP registers are used by a number of devices, so using a syscon
>>>> device to share them. The first consumer of this will by the
>>>> phy-da8xx-usb
>>>> driver.
>>>>
>>>> Signed-off-by: David Lechner <david@...hnology.com>
>>> [...]
>>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
>>>> b/arch/arm/mach-davinci/devices-da8xx.c
>>>> index 725e693..69d11a1 100644
>>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>>> @@ -11,6 +11,7 @@
>>>>    * (at your option) any later version.
>>>>    */
>>>>   #include <linux/init.h>
>>>> +#include <linux/platform_data/syscon.h>
>>>>   #include <linux/platform_device.h>
>>>>   #include <linux/dma-contiguous.h>
>>>>   #include <linux/serial_8250.h>
>>>> @@ -1109,3 +1110,30 @@ int __init da850_register_sata(unsigned long
>>>> refclkpn)
>>>>       return platform_device_register(&da850_sata_device);
>>>>   }
>>>>   #endif
>>>> +
>>>> +static struct syscon_platform_data da8xx_cfgchip_platform_data = {
>>>> +    .label    = "cfgchip",
>>>> +};
>>>> +
>>>> +static struct resource da8xx_cfgchip_resources[] = {
>>>> +    {
>>>> +        .start    = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP0_REG,
>>>> +        .end    = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP4_REG + 3,
>>>> +        .flags    = IORESOURCE_MEM,
>>>> +    },
>>>> +};
>>>> +
>>>> +static struct platform_device da8xx_cfgchip_device = {
>>>> +    .name    = "syscon",
>>>> +    .id    = 0,
>>>
>>>      Again, -1.
>>>
>>> [...]
>>>
>>> MBR, Sergei
>>>
>>
>> I wish you would have noticed this when I first submitted it. I remember
>> going back and forth about this. But it has been too long and I can't
>> remember the reason why I chose to go this way.
>>
>> It seems like changing it broke something with either this one or the
>> phy device and I opted to keep it this way on both to be consistent. For
>> example, the USB devices both use id = 0 as well even though there are
>> only one of each type.
>
> Agree with Sergei here. Can you confirm what broke exactly? I think the
> USB needs to be fixed too.
>
> Thanks,
> Sekhar
>

I have made the changes from id = 0 to id = -1. I'm not sure what broke 
before, but it is working now.

Re: USB needing fixed, I'm not sure how to do this and I won't have time 
for at least the next 2 or 3 months to do anything about it. The problem 
is that the MUSB can't detect the ID pin. As a workaround, it is
detecting the VBUS state and using that to determine the ID pin state. 
So, when you attach a self-powered device, it tells the VBUS to turn 
off, which in turn triggers the workaround to say that the ID pin has 
changed state.

If anyone has any ideas on what to do about this, I will be glad to have 
a look at it. It will just have to wait a bit though.