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

Message ID d9d626ca4e7ac9c7e81b24a34f5fbcae9d1d5046.1528423341.git.fthain@telegraphics.com.au
State Superseded
Headers show
Series
  • macintosh: Resolve various PMU driver problems
Related show

Commit Message

Finn Thain June 8, 2018, 2:24 a.m.
Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU
device found in those models was never supported by this driver.
Attempting to load the driver usually causes a boot hang.

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
 arch/m68k/mac/misc.c           | 6 ++----
 drivers/macintosh/via-pmu68k.c | 4 ----
 include/uapi/linux/pmu.h       | 1 -
 3 files changed, 2 insertions(+), 9 deletions(-)

Comments

Michael Schmitz June 9, 2018, 6:42 a.m. | #1
Hi Finn,

Am 08.06.2018 um 14:24 schrieb Finn Thain:
> Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU
> device found in those models was never supported by this driver.
> Attempting to load the driver usually causes a boot hang.
>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> ---
>  arch/m68k/mac/misc.c           | 6 ++----
>  drivers/macintosh/via-pmu68k.c | 4 ----
>  include/uapi/linux/pmu.h       | 1 -
>  3 files changed, 2 insertions(+), 9 deletions(-)
...
> diff --git a/include/uapi/linux/pmu.h b/include/uapi/linux/pmu.h
> index 89cb1acea93a..30f64d46f5db 100644
> --- a/include/uapi/linux/pmu.h
> +++ b/include/uapi/linux/pmu.h
> @@ -93,7 +93,6 @@ enum {
>  	PMU_HEATHROW_BASED,	/* PowerBook G3 series */
>  	PMU_PADDINGTON_BASED,	/* 1999 PowerBook G3 */
>  	PMU_KEYLARGO_BASED,	/* Core99 motherboard (PMU99) */
> -	PMU_68K_V1,		/* 68K PMU, version 1 */
>  	PMU_68K_V2, 		/* 68K PMU, version 2 */
>  };

Is this enum used by any user space code? If so, perhaps rather leave 
the PMU_68K_V1 in there to avoid upsetting that?

Otherwise,

Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>

Cheers,

	Michael
Andreas Schwab June 9, 2018, 7:14 a.m. | #2
On Jun 09 2018, Michael Schmitz <schmitzmic@gmail.com> wrote:

> Hi Finn,
>
> Am 08.06.2018 um 14:24 schrieb Finn Thain:
>> Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU
>> device found in those models was never supported by this driver.
>> Attempting to load the driver usually causes a boot hang.
>>
>> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>> ---
>>  arch/m68k/mac/misc.c           | 6 ++----
>>  drivers/macintosh/via-pmu68k.c | 4 ----
>>  include/uapi/linux/pmu.h       | 1 -
>>  3 files changed, 2 insertions(+), 9 deletions(-)
> ...
>> diff --git a/include/uapi/linux/pmu.h b/include/uapi/linux/pmu.h
>> index 89cb1acea93a..30f64d46f5db 100644
>> --- a/include/uapi/linux/pmu.h
>> +++ b/include/uapi/linux/pmu.h
>> @@ -93,7 +93,6 @@ enum {
>>  	PMU_HEATHROW_BASED,	/* PowerBook G3 series */
>>  	PMU_PADDINGTON_BASED,	/* 1999 PowerBook G3 */
>>  	PMU_KEYLARGO_BASED,	/* Core99 motherboard (PMU99) */
>> -	PMU_68K_V1,		/* 68K PMU, version 1 */
>>  	PMU_68K_V2, 		/* 68K PMU, version 2 */
>>  };
>
> Is this enum used by any user space code? If so, perhaps rather leave the
> PMU_68K_V1 in there to avoid upsetting that?

It also changes the value of PMU_68K_V2, which is an ABI break.

Andreas.
Michael Schmitz June 9, 2018, 7:55 a.m. | #3
Hi Andreas,

Am 09.06.2018 um 19:14 schrieb Andreas Schwab:
> On Jun 09 2018, Michael Schmitz <schmitzmic@gmail.com> wrote:
>
>> Hi Finn,
>>
>> Am 08.06.2018 um 14:24 schrieb Finn Thain:
>>> Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU
>>> device found in those models was never supported by this driver.
>>> Attempting to load the driver usually causes a boot hang.
>>>
>>> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>>> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>>> ---
>>>  arch/m68k/mac/misc.c           | 6 ++----
>>>  drivers/macintosh/via-pmu68k.c | 4 ----
>>>  include/uapi/linux/pmu.h       | 1 -
>>>  3 files changed, 2 insertions(+), 9 deletions(-)
>> ...
>>> diff --git a/include/uapi/linux/pmu.h b/include/uapi/linux/pmu.h
>>> index 89cb1acea93a..30f64d46f5db 100644
>>> --- a/include/uapi/linux/pmu.h
>>> +++ b/include/uapi/linux/pmu.h
>>> @@ -93,7 +93,6 @@ enum {
>>>  	PMU_HEATHROW_BASED,	/* PowerBook G3 series */
>>>  	PMU_PADDINGTON_BASED,	/* 1999 PowerBook G3 */
>>>  	PMU_KEYLARGO_BASED,	/* Core99 motherboard (PMU99) */
>>> -	PMU_68K_V1,		/* 68K PMU, version 1 */
>>>  	PMU_68K_V2, 		/* 68K PMU, version 2 */
>>>  };
>>
>> Is this enum used by any user space code? If so, perhaps rather leave the
>> PMU_68K_V1 in there to avoid upsetting that?
>
> It also changes the value of PMU_68K_V2, which is an ABI break.

Yes, that's what I worry about - but do we know of any users of that 
particular interface?

Cheers,

	Michael

>
> Andreas.
>
Finn Thain June 9, 2018, 12:21 p.m. | #4
> > > Is this enum used by any user space code? If so, perhaps rather 
> > > leave the PMU_68K_V1 in there to avoid upsetting that?
> > 
> > It also changes the value of PMU_68K_V2, which is an ABI break.
> 
> Yes, that's what I worry about - but do we know of any users of that 
> particular interface?

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. This patch 
series will make these UAPIs available on m68k, and for that reason I've 
chosen the value PMU_UNKNOWN for pmu_kind.

New pmu_kind values can be defined as and when the need arises. But that 
would imply a useful classification scheme for pre-PCI powerbooks, and I 
don't know what that scheme will look like because at this stage there is 
neither userland nor kernel code to support backlight, buttons and battery 
for pre-PCI powerbooks.

In anycase, the "v1" and "v2" scheme is obviously inadequate when you 
consider the range of m68k powerbook models. Also, consider the 
out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has 
this ABI break:

diff --git a/include/linux/pmu.h b/include/linux/pmu.h
index cafe98d9694..9882a185a52 100644
--- a/include/linux/pmu.h
+++ b/include/linux/pmu.h
@@ -90,6 +90,7 @@ enum {
         PMU_HEATHROW_BASED,     /* PowerBook G3 series */
         PMU_PADDINGTON_BASED,   /* 1999 PowerBook G3 */
         PMU_KEYLARGO_BASED,     /* Core99 motherboard (PMU99) */
+        PMU_NUBUS_BASED,        /* 1400, 2300, 5300 */
         PMU_68K_V1,             /* 68K PMU, version 1 */
         PMU_68K_V2,             /* 68K PMU, version 2 */
 };

(BTW, these powerbooks are not "nubus based", they are "pre-PCI", so I 
wouldn't want this to go upstream in this form. It could be that 
PMU_NUBUS_BASED should be PMU_UNKNOWN too.)

--
Andreas Schwab June 9, 2018, 1:24 p.m. | #5
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?

Andreas.
Finn Thain June 10, 2018, 2:11 a.m. | #6
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.
Benjamin Herrenschmidt June 10, 2018, 6:55 a.m. | #7
On Sat, 2018-06-09 at 22:21 +1000, Finn Thain wrote:
> In anycase, the "v1" and "v2" scheme is obviously inadequate when you 
> consider the range of m68k powerbook models. Also, consider the 
> out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has 
> this ABI break:
> 
> diff --git a/include/linux/pmu.h b/include/linux/pmu.h
> index cafe98d9694..9882a185a52 100644
> --- a/include/linux/pmu.h
> +++ b/include/linux/pmu.h
> @@ -90,6 +90,7 @@ enum {
>          PMU_HEATHROW_BASED,     /* PowerBook G3 series */
>          PMU_PADDINGTON_BASED,   /* 1999 PowerBook G3 */
>          PMU_KEYLARGO_BASED,     /* Core99 motherboard (PMU99) */
> +        PMU_NUBUS_BASED,        /* 1400, 2300, 5300 */
>          PMU_68K_V1,             /* 68K PMU, version 1 */
>          PMU_68K_V2,             /* 68K PMU, version 2 */
>  };
> 
> (BTW, these powerbooks are not "nubus based", they are "pre-PCI", so I 
> wouldn't want this to go upstream in this form. It could be that 
> PMU_NUBUS_BASED should be PMU_UNKNOWN too.)

Pre-PCI is basically "NUBUS" based even in absence of an actual NuBus
slot :-) It has to do with the internal HW architecture. The only ones
that aren't are the even older designs (the 68000 based ones).

What's the situation with those NuBus things ? What do they use as a
bootloader ? The old Apple one or BootX ? We should merge that port of
it's maintained.

Cheers,
Ben.
Geert Uytterhoeven June 10, 2018, 8:29 a.m. | #8
Hi Finn,

On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > > Is this enum used by any user space code? If so, perhaps rather
> > > > leave the PMU_68K_V1 in there to avoid upsetting that?
> > >
> > > It also changes the value of PMU_68K_V2, which is an ABI break.
> >
> > Yes, that's what I worry about - but do we know of any users of that
> > particular interface?
>
> 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. This patch
> series will make these UAPIs available on m68k, and for that reason I've
> chosen the value PMU_UNKNOWN for pmu_kind.

While /dev/pmu and /proc/pmu/* may not exist on m68k, definitions in
include/uapi/linux/pmu.h are part of the ABI, and cannot be changed or removed,
unless we are 100% sure there are no users.

If I would write a program interfacing with /dev/pmu and /proc/pmu/*, and
needing to check the PMU type, it would have a switch() statement with
all existing values defined in <linux/pmu.h>. So that would become broken
by your change.

Hence the enum is append-only.

> New pmu_kind values can be defined as and when the need arises. But that
> would imply a useful classification scheme for pre-PCI powerbooks, and I
> don't know what that scheme will look like because at this stage there is
> neither userland nor kernel code to support backlight, buttons and battery
> for pre-PCI powerbooks.
>
> In anycase, the "v1" and "v2" scheme is obviously inadequate when you
> consider the range of m68k powerbook models. Also, consider the

New values can be added at the bottom.

> out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has
> this ABI break:
>
> diff --git a/include/linux/pmu.h b/include/linux/pmu.h
> index cafe98d9694..9882a185a52 100644
> --- a/include/linux/pmu.h
> +++ b/include/linux/pmu.h
> @@ -90,6 +90,7 @@ enum {
>          PMU_HEATHROW_BASED,     /* PowerBook G3 series */
>          PMU_PADDINGTON_BASED,   /* 1999 PowerBook G3 */
>          PMU_KEYLARGO_BASED,     /* Core99 motherboard (PMU99) */
> +        PMU_NUBUS_BASED,        /* 1400, 2300, 5300 */
>          PMU_68K_V1,             /* 68K PMU, version 1 */
>          PMU_68K_V2,             /* 68K PMU, version 2 */
>  };

That's bad.  But as long as the NuBus-PMac project is out-of-tree, the
enum values it uses are not part of the Linux ABI, IMHO.
During upstreaming, PMU_NUBUS_BASED should be moved to the bottom.

Gr{oetje,eeting}s,

                        Geert
Michael Schmitz June 10, 2018, 9:12 a.m. | #9
Hi Geert,

Am 10.06.2018 um 20:29 schrieb Geert Uytterhoeven:
> Hi Finn,
>
> On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>>>>> Is this enum used by any user space code? If so, perhaps rather
>>>>> leave the PMU_68K_V1 in there to avoid upsetting that?
>>>>
>>>> It also changes the value of PMU_68K_V2, which is an ABI break.
>>>
>>> Yes, that's what I worry about - but do we know of any users of that
>>> particular interface?
>>
>> 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. This patch
>> series will make these UAPIs available on m68k, and for that reason I've
>> chosen the value PMU_UNKNOWN for pmu_kind.
>
> While /dev/pmu and /proc/pmu/* may not exist on m68k, definitions in
> include/uapi/linux/pmu.h are part of the ABI, and cannot be changed or removed,
> unless we are 100% sure there are no users.
>
> If I would write a program interfacing with /dev/pmu and /proc/pmu/*, and
> needing to check the PMU type, it would have a switch() statement with
> all existing values defined in <linux/pmu.h>. So that would become broken
> by your change.
>
> Hence the enum is append-only.

The PMU type from pmu.h was never exposed to user space on m68k via 
/proc/pmu/*, and /dev/pmu is used for ioctls to the PMU driver on 
powerpc only (the 68k PMU driver doesn't have ioctl support). No way 
that I can see for user space to make use of the PMU type definition 
from pmu.h, so I suppose we can be sure there are no users.

The m68k PMU types cannot be said to be exposed on powerpc either (which 
has ioctl support to interrogate the PMU type), as these only return 
values up to PMU_KEYLARGO_BASED.

Applications like pbbuttonsd or pmud don't use the kernel PMU type at 
all, but go straight to the PMU via the ADB bus to interrogate the 
hardware type, so won't be affected either.

Is there any other way besides procfs and ioctl for user space to 
interrogate the PMU type that I'm missing here?

(I understand that breaking the ABI should not be done as a rule, but 
this may be a case where we can successfully argue the definitions were 
never in use, so the rules may be bent a little).

Cheers,

	Michael


>> New pmu_kind values can be defined as and when the need arises. But that
>> would imply a useful classification scheme for pre-PCI powerbooks, and I
>> don't know what that scheme will look like because at this stage there is
>> neither userland nor kernel code to support backlight, buttons and battery
>> for pre-PCI powerbooks.
>>
>> In anycase, the "v1" and "v2" scheme is obviously inadequate when you
>> consider the range of m68k powerbook models. Also, consider the
>
> New values can be added at the bottom.
>
>> out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has
>> this ABI break:
>>
>> diff --git a/include/linux/pmu.h b/include/linux/pmu.h
>> index cafe98d9694..9882a185a52 100644
>> --- a/include/linux/pmu.h
>> +++ b/include/linux/pmu.h
>> @@ -90,6 +90,7 @@ enum {
>>          PMU_HEATHROW_BASED,     /* PowerBook G3 series */
>>          PMU_PADDINGTON_BASED,   /* 1999 PowerBook G3 */
>>          PMU_KEYLARGO_BASED,     /* Core99 motherboard (PMU99) */
>> +        PMU_NUBUS_BASED,        /* 1400, 2300, 5300 */
>>          PMU_68K_V1,             /* 68K PMU, version 1 */
>>          PMU_68K_V2,             /* 68K PMU, version 2 */
>>  };
>
> That's bad.  But as long as the NuBus-PMac project is out-of-tree, the
> enum values it uses are not part of the Linux ABI, IMHO.
> During upstreaming, PMU_NUBUS_BASED should be moved to the bottom.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
Benjamin Herrenschmidt June 11, 2018, 12:05 a.m. | #10
On Sun, 2018-06-10 at 21:12 +1200, Michael Schmitz wrote:
> Hi Geert,

Top posting, sorry ...

We are painting that bike shed with way too many coats..

We can keep the existing definitions, stick a comment on them stating
"obsolete" and use new number if/when needed.

Ben.


> Am 10.06.2018 um 20:29 schrieb Geert Uytterhoeven:
> > Hi Finn,
> > 
> > On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > > > > Is this enum used by any user space code? If so, perhaps rather
> > > > > > leave the PMU_68K_V1 in there to avoid upsetting that?
> > > > > 
> > > > > It also changes the value of PMU_68K_V2, which is an ABI break.
> > > > 
> > > > Yes, that's what I worry about - but do we know of any users of that
> > > > particular interface?
> > > 
> > > 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. This patch
> > > series will make these UAPIs available on m68k, and for that reason I've
> > > chosen the value PMU_UNKNOWN for pmu_kind.
> > 
> > While /dev/pmu and /proc/pmu/* may not exist on m68k, definitions in
> > include/uapi/linux/pmu.h are part of the ABI, and cannot be changed or removed,
> > unless we are 100% sure there are no users.
> > 
> > If I would write a program interfacing with /dev/pmu and /proc/pmu/*, and
> > needing to check the PMU type, it would have a switch() statement with
> > all existing values defined in <linux/pmu.h>. So that would become broken
> > by your change.
> > 
> > Hence the enum is append-only.
> 
> The PMU type from pmu.h was never exposed to user space on m68k via 
> /proc/pmu/*, and /dev/pmu is used for ioctls to the PMU driver on 
> powerpc only (the 68k PMU driver doesn't have ioctl support). No way 
> that I can see for user space to make use of the PMU type definition 
> from pmu.h, so I suppose we can be sure there are no users.
> 
> The m68k PMU types cannot be said to be exposed on powerpc either (which 
> has ioctl support to interrogate the PMU type), as these only return 
> values up to PMU_KEYLARGO_BASED.
> 
> Applications like pbbuttonsd or pmud don't use the kernel PMU type at 
> all, but go straight to the PMU via the ADB bus to interrogate the 
> hardware type, so won't be affected either.
> 
> Is there any other way besides procfs and ioctl for user space to 
> interrogate the PMU type that I'm missing here?
> 
> (I understand that breaking the ABI should not be done as a rule, but 
> this may be a case where we can successfully argue the definitions were 
> never in use, so the rules may be bent a little).
Michael Schmitz June 11, 2018, 1:45 a.m. | #11
Hi Ben,

I'm glad Finn is caring enough to keep this 20 year old bike shed in
good repair, but this may be overdoing it a little indeed. My bad.

A comment on the V1 PMU entry everyone should be OK with, I hope.

Cheers,

  Michael



On Mon, Jun 11, 2018 at 12:05 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sun, 2018-06-10 at 21:12 +1200, Michael Schmitz wrote:
>> Hi Geert,
>
> Top posting, sorry ...
>
> We are painting that bike shed with way too many coats..
>
> We can keep the existing definitions, stick a comment on them stating
> "obsolete" and use new number if/when needed.
>
> Ben.
>
>
>> Am 10.06.2018 um 20:29 schrieb Geert Uytterhoeven:
>> > Hi Finn,
>> >
>> > On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>> > > > > > Is this enum used by any user space code? If so, perhaps rather
>> > > > > > leave the PMU_68K_V1 in there to avoid upsetting that?
>> > > > >
>> > > > > It also changes the value of PMU_68K_V2, which is an ABI break.
>> > > >
>> > > > Yes, that's what I worry about - but do we know of any users of that
>> > > > particular interface?
>> > >
>> > > 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. This patch
>> > > series will make these UAPIs available on m68k, and for that reason I've
>> > > chosen the value PMU_UNKNOWN for pmu_kind.
>> >
>> > While /dev/pmu and /proc/pmu/* may not exist on m68k, definitions in
>> > include/uapi/linux/pmu.h are part of the ABI, and cannot be changed or removed,
>> > unless we are 100% sure there are no users.
>> >
>> > If I would write a program interfacing with /dev/pmu and /proc/pmu/*, and
>> > needing to check the PMU type, it would have a switch() statement with
>> > all existing values defined in <linux/pmu.h>. So that would become broken
>> > by your change.
>> >
>> > Hence the enum is append-only.
>>
>> The PMU type from pmu.h was never exposed to user space on m68k via
>> /proc/pmu/*, and /dev/pmu is used for ioctls to the PMU driver on
>> powerpc only (the 68k PMU driver doesn't have ioctl support). No way
>> that I can see for user space to make use of the PMU type definition
>> from pmu.h, so I suppose we can be sure there are no users.
>>
>> The m68k PMU types cannot be said to be exposed on powerpc either (which
>> has ioctl support to interrogate the PMU type), as these only return
>> values up to PMU_KEYLARGO_BASED.
>>
>> Applications like pbbuttonsd or pmud don't use the kernel PMU type at
>> all, but go straight to the PMU via the ADB bus to interrogate the
>> hardware type, so won't be affected either.
>>
>> Is there any other way besides procfs and ioctl for user space to
>> interrogate the PMU type that I'm missing here?
>>
>> (I understand that breaking the ABI should not be done as a rule, but
>> this may be a case where we can successfully argue the definitions were
>> never in use, so the rules may be bent a little).
Finn Thain June 11, 2018, 11:47 p.m. | #12
On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote:

> Pre-PCI is basically "NUBUS" based even in absence of an actual NuBus 
> slot :-) It has to do with the internal HW architecture. The only ones 
> that aren't are the even older designs (the 68000 based ones).
> 

There is already some disagreement in the comments in the nubus-pmac code 
about the suitability of "PMU_NUBUS_BASED" as opposed to e.g. 
"PMU_WHITNEY_BASED".

Point is, the PMU driver doesn't care about the expansion slots or 
architecture (Whitney-based PMU appears on m68k and powerpc). So NuBus vs. 
PCI is a red herring here. The pmu_kind relates to backlight, buttons and 
battery.

(Leaving aside the PMU driver, if a pre-OpenFirmware Mac has a "slot zero" 
ROM, one can argue that it is actually a NuBus machine, regardless of any 
actual expansion slots.)

> What's the situation with those NuBus things ? What do they use as a 
> bootloader ? The old Apple one or BootX ? We should merge that port of 
> it's maintained.
> 

I agree that this code should not languish out-of-tree. But it would need 
more work before it could reasonably be submitted to reviewers.

I do have some nubus-pmac hardware but I also have more mac/68k driver 
work to do before I can tackle another architecture.

I don't know what the bootloader situation is, but it looks messy...
http://nubus-pmac.sourceforge.net/#booters

Laurent, does Emile work on these machines?
Laurent Vivier June 12, 2018, 6:53 a.m. | #13
On 12/06/2018 01:47, Finn Thain wrote:
> On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote:
...
> I don't know what the bootloader situation is, but it looks messy...
> http://nubus-pmac.sourceforge.net/#booters
> 
> Laurent, does Emile work on these machines?
> 

No, Emile doesn't work on pmac-nubus, I tried to implement the switch
from m68k to ppc, but it has never worked.

Laurent
Michael Schmitz June 12, 2018, 8:12 p.m. | #14
Hi,

On Tue, Jun 12, 2018 at 6:53 PM, Laurent Vivier <lvivier@redhat.com> wrote:
> On 12/06/2018 01:47, Finn Thain wrote:
>> On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote:
> ...
>> I don't know what the bootloader situation is, but it looks messy...
>> http://nubus-pmac.sourceforge.net/#booters
>>
>> Laurent, does Emile work on these machines?
>>
>
> No, Emile doesn't work on pmac-nubus, I tried to implement the switch
> from m68k to ppc, but it has never worked.

On the PowerMac 6100 that I installed Linux on many years ago, I'm
pretty sure I used Apple's mkLinux boot loader.

Not sure how that would work with modern kernels and initrds though.
Haven't got that hardware anymore so no way try.

Cheers,

  Michael

>
> Laurent

Patch

diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
index c68054361615..7ccb799eeb57 100644
--- a/arch/m68k/mac/misc.c
+++ b/arch/m68k/mac/misc.c
@@ -478,8 +478,7 @@  void mac_poweroff(void)
 		cuda_shutdown();
 #endif
 #ifdef CONFIG_ADB_PMU68K
-	} else if (macintosh_config->adb_type == MAC_ADB_PB1
-		|| macintosh_config->adb_type == MAC_ADB_PB2) {
+	} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
 		pmu_shutdown();
 #endif
 	}
@@ -520,8 +519,7 @@  void mac_reset(void)
 		cuda_restart();
 #endif
 #ifdef CONFIG_ADB_PMU68K
-	} else if (macintosh_config->adb_type == MAC_ADB_PB1
-		|| macintosh_config->adb_type == MAC_ADB_PB2) {
+	} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
 		pmu_restart();
 #endif
 	} else if (CPU_IS_030) {
diff --git a/drivers/macintosh/via-pmu68k.c b/drivers/macintosh/via-pmu68k.c
index d545ed45e482..bec8e1837d7d 100644
--- a/drivers/macintosh/via-pmu68k.c
+++ b/drivers/macintosh/via-pmu68k.c
@@ -175,9 +175,6 @@  static s8 pmu_data_len[256][2] = {
 int __init find_via_pmu(void)
 {
 	switch (macintosh_config->adb_type) {
-	case MAC_ADB_PB1:
-		pmu_kind = PMU_68K_V1;
-		break;
 	case MAC_ADB_PB2:
 		pmu_kind = PMU_68K_V2;
 		break;
@@ -785,7 +782,6 @@  pmu_enable_backlight(int on)
 	    /* first call: get current backlight value */
 	    if (backlight_level < 0) {
 		switch(pmu_kind) {
-		    case PMU_68K_V1:
 		    case PMU_68K_V2:
 			pmu_request(&req, NULL, 3, PMU_READ_NVRAM, 0x14, 0xe);
 			while (!req.complete)
diff --git a/include/uapi/linux/pmu.h b/include/uapi/linux/pmu.h
index 89cb1acea93a..30f64d46f5db 100644
--- a/include/uapi/linux/pmu.h
+++ b/include/uapi/linux/pmu.h
@@ -93,7 +93,6 @@  enum {
 	PMU_HEATHROW_BASED,	/* PowerBook G3 series */
 	PMU_PADDINGTON_BASED,	/* 1999 PowerBook G3 */
 	PMU_KEYLARGO_BASED,	/* Core99 motherboard (PMU99) */
-	PMU_68K_V1,		/* 68K PMU, version 1 */
 	PMU_68K_V2, 		/* 68K PMU, version 2 */
 };