2015-10-19 18:56 GMT+09:00 Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx>:
> Hello,
>
> On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
>> On 19.10.2015 15:03, Alim Akhtar wrote:
>>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>>> so we don't need special handling for reboot/poweroff in
>>> exynos pmu driver. This patch remove the same.
>>>
>>> Signed-off-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>
>>> ---
>>> arch/arm/mach-exynos/pmu.c | 43 -------------------------------------------
>>> 1 file changed, 43 deletions(-)
>>
>> I think that removal of this stuff will effectively remove the
>> restart/poweroff handlers from:
>> 1. Other defconfigs, like multi_v7
>> 2. Custom configs.
>>
>
> This will also break old DTBs that don't have a "syscon-poweroff" device
> node that contains the necessary PMU regmap, offset and mask information.
I am not sure whether this is ABI break issue. There was no compatible
mentioning that "reset works" which now would be replaced. The
existing PMU compatible (like samsung,exynos4412-pmu) does not mention
"reset" as a feature coming with this compatible.
So no ABI break.
>
>> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
>> not so I am thinking about selecting necessary drivers from main exynos
>> Kconfig symbol. That could be tricky though, because "select" should be
>> used only for non-visible symbols.
>>
>> Any ideas how to solve that?
>>
>
> Is true that select should only be used for non-visible symbols but there
> are others user visible symbols that are selected by ARCH_EXYNOS such as
> EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
> is a sensible option.
Selecting from defconfig is not sufficient... since I do not have
other idea than selecting then ovak, but Alim please check it whether
it does not create circular dependencies on various configs.
Best regards,
Krzysztof
--
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
