> >>> I'm very worried about adding a DT that's known broken, especially when
> >>> we have no idea as to if/when the FW will be fixed judging from prior
> >>> replies.
> >>
> >> As I replied, I can not fix the FW because I don't have any code of FW.
> >
> > Surely you are able to contact those who do?
> >
> >> I don't have any solution to fix it on Linux kernel level.
> >>
> >> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
> >
> > I disagree. I do not want to add a DT that is known to be broken;
> > especially when we have no idea how to fix it. It creates long-term
> > maintenance pain for everyone, and marginal gain for few. A comment does
> > nothing to aid the end-user.
> >
> > So NAK to the PSCI node and PSCI enable method in this dts until we
> > either have a working firmware, or a reasonable mechanism to handle the
> > deficiency.
>
> There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
> To fix this issue, we must need the help of firmware developer.
> But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
> Also, as I mentioned on previous mail, all Exynos SoCs can not turn
> off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.
Is there a particular reason that CPU0 cannot be hotplugged?
In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.
Thanks,
Mark.
--
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
