Re: [PATCH] sparc64: fix OF path names for sun4v systems

[Eric Snowberg]

> On Feb 16, 2016, at 1:16 AM, Andrei Borzenkov <address@hidden> wrote:
> 
> On Mon, Feb 15, 2016 at 10:11 PM, Eric Snowberg
> <address@hidden> wrote:
>> Fix the open firmware path property for sun4v SPARC systems. These
>> platforms do not have a /sas/ within their path.  Over time
>> different OF addressing schemes have been supported. There
>> is no generic addressing scheme that works across every HBA.
>> 
>> Signed-off-by: Eric Snowberg <address@hidden>
>> ---
>> grub-core/osdep/linux/ofpath.c |  192 
>> +++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 190 insertions(+), 2 deletions(-)
>> 
>> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
>> index a79682a..de51c57 100644
>> --- a/grub-core/osdep/linux/ofpath.c
>> +++ b/grub-core/osdep/linux/ofpath.c
> ...
>> @@ -444,6 +525,111 @@ of_path_of_scsi(const char *sys_devname 
>> __attribute__((unused)), const char *dev
>>     }
>>   else
>>     {
>> +#ifdef __sparc__
>> +      int vendor = 0, device_id = 0;
>> +      check_hba_identifiers(sysfs_path, &vendor, &device_id);
>> +
>> +      if (vendor == 0x1000) /* LSI Logic Vendor ID */
>> +        {
>> +           /* Over time different OF addressing schemes have been supported 
>> */
>> +           /* There is no generic addressing scheme that works across */
>> +           /* every HBA */
>> +          switch (device_id)
>> +            {
>> +            case 0x30: /* Rhea, Jasper 320, LSI53C1020/1030 */
>> +            case 0x50: /* SAS-1068E                         */
>> +            case 0x56: /* SAS-1064E                         */
>> +            case 0x58: /* Pandora SAS-1068E                 */
>> +            case 0x5d: /* Aspen, Invader, LSI SAS-3108      */
>> +            case 0x79: /* Niwot, SAS 2108                   */
> 
> That really does not scale. Can we enumerate device aliases and take
> diskN and cdromN? So that we do not need to duplicate OBP logic?
> 

Do you have an idea in mind on how to do this differently to make it scale 
better?  This patch will default to the old address@hidden for unknown HBAs.  I 
agree it doesn’t scale that well, but new HBAs for SPARC with OF support don't 
come out that often. 

Before this patch, there isn’t a single SAS HBA that is enumerated correctly on 
SPARC.  I went back 10 years and believe I have added every HBA with OF 
support.  This isn’t duplicating OBP logic.  The final part of the device path 
is vendor specific.  OBP does not control that part of the path, it just uses 
it.  Unfortunately there isn’t a standard. This code only gets run during 
setup/install (not boot) to return the path for OBP to use.

You mentioned cdroms being enumerated with cdromN.  I believe that type of 
enumeration stopped with IDE drives.  A USB cdrom would be enumerated something 
like this:

/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden

So the function that runs during boot: check_string_removable does not identify 
the cdrom properly.

I’m open to making any changes to this patch if you have some ideas in mind. I 
tried to base it off of what was already in ofpath.c and I have some follow on 
patches coming the rely on this path being correct.

> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel