From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933776AbcJZI6n (ORCPT ); Wed, 26 Oct 2016 04:58:43 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:33369 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756300AbcJZI5f (ORCPT ); Wed, 26 Oct 2016 04:57:35 -0400 Subject: Re: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration. To: David Lechner , Axel Haslam References: <20161024164634.4330-1-ahaslam@baylibre.com> <20161024164634.4330-3-ahaslam@baylibre.com> <7f9efe9d-0912-e10a-3e45-24c5d2b455ab@ti.com> <758f206c-d0bd-6f70-da1e-42c88d6dd1f0@ti.com> CC: Greg KH , Johan Hovold , , Alan Stern , Kevin Hilman , Sergei Shtylyov , , Mark Brown , Alexandre Bailon , , , , From: Sekhar Nori Message-ID: <236fc069-b24b-ed8a-55c1-e3e7af08a229@ti.com> Date: Wed, 26 Oct 2016 14:26:07 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: >>>> On Monday 24 October 2016 10:16 PM, ahaslam@baylibre.com wrote: >>>>> From: David Lechner >>>>> >>>>> 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 >>>>> [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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sekhar Nori Subject: Re: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration. Date: Wed, 26 Oct 2016 14:26:07 +0530 Message-ID: <236fc069-b24b-ed8a-55c1-e3e7af08a229@ti.com> References: <20161024164634.4330-1-ahaslam@baylibre.com> <20161024164634.4330-3-ahaslam@baylibre.com> <7f9efe9d-0912-e10a-3e45-24c5d2b455ab@ti.com> <758f206c-d0bd-6f70-da1e-42c88d6dd1f0@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: David Lechner , Axel Haslam Cc: devicetree@vger.kernel.org, Sergei Shtylyov , Greg KH , manjunath.goudar@linaro.org, linux-usb@vger.kernel.org, Johan Hovold , linux-kernel@vger.kernel.org, robh+dt@kernel.org, Alan Stern , Mark Brown , Kevin Hilman , linux-arm-kernel@lists.infradead.org, Alexandre Bailon List-Id: devicetree@vger.kernel.org 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 wrote: >>>> On Monday 24 October 2016 10:16 PM, ahaslam@baylibre.com wrote: >>>>> From: David Lechner >>>>> >>>>> 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 >>>>> [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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: nsekhar@ti.com (Sekhar Nori) Date: Wed, 26 Oct 2016 14:26:07 +0530 Subject: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration. In-Reply-To: References: <20161024164634.4330-1-ahaslam@baylibre.com> <20161024164634.4330-3-ahaslam@baylibre.com> <7f9efe9d-0912-e10a-3e45-24c5d2b455ab@ti.com> <758f206c-d0bd-6f70-da1e-42c88d6dd1f0@ti.com> Message-ID: <236fc069-b24b-ed8a-55c1-e3e7af08a229@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 wrote: >>>> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote: >>>>> From: David Lechner >>>>> >>>>> 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 >>>>> [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