Add kmod packages to support accessing the fTPM (in-firmware TPM) which
can be implemented in the boot firmware of most modern platforms.
- kmod-optee: Open Portable Trusted Execution Environment
- kmod-optee-rng: OP-TEE random number generator client
- kmod-rtc-optee: OP-TEE real-time clock client
- kmod-scmi-transport-optee: SCMI OP-TEE transport
- kmod-tee: Generic Trusted Execution Environment
- kmod-tee-stmm-efi: EFI variable service Trusted Application
- kmod-tpm-ftpm-tee: Microsoft fTPM Trusted Application
Using the TPM 2.0 can be useful for various security applications,
such as encrypting on-disk credentials. OP-TEE itself alone is also
useful as it can provide a PKCS#11 token for authentication (eg. to
connect to a VPN) and significantly lower the risk of leaking secrets
used for authentication. Also, on some platforms RNG and RTC can only be
accessed via OP-TEE, and some ARM SystemReady platforms require EFI
variables to be access via a TA.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Upstream has marked it as BROKEN. Quote:
This driver is harmful:
- It is much slower than the CPU.
- It Has a history of bugs.
- It does not have exclusive access to the hardware, causing races
with the secure world.
- It register its implementations with too low a cra_priority for them
to be actually used.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24326
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Align the USXGMII configuration sequence with the vendor SSDK:
- Reset the PCS PLL by programming the whole reset register with the
documented assert and release values and 100ms holds, instead of
toggling a single bit for 1ms and relying on the power-on state of
the remaining analog enables.
- Keep the uniphy port clocks disabled across the reconfiguration and
re-enable them after calibration, before releasing the XPCS reset.
- Select in-band link detection explicitly rather than the SFP
loss-of-signal input, which does not exist on non-SFP ports.
- Wait for the 10GBASE-R receiver to link before enabling the USXGMII
adaptation layer. Best-effort, since the PHY SerDes may only come
up later.
Other interface modes keep the previous behaviour.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The MISC2 phy mode field is modelled as two bits at the wrong offset:
the hardware field is three bits wide and starts one bit lower. The
SGMII and 2500BASE-X values only come out right because the power-on
default happens to keep the missed bit set, and USXGMII is not
programmed at all, leaving the uniphy in its power-on SGMII
personality.
Model the field at its documented position, add the USXGMII mode
value and write the rate field explicitly instead of relying on its
power-on default, matching the values the vendor SSDK programs.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The uniphy never receives a software reset pulse during interface mode
configuration. The vendor SSDK asserts the GCC system reset and the
NSSCC soft reset together for 100ms on every uniphy mode change;
without the pulse, parts of the uniphy analog block can remain in
their power-on state.
Pulse both resets, when the devicetree provides them, after the mode
is programmed. Both resets are optional so existing devicetrees keep
working.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
Some board designs feed an external PHY its reference clock from the
uniphy 25MHz clock output instead of a local crystal. Enable the
output when the devicetree opts in with "qcom,uniphy-clkout-25mhz".
The clock output register only becomes writable once the PLL reset
and calibration have completed, so program it at the end of the mode
configuration rather than at probe time.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The XPCS signals USXGMII in-band autonegotiation completion through an
interrupt that is never enabled, waited for or acknowledged, so rate
adaptation never starts and the MAC receives nothing even though the
SerDes achieves block lock. The advertised speed and duplex are also
left at their reset values while autonegotiation runs.
Follow the vendor SSDK sequence: enable the completion interrupt and
advertise 10G/full duplex when configuring the PCS, and on link-up
restart the in-band autonegotiation, wait for completion and
acknowledge it before programming the negotiated speed. The wait is
best-effort, as in the vendor driver.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
Each uniphy has, besides the XPCS reset, a system reset in the GCC and
a soft reset in the NSSCC. The vendor driver pulses both on every
interface mode change as part of the uniphy bring-up. Describe them,
and name the resets while at it, so the PCS driver can pick them up.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/24033
Signed-off-by: Robert Marko <robimarko@gmail.com>
The firmware loading does not depend (solely) on the PHY id. The driver
needs to read out the vendor version id of the PHY before it can decide
which firmware file needs to be loaded.
A split in an RTL8261N and an RTL8264B firmware package is therefore
misleading. And it could even be that a product ships an RTL8264B but
switches the revision of the chip in the middle of its product lifetime. In
this case, the first identification based on the chip ID or the actual chip
ID for the OpenWrt porter might fail for another user with a later/earlier
produced device.
Shipping both files in the same package avoids this problem. Only the "low
power" firmware package is slightly misleading because there is only a
RTL8261N firmware binary for low power but no corresponding RTL8264B
version. It will ship simply the non-low power version for RTL8264B.
Suggested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23947
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move the QCA8084 XPCS channel lookup fix into the SerDes speed config
patch, so qca8084_qxgmii_set_speed() walks the channel table with the
loop index from the start.
Move the PPE port reset loop fix into the PPE driver update patch, so
ppe_port_mac_reset() asserts and deasserts each reset control instead of
reusing the MAC reset for every iteration.
Signed-off-by: Igor Kravchenko <igor.kravchenko05@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23900
Signed-off-by: Robert Marko <robimarko@gmail.com>
Switch the qualcommbe target to use kernel 6.18 and drop 6.12.
Kernel 6.18 for qualcommbe resolves some issues regarding
PCS support and reduces maintenance load maintaining two
kernel branches.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/23908
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
During testing on the Askey SBE1V1K, it was noticed that only very low
PWM frequencies would work, and 100% duty cycles also did not work.
Comparing the proposed upstream pwm-ipq driver to the downstream vendor
driver, `ipq_pwm_apply()` fixed pwm_div at its maximum and derived only
pre_div from the requested period. Since the period spans
`(pre_div + 1) * (pwm_div + 1)` input clocks, pinning pwm_div near its
maximum forces pre_div towards zero for short periods: once pre_div
rounds to 0 the shortest representable period is
`(pwm_div + 1) / clk_rate` (~2.7 ms, i.e. ~366 Hz, at a 24 MHz clock),
and any shorter request is silently stretched to that. The high
duration then truncates to 0, so the output collapses to ~0% duty.
Since 4-wire fans commonly expect a ~25kHz PWM, it was effectively
unusable, since every duty cycle programs a ~zero high time.
Search for the (pre_div, pwm_div) pair whose period best approximates
the request instead of fixing pwm_div. Starting pre_div at the smallest
value that keeps pwm_div within its field and stopping once pre_div
exceeds pwm_div bounds the loop and keeps pwm_div as large as possible
for fine duty resolution. For a 25 kHz request at 24 MHz this selects
pre_div = 0, pwm_div = 959, giving full 0..960 duty resolution.
While reworking the high-duration computation, round it to nearest
rather than truncating, so mid-range duty cycles are not biased low, and
clamp it to pwm_div + 1. Rounding, or a 100% duty request, could
otherwise push hi_dur past the period length and overflow the 16-bit
HI_DURATION field.
Also compute hi_div in `get_state()` in 64-bit; `hi_dur * (pre_div + 1)`
can exceed 32 bits before the existing promotion.
Fixes: 01fb4a6daa ("qualcommbe: update pwm patches and add missing symbol")
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/23916
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A step towards removing hack/420-mtd-support-OpenWrt-s-MTD_ROOTFS_ROOT_DEV.patch
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20951
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Since 6.18 RTL8261N support was added to the generic Realtek PHY driver
and was dropped from the downstream driver.
So, fix the missing RTL8261N support by including the Realtek PHY kmod
and the relevant firmware.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Lets refresh the config as generic config was wastly updated, and we
need the CONFIG_PAGE_BLOCK_MAX_ORDER to be defined.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
The 6.18 kernel port and PWM patches were developed independently. the
initial 6.18 port did not include the PWM patches, so add them now.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that everything is in place for kernel 6.18, enable it as a
testing kernel for qualcommbe.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Generate new patches for 6.18 from my ipq95xx development branch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
I generate patches form git, so maintaining an old numbering scheme
does not integrate well with my workflow. renumber the pacthes here so
that the commit shows only the changes to the patches.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove patches that are upstream in v6.18, but were not identified as
upstreamed in the patch naming.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Create the config and relevant patches for 6.18 from 6.12. The
"standard" openwrt devel process seems to be to move the files and
restore the old ones. I find this process confusing, and I don't see
any git benefits for doing things this way. So just copy the files.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
The lastest ethernet PPE driver, uses "mac", "rx", and "tx", without
the "port_" prefix for the port clocks and resets. The PPE ports are
declared by the device dts. In order to support v6.12 and v6.18
kernels simultaneously, update the kernel patches and kiwi-dvk
devicetree to use the newer naming scheme.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
This symbol is selected by CONFIG_BPF, which was already enabled
on generic config-6.12.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/22730
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
CONFIG_REGULATOR_QCOM_LABIBB is being disabled by targets manually, so
instead lets disable it in generic config.
Signed-off-by: Robert Marko <robimarko@gmail.com>
CONFIG_REGULATOR_QCOM_USB_VBUS showed up on Layerscape recently, and it
looks like multiple targets disable it manually, so simply disable it in
generic configuration instead.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add missing CONFIG_LEDS_QCOM_LPG symbol.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22096
Signed-off-by: Robert Marko <robimarko@gmail.com>
Commit 041ef9648d ("qualcommbe: move Device DTS to dedicated DTS
directory") introduced a dedicated DTS directory and set DEVICE_DTS_DIR
to ../dts as default. This broke the rdp433 device build since its DTS
resides in the kernel tree (applied via patches), not in the target dts
directory.
Fix this by overriding DEVICE_DTS_DIR for rdp433 to point to the kernel
DTS directory.
Fixes: 041ef9648d ("qualcommbe: move Device DTS to dedicated DTS directory")
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22096
Signed-off-by: Robert Marko <robimarko@gmail.com>
Align the qualcommbe target to the pattern already used on other devices where
the device DTS are placed in a dedicated directory separate from the files
directory.
This, while trying to enforce a common pattern for every target, also permits to
do modification to device DTS without having to trigger a recompilation of the
entire kernel (as the files directory is not touched)
Link: https://github.com/openwrt/openwrt/pull/22038
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add the flag required to enforce the fwtool's image metadata checks.
All sysupgrade image recipes on this platform already append the metadata.
Fixes: 93173aee96 ("qualcommbe: ipq95xx: Add initial support for new target")
Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/22010
Signed-off-by: Robert Marko <robimarko@gmail.com>
Update PWM patch set to v20 which resolves some bugs related to the
duty cycle / frequency calculation; and add missing config symbol
CONFIG_PWM.
Fixes: #21727
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/21889
Signed-off-by: Robert Marko <robimarko@gmail.com>
This adds the pending upstream patches for platform PWM support for qualcommbe
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/21727
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport a bunch of upstream commits simplifying the RealTek PHY driver
and re-unifying the C22 and C45 driver instances.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Commit ab805ec316 ("generic: add missing squashfs config") enabled
CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU in the generic config, so it is no
longer needed in the target configs.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Link: https://github.com/openwrt/openwrt/pull/21465
Signed-off-by: Robert Marko <robimarko@gmail.com>
Update the ipq9574 PCS driver the version provided by Qualcomm via
github. The updated driver simplifies link up handling by removing
unnecessary clock rate changes.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20993
Signed-off-by: Robert Marko <robimarko@gmail.com>
According to Qualcomm developers, the pcs nodes on IPQ9574 will be
labeled "pcs<n>" and "pcs<n>_ch<m>". The proposed IPQ5424 changes
include the simpler labels. Rename the IPQ95xx nodes for consistency.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20993
Signed-off-by: Robert Marko <robimarko@gmail.com>
ipq_unipcs_create/destroy() are provided by an older version of the
IPQ9574 PCS driver. Use the renamed versions ipq_pcs_get/put() to
allow updating the PCS driver.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20993
Signed-off-by: Robert Marko <robimarko@gmail.com>
