On Sat, 9 Jun 2018, Andreas Schwab wrote:
On Jun 09 2018, Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote:
There is no ABI issue AFAIK. The value of pmu_kind is visible to userland
only on powerpc. /dev/pmu and /proc/pmu/* do not exist on m68k.
Then why are PMU_68K_V1 and PMU_68K_V2 defined in the first place?
I think your question is academic. Mistakes were made, and dead code
appears in the kernel headers.
The author of via-pmu68k.c (apparently Joshua M. Thompson) may have a
better answer, but if you want my guess, it is simply that pmu_kind was
cut and pasted from via-pmu.c, and then given values corresponding to
internal kernel system controller type values. See via-pmu68k.c:
case MAC_ADB_PB1:
pmu_kind = PMU_68K_V1;
break;
case MAC_ADB_PB2:
pmu_kind = PMU_68K_V2;
break;
Note that the MAC_ADB_PB1 and MAC_ADB_PB2 categories are quite artificial
and were never useful to userland and were never visible to userland. The
same applies to PMU_68K_V1 and PMU_68K_V2.
The MAC_ADB_PB1 and MAC_ADB_PB2 categories are used internally by the
kernel to distinguish the M50753 devices which have no built-in RTC
(MAC_ADB_PB1) from the M68HC05 devices which do have a built-in RTC
(MAC_ADB_PB2). This distinction is completely hidden by the kernel behind
the RTC UAPIs. It is not useful to userland.
With this patch series, MAC_ADB_PB1/PMU_68K_V1 models will have no PMU
driver loaded at all, while MAC_ADB_PB2/PMU_68K_V2 models will have
pmu_kind set to PMU_UNKNOWN, and this will become visible to userland for
the first time.
Can please you explain why this change is problematic? You seem to be
worried about breaking code which doesn't exist, and which, if it did
exist, is already broken for other reasons.
--
Andreas.
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
