This fixes a regression after a kernel change in 5.4.69 [1] that
led to build failure on oxnas/ox820:
drivers/ata/sata_oxnas.c:2238:13: error: initialization of
'enum ata_completion_errors (*)(struct ata_queued_cmd *)'
from incompatible pointer type
'void (*)(struct ata_queued_cmd *)' [-Werror=incompatible-pointer-types]
.qc_prep = sata_oxnas_qc_prep,
^~~~~~~~~~~~~~~~~~
drivers/ata/sata_oxnas.c:2238:13: note:
(near initialization for 'sata_oxnas_ops.qc_prep')
Our local driver is changed the same way as prototyped in the
kernel patch, i.e. return type is changed and AC_ERR_OK return
value is added.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e11c83520cd04b813cd1748ee2a8f2c620e5f7e3
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
SPDX moved from GPL-2.0 to GPL-2.0-only and from GPL-2.0+ to
GPL-2.0-or-later. Reflect that in the SPDX license headers.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
After years of trying to find the reason for random kernel crashes
while both CPU and SATA are under load it has been found.
Some odd commented-out #defines in kref's single-port driver [1] which
were copied from the vendor driver made me develop a theory:
The IO-mapped memory area for DMA descriptors apparetly got some holes
just before the alignment boundaries.
This feels like an off-by-one bug in the hardware or maybe those fields
are used internally by the SATA controller's firmware.
Whatever the cause is: they cannot be used and trying to use them
results in reading back unexpected stuff and ends up with oopsing
Unable to handle kernel paging request at virtual address d085c004
Work around the issue by reducing the area used for bmdma descriptors.
This reduces SATA performance (iops) quite a bit, but finally makes
things work reliably. Possibly one could optimize this much more by
really just skipping the holes in that memory area -- however, that
seems to be non-trivial with the driver and libata in it's current form
(suggestions are welcome).
The 'proper' way to have good SATA performance would be to make use of
the hardware RAID features (one can use the JBOD mode to access even
just a single disc transparently through the RAID controller integrated
in the SATA host instead of accessing the SATA ports 'raw' as we do
now).
[1]: https://github.com/kref/linux-oxnas/blob/master/drivers/ata/sata_oxnas.c#L25
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
