[PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

[Finn Thain]

On Sat, 9 Jun 2018, Andreas Schwab wrote:

> On Jun 09 2018, Finn Thain <fthain at telegraphics.com.au> 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.
> 
>