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

2018-02-14 Thread Daniel Kiper 
On Fri, Feb 09, 2018 at 01:33:52PM +0100, Daniel Kiper wrote:
> On Fri, Feb 09, 2018 at 01:10:45PM +0100, John Paul Adrian Glaubitz wrote:
> > On 02/09/2018 12:04 PM, Daniel Kiper wrote:
> > >>Ok, do you want to remove it?  Or should I send out an updated patch?
> > >
> > >I will remove it before commit.
> >
> > Is it going in today? ;-)
>
> Sadly no. I am busy with other stuff. I will apply this and
> other outstanding patches next week.

Done!

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-09 Thread Daniel Kiper 
On Fri, Feb 09, 2018 at 01:10:45PM +0100, John Paul Adrian Glaubitz wrote:
> On 02/09/2018 12:04 PM, Daniel Kiper wrote:
> >>Ok, do you want to remove it?  Or should I send out an updated patch?
> >
> >I will remove it before commit.
>
> Is it going in today? ;-)

Sadly no. I am busy with other stuff. I will apply this and
other outstanding patches next week.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-09 Thread John Paul Adrian Glaubitz 

On 02/09/2018 12:04 PM, Daniel Kiper wrote:

Ok, do you want to remove it?  Or should I send out an updated patch?


I will remove it before commit.


Is it going in today? ;-)

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-09 Thread Daniel Kiper 
On Thu, Feb 08, 2018 at 08:37:27AM -0700, Eric Snowberg wrote:
> > On Feb 8, 2018, at 8:11 AM, Daniel Kiper  wrote:
> > On Wed, Feb 07, 2018 at 10:39:00AM -0700, Eric Snowberg wrote:
> >>> On Feb 7, 2018, at 4:53 AM, Daniel Kiper  wrote:
> >>> On Tue, Jan 30, 2018 at 08:49:48PM -0800, Eric Snowberg wrote:
>  Fix the Open Firmware (OF) 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 
> >>>
> >>> In general Reviewed-by: Daniel Kiper ...
> >>>
> >>> Just a few comments below...
> >>>
>  ---
>  V2:
>  - Requested coding style changes
>  ---
>  grub-core/osdep/linux/ofpath.c |  148 
>  +++-
>  1 files changed, 145 insertions(+), 3 deletions(-)
> 
>  diff --git a/grub-core/osdep/linux/ofpath.c 
>  b/grub-core/osdep/linux/ofpath.c
>  index dce4e59..5369508 100644
>  --- a/grub-core/osdep/linux/ofpath.c
>  +++ b/grub-core/osdep/linux/ofpath.c
>  @@ -38,6 +38,46 @@
>  #include 
>  #include 
> 
>  +#ifdef __sparc__
> >>>
> >>> I have discussed this with Vladimir. It looks that this will not
> >>> work if you try to cross-install SPARC GRUB2 binary using e.g.
> >>> x86 grub-install. By default it should work. However, we will also
> >>> have other issues here, like lack of access to OF firmware/paths,
> >>> which make such configs unusable anyway. So, I would leave this patch
> >>> as is for time being. If somebody cares then he/she should fix it.
> >>>
> >>> Anyway, I will add something like that into the commit message before 
> >>> committing.
> >>
> >> That is fine with me.
> >
> > Great! Thanks!
> >
>  +typedef enum
>  +  {
>  +GRUB_OFPATH_SPARC_WWN_ADDR = 1,
>  +GRUB_OFPATH_SPARC_TGT_LUN,
>  +  } ofpath_sparc_addressing;
>  +
>  +struct ofpath_sparc_hba
>  +{
>  +  grub_uint32_t device_id;
>  +  ofpath_sparc_addressing addressing;
>  +};
>  +
>  +static struct ofpath_sparc_hba sparc_lsi_hba[] = {
>  +  /* Rhea, Jasper 320, LSI53C1020/1030. */
>  +  {0x30, GRUB_OFPATH_SPARC_TGT_LUN},
>  +  /* SAS-1068E. */
>  +  {0x50, GRUB_OFPATH_SPARC_TGT_LUN},
>  +  /* SAS-1064E. */
>  +  {0x56, GRUB_OFPATH_SPARC_TGT_LUN},
>  +  /* Pandora SAS-1068E. */
>  +  {0x58, GRUB_OFPATH_SPARC_TGT_LUN},
>  +  /* Aspen, Invader, LSI SAS-3108. */
>  +  {0x5d, GRUB_OFPATH_SPARC_TGT_LUN},
>  +  /* Niwot, SAS 2108. */
>  +  {0x79, GRUB_OFPATH_SPARC_TGT_LUN},
>  +  /* Erie, Falcon, LSI SAS 2008. */
>  +  {0x72, GRUB_OFPATH_SPARC_WWN_ADDR},
>  +  /* LSI WarpDrive 6203. */
>  +  {0x7e, GRUB_OFPATH_SPARC_WWN_ADDR},
>  +  /* LSI SAS 2308. */
>  +  {0x87, GRUB_OFPATH_SPARC_WWN_ADDR},
>  +  /* LSI SAS 3008. */
>  +  {0x97, GRUB_OFPATH_SPARC_WWN_ADDR},
>  +  {0, 0}
>  +};
>  +
>  +static const int LSI_VENDOR_ID = 0x1000;
>  +#endif
>  +
>  #ifdef OFPATH_STANDALONE
>  #define xmalloc malloc
>  void
>  @@ -338,6 +378,67 @@ vendor_is_ATA(const char *path)
>   return (memcmp(bufcont, "ATA", 3) == 0);
>  }
> 
>  +#ifdef __sparc__
>  +static void
>  +check_hba_identifiers (const char *sysfs_path, int *vendor, int 
>  *device_id)
>  +{
>  +  char *ed = strstr (sysfs_path, "host");
>  +  size_t path_size;
>  +  char *p, *path;
>  +  char buf[8];
>  +  int fd;
>  +
>  +  if (!ed)
>  +return;
>  +
>  +  p = xstrdup (sysfs_path);
>  +  ed = strstr (p, "host");
>  +
>  +  if (!ed)
>  +goto out;
> >>>
> >>> In normal circumstances this will never ever fail.
> >>> If you are OK I will drop this "if" before committing.
> >>
> >> I put that in for the case if the xstrdup above can not allocate memory.
> >> Then p will be null, the strstr will fail and then we should jump to out.
> >
> > If this would be the case then you should check p for NULL before
> > strstr() call. AIUI its behavior is not well defined if one of
> > arguments is NULL. Anyway, xstrdup() does not return if it fails.
> > So, we do not have such problem here.
>
> Ok, do you want to remove it?  Or should I send out an updated patch?

I will remove it before commit.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-08 Thread Eric Snowberg 

> On Feb 8, 2018, at 8:11 AM, Daniel Kiper  wrote:
> 
> On Wed, Feb 07, 2018 at 10:39:00AM -0700, Eric Snowberg wrote:
>>> On Feb 7, 2018, at 4:53 AM, Daniel Kiper  wrote:
>>> On Tue, Jan 30, 2018 at 08:49:48PM -0800, Eric Snowberg wrote:
 Fix the Open Firmware (OF) 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 
>>> 
>>> In general Reviewed-by: Daniel Kiper ...
>>> 
>>> Just a few comments below...
>>> 
 ---
 V2:
 - Requested coding style changes
 ---
 grub-core/osdep/linux/ofpath.c |  148 
 +++-
 1 files changed, 145 insertions(+), 3 deletions(-)
 
 diff --git a/grub-core/osdep/linux/ofpath.c 
 b/grub-core/osdep/linux/ofpath.c
 index dce4e59..5369508 100644
 --- a/grub-core/osdep/linux/ofpath.c
 +++ b/grub-core/osdep/linux/ofpath.c
 @@ -38,6 +38,46 @@
 #include 
 #include 
 
 +#ifdef __sparc__
>>> 
>>> I have discussed this with Vladimir. It looks that this will not
>>> work if you try to cross-install SPARC GRUB2 binary using e.g.
>>> x86 grub-install. By default it should work. However, we will also
>>> have other issues here, like lack of access to OF firmware/paths,
>>> which make such configs unusable anyway. So, I would leave this patch
>>> as is for time being. If somebody cares then he/she should fix it.
>>> 
>>> Anyway, I will add something like that into the commit message before 
>>> committing.
>> 
>> That is fine with me.
> 
> Great! Thanks!
> 
 +typedef enum
 +  {
 +GRUB_OFPATH_SPARC_WWN_ADDR = 1,
 +GRUB_OFPATH_SPARC_TGT_LUN,
 +  } ofpath_sparc_addressing;
 +
 +struct ofpath_sparc_hba
 +{
 +  grub_uint32_t device_id;
 +  ofpath_sparc_addressing addressing;
 +};
 +
 +static struct ofpath_sparc_hba sparc_lsi_hba[] = {
 +  /* Rhea, Jasper 320, LSI53C1020/1030. */
 +  {0x30, GRUB_OFPATH_SPARC_TGT_LUN},
 +  /* SAS-1068E. */
 +  {0x50, GRUB_OFPATH_SPARC_TGT_LUN},
 +  /* SAS-1064E. */
 +  {0x56, GRUB_OFPATH_SPARC_TGT_LUN},
 +  /* Pandora SAS-1068E. */
 +  {0x58, GRUB_OFPATH_SPARC_TGT_LUN},
 +  /* Aspen, Invader, LSI SAS-3108. */
 +  {0x5d, GRUB_OFPATH_SPARC_TGT_LUN},
 +  /* Niwot, SAS 2108. */
 +  {0x79, GRUB_OFPATH_SPARC_TGT_LUN},
 +  /* Erie, Falcon, LSI SAS 2008. */
 +  {0x72, GRUB_OFPATH_SPARC_WWN_ADDR},
 +  /* LSI WarpDrive 6203. */
 +  {0x7e, GRUB_OFPATH_SPARC_WWN_ADDR},
 +  /* LSI SAS 2308. */
 +  {0x87, GRUB_OFPATH_SPARC_WWN_ADDR},
 +  /* LSI SAS 3008. */
 +  {0x97, GRUB_OFPATH_SPARC_WWN_ADDR},
 +  {0, 0}
 +};
 +
 +static const int LSI_VENDOR_ID = 0x1000;
 +#endif
 +
 #ifdef OFPATH_STANDALONE
 #define xmalloc malloc
 void
 @@ -338,6 +378,67 @@ vendor_is_ATA(const char *path)
  return (memcmp(bufcont, "ATA", 3) == 0);
 }
 
 +#ifdef __sparc__
 +static void
 +check_hba_identifiers (const char *sysfs_path, int *vendor, int 
 *device_id)
 +{
 +  char *ed = strstr (sysfs_path, "host");
 +  size_t path_size;
 +  char *p, *path;
 +  char buf[8];
 +  int fd;
 +
 +  if (!ed)
 +return;
 +
 +  p = xstrdup (sysfs_path);
 +  ed = strstr (p, "host");
 +
 +  if (!ed)
 +goto out;
>>> 
>>> In normal circumstances this will never ever fail.
>>> If you are OK I will drop this "if" before committing.
>> 
>> I put that in for the case if the xstrdup above can not allocate memory.
>> Then p will be null, the strstr will fail and then we should jump to out.
> 
> If this would be the case then you should check p for NULL before
> strstr() call. AIUI its behavior is not well defined if one of
> arguments is NULL. Anyway, xstrdup() does not return if it fails.
> So, we do not have such problem here.

Ok, do you want to remove it?  Or should I send out an updated patch?

> 
>>> If there are no objections I will commit this patch in a week or so.
>> 
>> Thanks…
>> 
>> Is there some reason this patch is being held up too?
>> 
>> http://lists.gnu.org/archive/html/grub-devel/2017-05/msg00045.html
>> 
>> This is where things last left off:
>> 
>> http://lists.gnu.org/archive/html/grub-devel/2017-10/msg00046.html
>> 
>> We really need minimal GPT support in there for many of the follow on 
>> patches in my queue.
> 
> Oh, sorry, I have simply forgotten about that patch. I will commit
> it with this one.

Thanks 


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-08 Thread Daniel Kiper 
On Wed, Feb 07, 2018 at 10:39:00AM -0700, Eric Snowberg wrote:
> > On Feb 7, 2018, at 4:53 AM, Daniel Kiper  wrote:
> > On Tue, Jan 30, 2018 at 08:49:48PM -0800, Eric Snowberg wrote:
> >> Fix the Open Firmware (OF) 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 
> >
> > In general Reviewed-by: Daniel Kiper ...
> >
> > Just a few comments below...
> >
> >> ---
> >> V2:
> >>  - Requested coding style changes
> >> ---
> >> grub-core/osdep/linux/ofpath.c |  148 
> >> +++-
> >> 1 files changed, 145 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/grub-core/osdep/linux/ofpath.c 
> >> b/grub-core/osdep/linux/ofpath.c
> >> index dce4e59..5369508 100644
> >> --- a/grub-core/osdep/linux/ofpath.c
> >> +++ b/grub-core/osdep/linux/ofpath.c
> >> @@ -38,6 +38,46 @@
> >> #include 
> >> #include 
> >>
> >> +#ifdef __sparc__
> >
> > I have discussed this with Vladimir. It looks that this will not
> > work if you try to cross-install SPARC GRUB2 binary using e.g.
> > x86 grub-install. By default it should work. However, we will also
> > have other issues here, like lack of access to OF firmware/paths,
> > which make such configs unusable anyway. So, I would leave this patch
> > as is for time being. If somebody cares then he/she should fix it.
> >
> > Anyway, I will add something like that into the commit message before 
> > committing.
>
> That is fine with me.

Great! Thanks!

> >> +typedef enum
> >> +  {
> >> +GRUB_OFPATH_SPARC_WWN_ADDR = 1,
> >> +GRUB_OFPATH_SPARC_TGT_LUN,
> >> +  } ofpath_sparc_addressing;
> >> +
> >> +struct ofpath_sparc_hba
> >> +{
> >> +  grub_uint32_t device_id;
> >> +  ofpath_sparc_addressing addressing;
> >> +};
> >> +
> >> +static struct ofpath_sparc_hba sparc_lsi_hba[] = {
> >> +  /* Rhea, Jasper 320, LSI53C1020/1030. */
> >> +  {0x30, GRUB_OFPATH_SPARC_TGT_LUN},
> >> +  /* SAS-1068E. */
> >> +  {0x50, GRUB_OFPATH_SPARC_TGT_LUN},
> >> +  /* SAS-1064E. */
> >> +  {0x56, GRUB_OFPATH_SPARC_TGT_LUN},
> >> +  /* Pandora SAS-1068E. */
> >> +  {0x58, GRUB_OFPATH_SPARC_TGT_LUN},
> >> +  /* Aspen, Invader, LSI SAS-3108. */
> >> +  {0x5d, GRUB_OFPATH_SPARC_TGT_LUN},
> >> +  /* Niwot, SAS 2108. */
> >> +  {0x79, GRUB_OFPATH_SPARC_TGT_LUN},
> >> +  /* Erie, Falcon, LSI SAS 2008. */
> >> +  {0x72, GRUB_OFPATH_SPARC_WWN_ADDR},
> >> +  /* LSI WarpDrive 6203. */
> >> +  {0x7e, GRUB_OFPATH_SPARC_WWN_ADDR},
> >> +  /* LSI SAS 2308. */
> >> +  {0x87, GRUB_OFPATH_SPARC_WWN_ADDR},
> >> +  /* LSI SAS 3008. */
> >> +  {0x97, GRUB_OFPATH_SPARC_WWN_ADDR},
> >> +  {0, 0}
> >> +};
> >> +
> >> +static const int LSI_VENDOR_ID = 0x1000;
> >> +#endif
> >> +
> >> #ifdef OFPATH_STANDALONE
> >> #define xmalloc malloc
> >> void
> >> @@ -338,6 +378,67 @@ vendor_is_ATA(const char *path)
> >>   return (memcmp(bufcont, "ATA", 3) == 0);
> >> }
> >>
> >> +#ifdef __sparc__
> >> +static void
> >> +check_hba_identifiers (const char *sysfs_path, int *vendor, int 
> >> *device_id)
> >> +{
> >> +  char *ed = strstr (sysfs_path, "host");
> >> +  size_t path_size;
> >> +  char *p, *path;
> >> +  char buf[8];
> >> +  int fd;
> >> +
> >> +  if (!ed)
> >> +return;
> >> +
> >> +  p = xstrdup (sysfs_path);
> >> +  ed = strstr (p, "host");
> >> +
> >> +  if (!ed)
> >> +goto out;
> >
> > In normal circumstances this will never ever fail.
> > If you are OK I will drop this "if" before committing.
>
> I put that in for the case if the xstrdup above can not allocate memory.
> Then p will be null, the strstr will fail and then we should jump to out.

If this would be the case then you should check p for NULL before
strstr() call. AIUI its behavior is not well defined if one of
arguments is NULL. Anyway, xstrdup() does not return if it fails.
So, we do not have such problem here.

> > If there are no objections I will commit this patch in a week or so.
>
> Thanks…
>
> Is there some reason this patch is being held up too?
>
> http://lists.gnu.org/archive/html/grub-devel/2017-05/msg00045.html
>
> This is where things last left off:
>
> http://lists.gnu.org/archive/html/grub-devel/2017-10/msg00046.html
>
> We really need minimal GPT support in there for many of the follow on patches 
> in my queue.

Oh, sorry, I have simply forgotten about that patch. I will commit
it with this one.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-07 Thread John Paul Adrian Glaubitz 
On 02/07/2018 06:39 PM, Eric Snowberg wrote:
> Is there some reason this patch is being held up too?
> 
> http://lists.gnu.org/archive/html/grub-devel/2017-05/msg00045.html
> 
> This is where things last left off:
> 
> http://lists.gnu.org/archive/html/grub-devel/2017-10/msg00046.html
> 
> We really need minimal GPT support in there for many of the follow on patches 
> in my queue.

FWIW, we have received lots of positive feedback from Debian users on
sparc64 with Eric's patches applied to the Debian GRUB package:

> https://lists.debian.org/debian-sparc/2018/02/msg00015.html
> https://lists.debian.org/debian-sparc/2017/12/msg00027.html
> https://lists.debian.org/debian-sparc/2017/12/msg00050.html
> https://lists.debian.org/debian-sparc/2017/12/msg00053.html
> https://lists.debian.org/debian-sparc/2017/12/msg00074.html

Even machines reported as old as the Ultra10 are reported to
work fine.

I am mentioning this because I talked to Vladimir and Daniel
at FOSDEM and there was concern whether this patch series would
break GRUB on old SPARC machines.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-07 Thread Eric Snowberg 

> On Feb 7, 2018, at 4:53 AM, Daniel Kiper  wrote:
> 
> On Tue, Jan 30, 2018 at 08:49:48PM -0800, Eric Snowberg wrote:
>> Fix the Open Firmware (OF) 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 
> 
> In general Reviewed-by: Daniel Kiper ...
> 
> Just a few comments below...
> 
>> ---
>> V2:
>>  - Requested coding style changes
>> ---
>> grub-core/osdep/linux/ofpath.c |  148 
>> +++-
>> 1 files changed, 145 insertions(+), 3 deletions(-)
>> 
>> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
>> index dce4e59..5369508 100644
>> --- a/grub-core/osdep/linux/ofpath.c
>> +++ b/grub-core/osdep/linux/ofpath.c
>> @@ -38,6 +38,46 @@
>> #include 
>> #include 
>> 
>> +#ifdef __sparc__
> 
> I have discussed this with Vladimir. It looks that this will not
> work if you try to cross-install SPARC GRUB2 binary using e.g.
> x86 grub-install. By default it should work. However, we will also
> have other issues here, like lack of access to OF firmware/paths,
> which make such configs unusable anyway. So, I would leave this patch
> as is for time being. If somebody cares then he/she should fix it.
> 
> Anyway, I will add something like that into the commit message before 
> committing.

That is fine with me.

> 
>> +typedef enum
>> +  {
>> +GRUB_OFPATH_SPARC_WWN_ADDR = 1,
>> +GRUB_OFPATH_SPARC_TGT_LUN,
>> +  } ofpath_sparc_addressing;
>> +
>> +struct ofpath_sparc_hba
>> +{
>> +  grub_uint32_t device_id;
>> +  ofpath_sparc_addressing addressing;
>> +};
>> +
>> +static struct ofpath_sparc_hba sparc_lsi_hba[] = {
>> +  /* Rhea, Jasper 320, LSI53C1020/1030. */
>> +  {0x30, GRUB_OFPATH_SPARC_TGT_LUN},
>> +  /* SAS-1068E. */
>> +  {0x50, GRUB_OFPATH_SPARC_TGT_LUN},
>> +  /* SAS-1064E. */
>> +  {0x56, GRUB_OFPATH_SPARC_TGT_LUN},
>> +  /* Pandora SAS-1068E. */
>> +  {0x58, GRUB_OFPATH_SPARC_TGT_LUN},
>> +  /* Aspen, Invader, LSI SAS-3108. */
>> +  {0x5d, GRUB_OFPATH_SPARC_TGT_LUN},
>> +  /* Niwot, SAS 2108. */
>> +  {0x79, GRUB_OFPATH_SPARC_TGT_LUN},
>> +  /* Erie, Falcon, LSI SAS 2008. */
>> +  {0x72, GRUB_OFPATH_SPARC_WWN_ADDR},
>> +  /* LSI WarpDrive 6203. */
>> +  {0x7e, GRUB_OFPATH_SPARC_WWN_ADDR},
>> +  /* LSI SAS 2308. */
>> +  {0x87, GRUB_OFPATH_SPARC_WWN_ADDR},
>> +  /* LSI SAS 3008. */
>> +  {0x97, GRUB_OFPATH_SPARC_WWN_ADDR},
>> +  {0, 0}
>> +};
>> +
>> +static const int LSI_VENDOR_ID = 0x1000;
>> +#endif
>> +
>> #ifdef OFPATH_STANDALONE
>> #define xmalloc malloc
>> void
>> @@ -338,6 +378,67 @@ vendor_is_ATA(const char *path)
>>   return (memcmp(bufcont, "ATA", 3) == 0);
>> }
>> 
>> +#ifdef __sparc__
>> +static void
>> +check_hba_identifiers (const char *sysfs_path, int *vendor, int *device_id)
>> +{
>> +  char *ed = strstr (sysfs_path, "host");
>> +  size_t path_size;
>> +  char *p, *path;
>> +  char buf[8];
>> +  int fd;
>> +
>> +  if (!ed)
>> +return;
>> +
>> +  p = xstrdup (sysfs_path);
>> +  ed = strstr (p, "host");
>> +
>> +  if (!ed)
>> +goto out;
> 
> In normal circumstances this will never ever fail.
> If you are OK I will drop this "if" before committing.

I put that in for the case if the xstrdup above can not allocate memory.  Then 
p will be null, the strstr will fail and then we should jump to out.


> 
> If there are no objections I will commit this patch in a week or so.

Thanks…

Is there some reason this patch is being held up too?

http://lists.gnu.org/archive/html/grub-devel/2017-05/msg00045.html

This is where things last left off:

http://lists.gnu.org/archive/html/grub-devel/2017-10/msg00046.html

We really need minimal GPT support in there for many of the follow on patches 
in my queue.




___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-02-07 Thread Daniel Kiper 
On Tue, Jan 30, 2018 at 08:49:48PM -0800, Eric Snowberg wrote:
> Fix the Open Firmware (OF) 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 

In general Reviewed-by: Daniel Kiper ...

Just a few comments below...

> ---
> V2:
>   - Requested coding style changes
> ---
>  grub-core/osdep/linux/ofpath.c |  148 
> +++-
>  1 files changed, 145 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
> index dce4e59..5369508 100644
> --- a/grub-core/osdep/linux/ofpath.c
> +++ b/grub-core/osdep/linux/ofpath.c
> @@ -38,6 +38,46 @@
>  #include 
>  #include 
>
> +#ifdef __sparc__

I have discussed this with Vladimir. It looks that this will not
work if you try to cross-install SPARC GRUB2 binary using e.g.
x86 grub-install. By default it should work. However, we will also
have other issues here, like lack of access to OF firmware/paths,
which make such configs unusable anyway. So, I would leave this patch
as is for time being. If somebody cares then he/she should fix it.

Anyway, I will add something like that into the commit message before 
committing.

> +typedef enum
> +  {
> +GRUB_OFPATH_SPARC_WWN_ADDR = 1,
> +GRUB_OFPATH_SPARC_TGT_LUN,
> +  } ofpath_sparc_addressing;
> +
> +struct ofpath_sparc_hba
> +{
> +  grub_uint32_t device_id;
> +  ofpath_sparc_addressing addressing;
> +};
> +
> +static struct ofpath_sparc_hba sparc_lsi_hba[] = {
> +  /* Rhea, Jasper 320, LSI53C1020/1030. */
> +  {0x30, GRUB_OFPATH_SPARC_TGT_LUN},
> +  /* SAS-1068E. */
> +  {0x50, GRUB_OFPATH_SPARC_TGT_LUN},
> +  /* SAS-1064E. */
> +  {0x56, GRUB_OFPATH_SPARC_TGT_LUN},
> +  /* Pandora SAS-1068E. */
> +  {0x58, GRUB_OFPATH_SPARC_TGT_LUN},
> +  /* Aspen, Invader, LSI SAS-3108. */
> +  {0x5d, GRUB_OFPATH_SPARC_TGT_LUN},
> +  /* Niwot, SAS 2108. */
> +  {0x79, GRUB_OFPATH_SPARC_TGT_LUN},
> +  /* Erie, Falcon, LSI SAS 2008. */
> +  {0x72, GRUB_OFPATH_SPARC_WWN_ADDR},
> +  /* LSI WarpDrive 6203. */
> +  {0x7e, GRUB_OFPATH_SPARC_WWN_ADDR},
> +  /* LSI SAS 2308. */
> +  {0x87, GRUB_OFPATH_SPARC_WWN_ADDR},
> +  /* LSI SAS 3008. */
> +  {0x97, GRUB_OFPATH_SPARC_WWN_ADDR},
> +  {0, 0}
> +};
> +
> +static const int LSI_VENDOR_ID = 0x1000;
> +#endif
> +
>  #ifdef OFPATH_STANDALONE
>  #define xmalloc malloc
>  void
> @@ -338,6 +378,67 @@ vendor_is_ATA(const char *path)
>return (memcmp(bufcont, "ATA", 3) == 0);
>  }
>
> +#ifdef __sparc__
> +static void
> +check_hba_identifiers (const char *sysfs_path, int *vendor, int *device_id)
> +{
> +  char *ed = strstr (sysfs_path, "host");
> +  size_t path_size;
> +  char *p, *path;
> +  char buf[8];
> +  int fd;
> +
> +  if (!ed)
> +return;
> +
> +  p = xstrdup (sysfs_path);
> +  ed = strstr (p, "host");
> +
> +  if (!ed)
> +goto out;

In normal circumstances this will never ever fail.
If you are OK I will drop this "if" before committing.

If there are no objections I will commit this patch in a week or so.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

2018-01-30 Thread Eric Snowberg 
Fix the Open Firmware (OF) 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 
---
V2:
  - Requested coding style changes
---
 grub-core/osdep/linux/ofpath.c |  148 +++-
 1 files changed, 145 insertions(+), 3 deletions(-)

diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
index dce4e59..5369508 100644
--- a/grub-core/osdep/linux/ofpath.c
+++ b/grub-core/osdep/linux/ofpath.c
@@ -38,6 +38,46 @@
 #include 
 #include 
 
+#ifdef __sparc__
+typedef enum
+  {
+GRUB_OFPATH_SPARC_WWN_ADDR = 1,
+GRUB_OFPATH_SPARC_TGT_LUN,
+  } ofpath_sparc_addressing;
+
+struct ofpath_sparc_hba
+{
+  grub_uint32_t device_id;
+  ofpath_sparc_addressing addressing;
+};
+
+static struct ofpath_sparc_hba sparc_lsi_hba[] = {
+  /* Rhea, Jasper 320, LSI53C1020/1030. */
+  {0x30, GRUB_OFPATH_SPARC_TGT_LUN},
+  /* SAS-1068E. */
+  {0x50, GRUB_OFPATH_SPARC_TGT_LUN},
+  /* SAS-1064E. */
+  {0x56, GRUB_OFPATH_SPARC_TGT_LUN},
+  /* Pandora SAS-1068E. */
+  {0x58, GRUB_OFPATH_SPARC_TGT_LUN},
+  /* Aspen, Invader, LSI SAS-3108. */
+  {0x5d, GRUB_OFPATH_SPARC_TGT_LUN},
+  /* Niwot, SAS 2108. */
+  {0x79, GRUB_OFPATH_SPARC_TGT_LUN},
+  /* Erie, Falcon, LSI SAS 2008. */
+  {0x72, GRUB_OFPATH_SPARC_WWN_ADDR},
+  /* LSI WarpDrive 6203. */
+  {0x7e, GRUB_OFPATH_SPARC_WWN_ADDR},
+  /* LSI SAS 2308. */
+  {0x87, GRUB_OFPATH_SPARC_WWN_ADDR},
+  /* LSI SAS 3008. */
+  {0x97, GRUB_OFPATH_SPARC_WWN_ADDR},
+  {0, 0}
+};
+
+static const int LSI_VENDOR_ID = 0x1000;
+#endif
+
 #ifdef OFPATH_STANDALONE
 #define xmalloc malloc
 void
@@ -338,6 +378,67 @@ vendor_is_ATA(const char *path)
   return (memcmp(bufcont, "ATA", 3) == 0);
 }
 
+#ifdef __sparc__
+static void
+check_hba_identifiers (const char *sysfs_path, int *vendor, int *device_id)
+{
+  char *ed = strstr (sysfs_path, "host");
+  size_t path_size;
+  char *p, *path;
+  char buf[8];
+  int fd;
+
+  if (!ed)
+return;
+
+  p = xstrdup (sysfs_path);
+  ed = strstr (p, "host");
+
+  if (!ed)
+goto out;
+
+  *ed = '\0';
+
+  path_size = (strlen (p) + sizeof ("vendor"));
+  path = xmalloc (path_size);
+
+  if (!path)
+goto out;
+
+  snprintf (path, path_size, "%svendor", p);
+  fd = open (path, O_RDONLY);
+
+  if (fd < 0)
+goto out;
+
+  memset (buf, 0, sizeof (buf));
+
+  if (read (fd, buf, sizeof (buf) - 1) < 0)
+goto out;
+
+  close (fd);
+  sscanf (buf, "%x", vendor);
+
+  snprintf (path, path_size, "%sdevice", p);
+  fd = open (path, O_RDONLY);
+
+  if (fd < 0)
+goto out;
+
+  memset (buf, 0, sizeof (buf));
+
+  if (read (fd, buf, sizeof (buf) - 1) < 0)
+goto out;
+
+  close (fd);
+  sscanf (buf, "%x", device_id);
+
+ out:
+  free (path);
+  free (p);
+}
+#endif
+
 static void
 check_sas (const char *sysfs_path, int *tgt, unsigned long int *sas_address)
 {
@@ -399,7 +500,7 @@ of_path_of_scsi(const char *sys_devname 
__attribute__((unused)), const char *dev
 {
   const char *p, *digit_string, *disk_name;
   int host, bus, tgt, lun;
-  unsigned long int sas_address;
+  unsigned long int sas_address = 0;
   char *sysfs_path, disk[MAX_DISK_CAT - sizeof ("/fp@0,0")];
   char *of_path;
 
@@ -416,9 +517,8 @@ of_path_of_scsi(const char *sys_devname 
__attribute__((unused)), const char *dev
 }
 
   of_path = find_obppath(sysfs_path);
-  free (sysfs_path);
   if (!of_path)
-return NULL;
+goto out;
 
   if (strstr (of_path, "qlc"))
 strcat (of_path, "/fp@0,0");
@@ -447,6 +547,44 @@ of_path_of_scsi(const char *sys_devname 
__attribute__((unused)), const char *dev
 }
   else
 {
+#ifdef __sparc__
+  ofpath_sparc_addressing addressing = GRUB_OFPATH_SPARC_TGT_LUN;
+  int vendor = 0, device_id = 0;
+  char *optr = disk;
+
+  check_hba_identifiers (sysfs_path, , _id);
+
+  if (vendor == LSI_VENDOR_ID)
+{
+  struct ofpath_sparc_hba *lsi_hba;
+
+  /* Over time different OF addressing schemes have been supported.
+ There is no generic addressing scheme that works across
+ every HBA. */
+  for (lsi_hba = sparc_lsi_hba; lsi_hba->device_id; lsi_hba++)
+if (lsi_hba->device_id == device_id)
+  {
+addressing = lsi_hba->addressing;
+break;
+  }
+}
+
+  if (addressing == GRUB_OFPATH_SPARC_WWN_ADDR)
+optr += snprintf (disk, sizeof (disk), "/%s@w%lx,%x", disk_name,
+  sas_address, lun);
+  else
+optr += snprintf (disk, sizeof (disk), "/%s@%x,%x", disk_name, tgt,
+  lun);
+
+  if (*digit_string != '\0')
+{
+  int part;
+
+  sscanf (digit_string, "%d", );
+  snprintf (optr, sizeof (disk) - (optr - disk - 1), ":%c", 'a'
+