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

[Andrei Borzenkov]

17.02.2016 05:02, 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.
> 

I mean to read device aliases created by OBP (those displayed by
devalias OBP command).

disk0 
/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden
...