The majority of our targets provide a default value for the variable
SUPPORTED_DEVICES, which is used in images to check against the
compatible on a running device:
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
At the moment, this is implemented in the Device/Default block of
the individual targets or even subtargets. However, since we
standardized device names and compatible in the recent past, almost
all targets are following the same scheme now:
device/image name: vendor_model
compatible: vendor,model
The equal redundant definitions are a symptom of this process.
Consequently, this patch moves the definition to image.mk making it
a global default. For the few targets not using the scheme above,
SUPPORTED_DEVICES will be defined to a different value in
Device/Default anyway, overwriting the default. In other words:
This change is supposed to be cosmetic.
This can be used as a global measure to get the current compatible
with: $(firstword $(SUPPORTED_DEVICES))
(Though this is not precisely an achievement of this commit.)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Signed-off-by: CN_SZTL <cnsztl@project-openwrt.eu.org>
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>
