add physical_block_size field where applicable

only scsi_disk checks the actual value, other drivers take the logical block size.

This change reports the physical block size from the disk rather than the block
size used by IDE/SATA/SCSI commands. On typical modern SATA disks, the SATA
commands will use 512 byte blocks, but the disk will actually read and write
4K blocks internally. This is only of importance for partition alignment for DriveSetup,
and is independant of file systems or partitioning systems. This could also influence
the recommended block size for some file systems.

Change-Id: Id0f2e22659e89fcef64c1f8d04f81cd68995e01f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5667
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

Improve SCSI and SATA trim support

Fixes:
* scsi: Fix a bug that caused the device capacity to be set
to an undefined value for some large SCSI devices when
READ CAPACITY (16) was used
* ahci: Fix VPD page reporting so that it does not return
undefined values
* ahci: Set the write bit to true when sending a DATA SET
MANAGEMENT (trim) command to a device. The command would
otherwise fail and time out on some devices.

Improvements:
* scsi: Extend the READ CAPACITY (16) support to also
include logical block provisioning information
* scsi: Prefer READ CAPACITY (16) over READ CAPACITY (10)
on devices that are expected to support this command
* scsi, ahci: Enable trim on SCSI and SATA devices that
are expected to support trim and which correctly report
trim support
* ahci: Redo the implementation of the SCSI UNMAP command
* scsi: Redo UNMAP-related code
* scsi: Add support for UNMAP via WRITE SAME (10) and
WRITE SAME (16) commands
* When copying trim ranges between different data types,
make sure that the values don't change (detect overflows)
* Report the number of trimmed blocks even if the trim
operation fails

Change-Id: Ie5fc993bbbc19546b4308138ba10184bf7b9986a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4157
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

scsi_periph: use synchronous command.

* The call waited anyway, so there is no reason to make it async.

scsi_periph: fixed copy&paste error in periph_trim_device().

trim: Target SCSI UNMAP command instead of WRITE SAME.

* The UNMAP command is theoretically much faster, as it can get many block
ranges instead of just a single range.
* Furthermore, the ATA TRIM command resembles it much better.
* Therefore, fs_trim_data now gets an array of ranges, and we use SCSI UNMAP
to trim.
* Updated BFS code to collect array ranges to fully support the new
fs_trim_data possibilities.

This gets the trim command as WRITE SAME operation to SCSI

* Neither hardware nor driver to test it; AHCI/IDE support is next
on the table.

Various 64-bit fixes to SCSI and ATA bus managers/drivers.

Mostly compilation fixes, as well as a few 64-bit safety fixes. I've
briefly looked through everything for any obvious issues and fixed
the ones I've found, and it seems like they're working properly, though
there could be some more well hidden ones that I've missed.

* Removed *_BEN() macros.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40222 a95241bf-73f2-0310-859d-f6bbb57e9c96

big_endian conversion: this should be more correct


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39279 a95241bf-73f2-0310-859d-f6bbb57e9c96

style fix (pointed out by Axel)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39261 a95241bf-73f2-0310-859d-f6bbb57e9c96

* ata: added ATADevice::ReadCapacity16()
* ata: don't fail if lba_sector_count is null and lba48_sector_count is not
* scsi_periph: if ReadCapacity() returns 0xffffffff, use ReadCapacity16() instead
* scsi_disk: use a different computation in the struct geometry computation for bigger disks
Tested successfully with a virtual 10TB hard drive.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39252 a95241bf-73f2-0310-859d-f6bbb57e9c96

* First baby steps in letting our drivers use the new I/O request/scheduler
architecture: for now, we do this on the lowest layer only, therefore all
requests are handled synchronously (ie. in the scheduler's thread).
* Instead of using the block_io module, scsi_disk (and scsi_cd) are now
exporting a device on their own, and use an I/O scheduler with an appropriate
DMA resource.
* There are still lots of TODOs, and it can easily panic - don't update if
you intend to demo Haiku.
* scsi_periph now only has an io() function that get an io_operation, instead
of the previous read/write functions, moved preferred CCB size from those
functions into the device registration.
* Changed all scsi_periph files to C++.
* scsi_cd ported, too, but untested.
* Removed block_io from image - it will be removed completely soon.
* Temporarily commented an ASSERT() in the ATA bus manager (in case you use
it); it's sometimes triggered by the code now, and I haven't yet looked into
the issue -- doesn't seem to harm, at least.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26828 a95241bf-73f2-0310-859d-f6bbb57e9c96

scsi_periph: use synchronous command.

* The call waited anyway, so there is no reason to make it async.

scsi_periph: fixed copy&paste error in periph_trim_device().

trim: Target SCSI UNMAP command instead of WRITE SAME.

* The UNMAP command is theoretically much faster, as it can get many block
ranges instead of just a single range.
* Furthermore, the ATA TRIM command resembles it much better.
* Therefore, fs_trim_data now gets an array of ranges, and we use SCSI UNMAP
to trim.
* Updated BFS code to collect array ranges to fully support the new
fs_trim_data possibilities.

This gets the trim command as WRITE SAME operation to SCSI

* Neither hardware nor driver to test it; AHCI/IDE support is next
on the table.

Various 64-bit fixes to SCSI and ATA bus managers/drivers.

Mostly compilation fixes, as well as a few 64-bit safety fixes. I've
briefly looked through everything for any obvious issues and fixed
the ones I've found, and it seems like they're working properly, though
there could be some more well hidden ones that I've missed.

* Removed *_BEN() macros.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40222 a95241bf-73f2-0310-859d-f6bbb57e9c96

big_endian conversion: this should be more correct


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39279 a95241bf-73f2-0310-859d-f6bbb57e9c96

style fix (pointed out by Axel)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39261 a95241bf-73f2-0310-859d-f6bbb57e9c96

* ata: added ATADevice::ReadCapacity16()
* ata: don't fail if lba_sector_count is null and lba48_sector_count is not
* scsi_periph: if ReadCapacity() returns 0xffffffff, use ReadCapacity16() instead
* scsi_disk: use a different computation in the struct geometry computation for bigger disks
Tested successfully with a virtual 10TB hard drive.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39252 a95241bf-73f2-0310-859d-f6bbb57e9c96

* First baby steps in letting our drivers use the new I/O request/scheduler
architecture: for now, we do this on the lowest layer only, therefore all
requests are handled synchronously (ie. in the scheduler's thread).
* Instead of using the block_io module, scsi_disk (and scsi_cd) are now
exporting a device on their own, and use an I/O scheduler with an appropriate
DMA resource.
* There are still lots of TODOs, and it can easily panic - don't update if
you intend to demo Haiku.
* scsi_periph now only has an io() function that get an io_operation, instead
of the previous read/write functions, moved preferred CCB size from those
functions into the device registration.
* Changed all scsi_periph files to C++.
* scsi_cd ported, too, but untested.
* Removed block_io from image - it will be removed completely soon.
* Temporarily commented an ASSERT() in the ATA bus manager (in case you use
it); it's sometimes triggered by the code now, and I haven't yet looked into
the issue -- doesn't seem to harm, at least.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26828 a95241bf-73f2-0310-859d-f6bbb57e9c96