[PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[David Miller]

We skip CDROMs in the block device iterator because they simply can't
be openned safely unless we absolutely know there is a CDROM drive
there and there is in fact a disc in the drive.

Openning it blindly results in either a 10 second hang during the open
call, or even worse a crash in OpenFirmware.

My SunBlade100 wouldn't boot a kernel properly because not only does
it by default have a "cdrom" alias, it also has two others named
"cdrom1" and "cdrom2".

So to cover all cases, match "cdrom" as a 5 character prefix of the
alias name in the check.

I tried to surmise other ways to do this more cleanly, such as
resolving the path and looking for some device property inside of the
resulting node, but there simply isn't anything we can check for.

BTW, if people want to look at some OpenFirmware device tree dumps on
just about every sparc64 system type there is a GIT repo where we
maintain such things contributed by various sparc64 Linux users at:

	git://git.kernel.org/pub/scm/linux/kernel/git/davem/prtconfs.git

There are some 32-bit sparc dumps in there, but the majority are
64-bit systems.

Anyways, here is the fix, please apply thanks!

2009-12-06  David S. Miller  <davem@sunset.davemloft.net>

	* disk/ieee1275/ofdisk.c (grub_ofdisk_iterate): Recognize
	anything even prefixed with 'cdrom' as a cdrom.

=== modified file 'disk/ieee1275/ofdisk.c'
--- disk/ieee1275/ofdisk.c	2009-06-10 21:04:23 +0000
+++ disk/ieee1275/ofdisk.c	2009-12-07 02:13:52 +0000
@@ -107,7 +107,7 @@
 	}
 
       if (! grub_strcmp (alias->type, "block") &&
-	  grub_strcmp (alias->name, "cdrom"))
+	  grub_strncmp (alias->name, "cdrom", 5))
 	ret = hook (alias->name);
       return ret;
     }

Re: [PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Committed.
David Miller wrote:
> I tried to surmise other ways to do this more cleanly, such as
> resolving the path and looking for some device property inside of the
> resulting node, but there simply isn't anything we can check for.
>
>   
If you find a cleaner way we can commit it later. I was thinking of
resolving path to hardware one and then querying hardware directly but
it may conflict with OF. What do you think?
How much work would be needed to make ata.mod work on sparc64?
Which other drivers we would need to reasonably replace ofdisk (which
would still be available as fallback)? In dumps in addition to ide I see
protocols FP, ESP, SCSI, FAS, ISP, ULSA, SAS, SoC. ESP looks like
SBUS-only so it can be fallbacked to OF considering number of users. I
have no idea what FP,FAS, ISP, ULSA, SAS, SoC stand for and even if they
are real protocols or just some weird pathnames. As for SCSI we
definitely want it and already have scsi.mod but not the encapsulator of
SCSI commands

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[David Miller]

From: Vladimir '^[$B&U^[(B-coder/phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 07 Dec 2009 12:05:24 +0100

> Committed.
> David Miller wrote:
>> I tried to surmise other ways to do this more cleanly, such as
>> resolving the path and looking for some device property inside of the
>> resulting node, but there simply isn't anything we can check for.
>>
>>   
> If you find a cleaner way we can commit it later. I was thinking of
> resolving path to hardware one and then querying hardware directly but
> it may conflict with OF. What do you think?

I don't think that is wise.

We would then need two mappings, OF --> OS and OS --> OF for
device naming.  And all of that complexity for what?  This
silly cdrom issue where a simple strncmp() is solving the
problem quite well so far?

There are conventions for alias names created by default by
the firmware, so we should be OK with the patch I have written
here.

> How much work would be needed to make ata.mod work on sparc64?

Probably a lot.

> Which other drivers we would need to reasonably replace ofdisk (which
> would still be available as fallback)?

I don't think it's worthwhile to break away from ofdisk, it works
quite well.

Re: [PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

David Miller wrote:
> From: Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>
> Date: Mon, 07 Dec 2009 12:05:24 +0100
>
>   
>> Committed.
>> David Miller wrote:
>>     
>>> I tried to surmise other ways to do this more cleanly, such as
>>> resolving the path and looking for some device property inside of the
>>> resulting node, but there simply isn't anything we can check for.
>>>
>>>   
>>>       
>> If you find a cleaner way we can commit it later. I was thinking of
>> resolving path to hardware one and then querying hardware directly but
>> it may conflict with OF. What do you think?
>>     
>
> I don't think that is wise.
>
> We would then need two mappings, OF --> OS and OS --> OF for
> device naming.  
I don't understand why we would need such a mapping. I meant to use full
OF path which gives us where device is attached physically and so we can
connect to it.
> And all of that complexity for what?  This
> silly cdrom issue where a simple strncmp() is solving the
> problem quite well so far?
>
> There are conventions for alias names created by default by
> the firmware, so we should be OK with the patch I have written
> here.
>
>   
The problem is that if user has defined additional aliases we fall into
original problem.
>> How much work would be needed to make ata.mod work on sparc64?
>>     
>
> Probably a lot.
>
>   
It already works on MIPS and AFAICT only thing it needs to work is PCI.
Do you mean that accessing PCI on sparc is a lot of work?


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [PATCH]: Fix CDROM skipping in ieee1275 ofdisk iterator.

[David Miller]

From: Vladimir '^[$B&U^[(B-coder/phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 07 Dec 2009 12:52:01 +0100

> It already works on MIPS and AFAICT only thing it needs to work is PCI.
> Do you mean that accessing PCI on sparc is a lot of work?

Even just calculating the register addresses is a lot of work.

You can't just take the property values for the device as-is, you have
to walk up to the root applying 'range' property translations to the
register addresses.

And there are special cases and quirks all over the place.

The code to do this in the Linux kernel is several thousand lines of
code.