lkml.org 
[lkml]   [2018]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware
On Sat, 9 Jun 2018, Andreas Schwab wrote:

> On Jun 09 2018, Finn Thain <fthain@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.
>
>

\
 
 \ /
  Last update: 2018-06-10 04:12    [W:0.130 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site