Hi,
On 8/28/2023 3:48 PM, Dmitry Baryshkov wrote:
On Mon, 28 Aug 2023 at 13:04, Marc Zyngier <maz@xxxxxxxxxx> wrote:
On Mon, 28 Aug 2023 10:46:10 +0100,
Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote:
On Mon, 28 Aug 2023 at 12:36, Maulik Shah (mkshah)
<quic_mkshah@xxxxxxxxxxx> wrote:
Hi Dmitry,
This patch may be useful if there was a case where some PDCs don't have
version register populated/available,
In all PDC versions, version register is always available but due to reg
size not good enough in device tree for SM8150 it failed to read.
reg size in device node must be expanded if its too small to access all
registers and i think
additional check in driver to check if size is good enough would not be
of much use.
Unfortunately, it doesn't work this way. DT files are ABI. Even if we
change the DT, the kernel should continue working with the older
version.
Thus, we have to add such bandaid code, which will keep the kernel
from crashing if old DT was used.
You're missing the point: all existing PDC HW have version register.
The fact that the DT is crap doesn't invalidate this simple fact. It
is thus perfectly possible for the driver to *ignore* the crap and do
the right thing by expanding the size of the mapping, rather than
falling back to the non-versioned code.
Ah. Interesting idea. If that's the overall consensus I can send v2
doing this. Not sure what is better though.
if expanding register size and reading version register looks too hacky
the other way is to have "qcom,pdc-v3.2" compatible for newer targets
post which don't need to read version register to figure out as the
compatible string is enough to tell if v3.2 HW behavior needs to apply.
I am ok with either approach but biased towards using version register
rather than compatibles.
Thanks,
Maulik
There is definitely precedents for this sort of behaviour, such as the
ARM GICv2 probe code.
