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

[Andrei Borzenkov <arvidjaar@gmail.com>]

17.02.2016 05:02, Eric Snowberg пишет:
> 
>> On Feb 16, 2016, at 1:16 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>
>> On Mon, Feb 15, 2016 at 10:11 PM, Eric Snowberg
>> <eric.snowberg@oracle.com> 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 <eric.snowberg@oracle.com>
>>> ---
>>> 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 disk@N 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:
> 
> /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0
> 
> 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 /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0
...