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>
* install kmod-hwmon-drivetemp by default
* wire up thermal zone
* fix fan GPIO polarity
* fix i2c-gpio GPIO_OPEN_DRAIN
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
drivers/ata/sata_oxnas.c: In function 'sata_oxnas_port_irq':
drivers/ata/sata_oxnas.c:2126:25: warning: left shift count >= width of type [-Wshift-count-overflow]
if (ap->qc_active & (1 << ATA_TAG_INTERNAL)) {
^~
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Pogoplug V3/Pro has an interanl SATA port. To use it, DTS sata node should be
enabled, and kmod-ata-oxnas-sata package needs to be installed.
Fixes: FS#2542
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Run-tested 5.4 on Shuttle KD20 for some days now, everything seems
fine so far. Let's have snapshot builds based on 5.4.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add 5.4 kernel version as a new testing kernel option.
Run-tested on Shuttle KD20, seems to work just as well as kernel 4.14.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Move PCIe controller outside down to SoC level to avoid resource
mapping problems.
Also add more detailed error handling when mapping registers.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Refactor pcie-oxnas to have shared resources in syscon and new pcie-phy
driver. Hopefully this revives PCIe...
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add port handles for both USB 2.0 ports so they can be used as
trigger-source for USB LEDs.
Suggestions for pogoplug and akitio,mycloud devices are welcome.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
add kernel and other missing NAND flash partitions to allow booting
using stock loader instead of the 2nd-stage bootloader.
This will ease installation from stock firmware on pogoplugs as well
as stg212 aka. medion nas.
Existing users of OpenWrt on those boards will have to boot initramfs
generated after this commit and subsequently flash first the ubinized
image, then again run initramfs to flash sysupgrade.tar image, and
then restore bootcmd in U-Boot environment back to the original setting
('nboot 60500000 0 440000' or something like that) instead of jumping
into the now no longer used 2nd-stage loader.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
- fix single spaces hidden by a tab
- replace indentation with spaces by tabs
- make empty lines empty
- drop trailing whitespace
- drop unnecessary blank lines
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Paul Wassi <p.wassi@gmx.at>
Reboot the oxnas target based on Linux 4.14 by rebasing our support on
top of the now-existing upstream kernel support.
This commit brings oxnas support to the level of v4.17 having upstream
drivers for Ethernet, Serial and NAND flash.
Botch up OpenWrt's local drivers for EHCI, SATA and PCIe based on the
new platform code and device-tree.
Re-introduce base-files from old oxnas target which works for now but
needs further clean-up towards generic board support.
Functional issues:
* PCIe won't come up (hence no USB3 on Shuttle KD20)
* I2C bus of Akitio myCloud device is likely not to work (missing
debounce support in new pinctrl driver)
Code-style issues:
* plla/pllb needs further cleanup -- currently their users or writing
into the syscon regmap after acquireling the clk instead of using
defined clk_*_*() functions to setup multipliers and dividors.
* PCIe phy needs its own little driver.
* SATA driver is a monster and should be split into an mfd having
a raidctrl regmap, sata controller, sata ports and sata phy.
Tested on MitraStar STG-212 aka. Medion Akoya MD86xxx and Shuttle KD20.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This commit introduced a syntax error in ox820-akitio.dts which is
fixed now:
commit 5cde94d9ab
Author: Daniel Golle <daniel@makrotopia.org>
Date: Sat Sep 24 01:14:53 2016 +0200
oxnas: backport upstream NAND driver
This caused the folowing error message in the build bot:
Error: arch/arm/boot/dts/ox820-akitio.dts:146.3-147.1 syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:293: recipe for target 'arch/arm/boot/dts/ox820-akitio.dtb' failed
make[5]: *** [arch/arm/boot/dts/ox820-akitio.dtb] Error 1
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
All compiled device tree files not mentioned are binary identical to the
former ones.
Fix the obvious decimal/hex confusion for the power key of ramips/M2M.dts.
Due to the include of the input binding header, the BTN_* node names in:
- ramips/GL-MT300A.dts
- ramips/GL-MT300N.dts
- ramips/GL-MT750.dts
- ramips/Timecloud.dts
will be changed by the compiler to the numerical equivalent.
Move the binding include of lantiq boards to the file where they are
used the first time to hint the user where the values do come from.
Signed-off-by: Mathias Kresin <dev@kresin.me>
A bug resulting in the NAND not being detected by newer kernels has
kept me sleepless for months and yet I wasn't able to discover the
cause.
Bring back patches and files for 4.1 until this has been resolved.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
A missing semicolon in the gpio-keys-polled section of ox820-akitio.dts
caused the build to break. Add it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 49219
Make mach-oxnas/hotplug.c look more similar to mach-realview/hotplug.c,
just cosmetics and maintainability concerns, no functional changes.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 49044
