[GIT PULL] ARM: SOC PM domain for 4.12

From: d-gerlach@ti•com (Dave Gerlach)
To: linux-arm-kernel@lists•infradead.org
Subject: [GIT PULL] ARM: SOC PM domain for 4.12
Date: Wed, 19 Apr 2017 20:44:09 -0500	[thread overview]
Message-ID: <58F81269.70207@ti.com> (raw)
In-Reply-To: <0358ac18-8d7a-84a6-356f-8c9e8840bc4d@oracle.com>

Arnd,
On 04/19/2017 05:54 PM, santosh.shilimkar at oracle.com wrote:
> +Dave,
> 
> On 4/19/17 12:56 PM, Arnd Bergmann wrote:
>> On Thu, Apr 6, 2017 at 7:42 PM, Santosh Shilimkar <ssantosh@kernel•org> wrote:
>>> Hi Arnd, Olof,
>>>
>>> As inidcated on the list, because of various dependencies, am senidng
>>> Dave Gerlach's full patchset in single pull request.
>>>
>>> The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
>>>
>>>   Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
>>> tags/arm-soc-pmdomain
>>>
>>> for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:
>>>
>>>   ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)
>>>
>>> ----------------------------------------------------------------
>>> ARM SOC PM domain support for 4.12
>>>
>>> Dave Gerlach (5):
>>>       PM / Domains: Add generic data pointer to genpd data struct
>>>       PM / Domains: Do not check if simple providers have phandle cells
>>>       dt-bindings: Add TI SCI PM Domains
>>>       soc: ti: Add ti_sci_pm_domains driver
>>>       ARM: keystone: Drop PM domain support for k2g
>>
>> I went through the list of arm at kernel.org emails that had not seen a reply after
>> Olof's pull marathon today. I did not get a reply for this one, but I
>> see that Olof
>> has merged it into next/drivers.
>>
> Thanks.
> 
>> Since I was looking at it, I also took a closer look at the contents of the
>> patch series. The driver itself looks fine, but for the record, I'm not that
>> happy about seeing a header file duplicating the information from the
>> data sheet: We only use dt-binding headers to establish an interface between
>> the driver and the sources when there is well-defined fixed way to enumerate
>> resources, but in this case there clearly is...
>>

I apologize but I'm not clear on exactly what your concern is? Currently we
define a device ID which is associated to a "device" in the firmware's view of
the world, however the firmware has no knowledge of what goes on in the kernel
and vice-versa. The device ID is associated to that device only on that
hardware, it could be a different ID on a different SoC making use of SCI. The
only way a device is identified to the firmware is through this number, it will
also be used by the ti-sci-clock [1] and ti-sci-reset [2] drivers to identify
the device.

I'm not sure what you mean by "We only use dt-binding headers to establish an
interface between the driver and the sources when there is well-defined fixed
way to enumerate resources."

Regards,
Dave

[1] https://www.spinics.net/lists/arm-kernel/msg537665.html
[2] https://www.spinics.net/lists/devicetree/msg151643.html

> Dave, please care to follow up Arnd's concerns on those defines.
> 
> Regards,
> Santosh
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel