Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up

From: Harry Coin <harrycoin_at_qconline.com>
Date: Tue, 12 Jul 2005 14:19:06 -0500
At 10:44 AM 7/12/2005 -0400, John Baldwin wrote:
>Now, when ACPI is enabled, the
>pnpmss driver doesn't probe the device IIRC?

Both the mss_probe and pnpmss_probe routine are called in the ACPI case and 
in the ACPI disabled case.   Let me help by providing proof from some 
edited short form commented dmesg excerpts from upstream postings using 
unmodified-except-for-debug-writes mss.c:

In the case ACPI is enabled, you get:
...
atpic: Programming IRQ9 as level/low
mss_probe: bus acpi0 is probing device pcm0  -- non-pnp probe does not find 
device
pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh
pnpmss_probe result 6
mss_probe: bus acpi0 is probing device pcm0  -- non-pnp probe does not find 
device
pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh
pnpmss_probe result 6
ACPI timer: 0/6 0/4 0/5 0/6 0/6 0/4 0/6 0/6 0/6 0/5 -> 0
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
mss_probe: bus acpi0 is probing device pcm0
mss_probe: isa_get_logicalid() returned 0!  -- non pnp probe FINDS the 
device, wrongly.  Using the ISA_PNP_PROBE does the right thing here.
mss_probe: no address given, try 0x530
mss_detect - chip revision 0x0a
mss_detect() - Detected CS4236
pcm0: <CS4236> port 0x530-0x537 on acpi0
device_attach: pcm0 attach returned 6
mss_probe: bus acpi0 is probing device pcm1
pnpmss_probe: bus acpi0 is probing device pcm1 lid 30ad041h, vid ffffffffh
pnpmss_probe result 6
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
<snip>...
isa_probe_children: probing PnP devices
mss_probe: bus isa0 is probing device pcm3
pnpmss_probe: bus isa0 is probing device pcm3 lid 630eh, vid 3568630eh
pnpmss_probe result 0
pcm3: <CS4236B> at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 
on isa0
CS4236B X25 reg: ebh
...<snip and so on>


In the case ACPI is not enabled,  you get:

..isa_probe_children: probing PnP devices
mss_probe: bus isa0 is probing device pcm0
pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh
pnpmss_probe result 0
pcm0: <CS4236B> at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 
on isa0
CS4236B X25 reg: ebh
..
Note that in the non-ACPI case, the non-pnp probe routine, mss_probe, when 
called by isa0 does the right thing and fails to accept the pnp 
device.  The pnp probe routine correctly probes the device in this case.

The question I can't get out of my head is this:  When I change the mss.c 
code to use the routine the manual says non-PNP devices are supposed to 
use: ISA_PNP_PROBE -- all bootup operations are correct in both the ACPI 
and non ACPI case.

Why doesn't that count as 'fixed, update mss.c and lets move on?'.

Clearly the present code uses another function that doesn't work in the 
ACPI case.  Shouldn't the investigation focus on what ISA_PNP_PROBE knows 
that the other call doesn't?   ISA_PNP_PROBE in mss_probe works and matches 
the docs, the isa_get_whatziz doesn't work and is not accepted as correct 
practice in the docs.   Maybe the doc writer has the answer.  At any 
rate  I don't get why this further investigation when an apparently 
'canonical' practice works.  That, or the architecture manual needs 
changing to mention this other way to avoid wrongful probing by non-PNP isa 
drivers when called by ACPI or isa0.

If you still want me to try a test I'm game, let me know.  It would 
encourage me to do so with the insight provided by some comments on the 
above though.

Harry
Received on Tue Jul 12 2005 - 17:19:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC