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@xxxxxx> wrote: >>>> On Monday 24 October 2016 10:16 PM, ahaslam@xxxxxxxxxxxx wrote: >>>>> From: David Lechner <david@xxxxxxxxxxxxxx> >>>>> >>>>> 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@xxxxxxxxxxxxxx> >>>>> [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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html