[PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

Sekhar Nori nsekhar at ti.com
Wed Oct 26 01:56:07 PDT 2016


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 at ti.com> wrote:
>>>> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
>>>>> From: David Lechner <david at lechnology.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 at lechnology.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



More information about the linux-arm-kernel mailing list