| Message ID | d9d626ca4e7ac9c7e81b24a34f5fbcae9d1d5046.1528423341.git.fthain@telegraphics.com.au (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | macintosh: Resolve various PMU driver problems | expand |
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
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.
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. >
> > > 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.) --
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.
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.
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.
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
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 >
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).
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).
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?
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
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
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 */ };
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(-)