[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <236fc069-b24b-ed8a-55c1-e3e7af08a229@ti.com>
Date: Wed, 26 Oct 2016 14:26:07 +0530
From: Sekhar Nori <nsekhar@...com>
To: David Lechner <david@...hnology.com>,
Axel Haslam <ahaslam@...libre.com>
CC: Greg KH <gregkh@...uxfoundation.org>,
Johan Hovold <johan@...nel.org>, <robh+dt@...nel.org>,
Alan Stern <stern@...land.harvard.edu>,
Kevin Hilman <khilman@...libre.com>,
Sergei Shtylyov <sshtylyov@...mvista.com>,
<manjunath.goudar@...aro.org>, Mark Brown <broonie@...nel.org>,
Alexandre Bailon <abailon@...libre.com>,
<linux-usb@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon
platform declaration.
On Tuesday 25 October 2016 09:23 PM, David Lechner wrote:
> Hi Sekhar,
>
> On 10/25/2016 05:17 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 03:07 PM, Axel Haslam wrote:
>>> Hi Sekar,
>>>
>>> On Tue, Oct 25, 2016 at 10:10 AM, Sekhar Nori <nsekhar@...com> wrote:
>>>> On Monday 24 October 2016 10:16 PM, ahaslam@...libre.com wrote:
>>>>> From: David Lechner <david@...hnology.com>
>>>>>
>>>>> 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>
>>>>> [Axel: minor fix: change id to -1]
>>>>
>>>> Can you please clarify this change? There could be other syscon devices
>>>> on the chip for other common registers. Why use the singular device-id?
>>>>
>>>
>>> in the case of non DT boot, the phy driver is looking for "syscon" :
>>>
>>> d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
>>>
>>> if we register the syscon driver with id = 0, the actual name of the
>>> syscon
>>> device will be "syscon.0" and the phy driver will fail to probe, because
>>> the strncmp match in the syscon driver (syscon_match_pdevname)
>>> will fail.
>>>
>>> should i change the phy driver instead?
>>
>> Yes, please. Forcing only one syscon region for the whole chip will be
>> too restrictive, I am pretty sure.
>>
>> Thanks,
>> Sekhar
>>
>
> In the previous review, you requested that this be changed to -1 [1].
>
> If we change it back to 0, it will also require reverting a patch to the
> phy driver that has already been merged[2].
Sigh. Sorry about going around in circles on this one. Lets go with what
you have. If and when there is a need for another syscon node, the
driver and platform code can be updated. At least we will know why the
change is being done at that time.
Thanks,
Sekhar
Powered by blists - more mailing lists