From: Randy Dunlap <[email protected]>
sparse warns about incorrect type when using __be64 data.
It is not being converted to CPU-endian but it should be.
Fixes these sparse warnings:
../block/sed-opal.c:375:20: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:375:20: expected unsigned long long [usertype] align
../block/sed-opal.c:375:20: got restricted __be64 const [usertype] alignment_granularity
../block/sed-opal.c:376:25: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:376:25: expected unsigned long long [usertype] lowest_lba
../block/sed-opal.c:376:25: got restricted __be64 const [usertype] lowest_aligned_lba
Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Scott Bauer <[email protected]>
Cc: Rafael Antognolli <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: [email protected]
---
If this code is known to work as is, it would be nice to have an
explanation of it. Oh: maybe it's just that these fields are not
used after they are saved/set.
block/sed-opal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- lnx-54-rc1.orig/block/sed-opal.c
+++ lnx-54-rc1/block/sed-opal.c
@@ -372,8 +372,8 @@ static void check_geometry(struct opal_d
{
const struct d0_geometry_features *geo = data;
- dev->align = geo->alignment_granularity;
- dev->lowest_lba = geo->lowest_aligned_lba;
+ dev->align = be64_to_cpu(geo->alignment_granularity);
+ dev->lowest_lba = be64_to_cpu(geo->lowest_aligned_lba);
}
static int execute_step(struct opal_dev *dev,
On Wed, Oct 02, 2019 at 07:23:15PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> sparse warns about incorrect type when using __be64 data.
> It is not being converted to CPU-endian but it should be.
>
> Fixes these sparse warnings:
>
> ../block/sed-opal.c:375:20: warning: incorrect type in assignment (different base types)
> ../block/sed-opal.c:375:20: expected unsigned long long [usertype] align
> ../block/sed-opal.c:375:20: got restricted __be64 const [usertype] alignment_granularity
> ../block/sed-opal.c:376:25: warning: incorrect type in assignment (different base types)
> ../block/sed-opal.c:376:25: expected unsigned long long [usertype] lowest_lba
> ../block/sed-opal.c:376:25: got restricted __be64 const [usertype] lowest_aligned_lba
>
> Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Scott Bauer <[email protected]>
> Cc: Rafael Antognolli <[email protected]>
> Cc: Jens Axboe <[email protected]>
> Cc: [email protected]
+ Jon and Revanth,
These look fine. They're currently unused, but may be useful in the future for sysfs or what ever else we add in.
On Thu, 2019-10-03 at 11:40 -0400, Scott Bauer wrote:
> On Wed, Oct 02, 2019 at 07:23:15PM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <[email protected]>
> >
> > sparse warns about incorrect type when using __be64 data.
> > It is not being converted to CPU-endian but it should be.
> >
> > Fixes these sparse warnings:
> >
> > ../block/sed-opal.c:375:20: warning: incorrect type in assignment (different base types)
> > ../block/sed-opal.c:375:20: expected unsigned long long [usertype] align
> > ../block/sed-opal.c:375:20: got restricted __be64 const [usertype] alignment_granularity
> > ../block/sed-opal.c:376:25: warning: incorrect type in assignment (different base types)
> > ../block/sed-opal.c:376:25: expected unsigned long long [usertype] lowest_lba
> > ../block/sed-opal.c:376:25: got restricted __be64 const [usertype] lowest_aligned_lba
> >
> > Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
> > Signed-off-by: Randy Dunlap <[email protected]>
> > Cc: Scott Bauer <[email protected]>
> > Cc: Rafael Antognolli <[email protected]>
> > Cc: Jens Axboe <[email protected]>
> > Cc: [email protected]
>
> + Jon and Revanth,
>
>
> These look fine. They're currently unused, but may be useful in the future for sysfs or what ever else we add in.
I imagine modern devices with logical/physical indirection would
probably report gran=1 and lowest=0 regardless.
Either way,
Reviewed-by: Jon Derrick <[email protected]>