From: Ard Biesheuvel <ardb(a)kernel.org>
Currently, LPA2 kernel support implies support for up to 52 bits of
physical addressing, and this is reflected in global definitions such as
PHYS_MASK_SHIFT and MAX_PHYSMEM_BITS.
This is potentially problematic, given that LPA2 hardware support is
modeled as a CPU feature which can be overridden, and with LPA2 hardware
support turned off, attempting to map physical regions with address bits
[51:48] set (which may exist on LPA2 capable systems booting with
arm64.nolva) will result in corrupted mappings with a truncated output
address and bogus shareability attributes.
This means that the accepted physical address range in the mapping
routines should be at most 48 bits wide when LPA2 support is configured
but not enabled at runtime.
Fixes: 352b0395b505 ("arm64: Enable 52-bit virtual addressing for 4k and 16k granule configs")
Cc: <stable(a)vger.kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com>
Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
---
arch/arm64/include/asm/pgtable-hwdef.h | 6 ------
arch/arm64/include/asm/pgtable-prot.h | 7 +++++++
arch/arm64/include/asm/sparsemem.h | 4 +++-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index c78a988cca93..a9136cc551cc 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -222,12 +222,6 @@
*/
#define S1_TABLE_AP (_AT(pmdval_t, 3) << 61)
-/*
- * Highest possible physical address supported.
- */
-#define PHYS_MASK_SHIFT (CONFIG_ARM64_PA_BITS)
-#define PHYS_MASK ((UL(1) << PHYS_MASK_SHIFT) - 1)
-
#define TTBR_CNP_BIT (UL(1) << 0)
/*
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 9f9cf13bbd95..a95f1f77bb39 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -81,6 +81,7 @@ extern unsigned long prot_ns_shared;
#define lpa2_is_enabled() false
#define PTE_MAYBE_SHARED PTE_SHARED
#define PMD_MAYBE_SHARED PMD_SECT_S
+#define PHYS_MASK_SHIFT (CONFIG_ARM64_PA_BITS)
#else
static inline bool __pure lpa2_is_enabled(void)
{
@@ -89,8 +90,14 @@ static inline bool __pure lpa2_is_enabled(void)
#define PTE_MAYBE_SHARED (lpa2_is_enabled() ? 0 : PTE_SHARED)
#define PMD_MAYBE_SHARED (lpa2_is_enabled() ? 0 : PMD_SECT_S)
+#define PHYS_MASK_SHIFT (lpa2_is_enabled() ? CONFIG_ARM64_PA_BITS : 48)
#endif
+/*
+ * Highest possible physical address supported.
+ */
+#define PHYS_MASK ((UL(1) << PHYS_MASK_SHIFT) - 1)
+
/*
* If we have userspace only BTI we don't want to mark kernel pages
* guarded even if the system does support BTI.
diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h
index 8a8acc220371..035e0ca74e88 100644
--- a/arch/arm64/include/asm/sparsemem.h
+++ b/arch/arm64/include/asm/sparsemem.h
@@ -5,7 +5,9 @@
#ifndef __ASM_SPARSEMEM_H
#define __ASM_SPARSEMEM_H
-#define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS
+#include <asm/pgtable-prot.h>
+
+#define MAX_PHYSMEM_BITS PHYS_MASK_SHIFT
/*
* Section size must be at least 512MB for 64K base
--
2.47.0.338.g60cca15819-goog
On Mon, Dec 09 2024 at 06:32, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
> commit 57103d282a874ed716f489b7b336b8d833ba43b2
> Author: Thomas Gleixner <tglx(a)linutronix.de>
> Date: Wed Sep 11 15:17:43 2024 +0200
>
> ntp: Introduce struct ntp_data
>
> [ Upstream commit 68f66f97c5689825012877f58df65964056d4b5d ]
>
> All NTP data is held in static variables. That prevents the NTP code from
> being reuasble for non-system time timekeepers, e.g. per PTP clock
> timekeeping.
>
> Introduce struct ntp_data and move tick_usec into it for a start.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Signed-off-by: Anna-Maria Behnsen <anna-maria(a)linutronix.de>
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Acked-by: John Stultz <jstultz(a)google.com>
> Link: https://lore.kernel.org/all/20240911-devel-anna-maria-b4-timers-ptp-ntp-v1-…
> Stable-dep-of: f5807b0606da ("ntp: Remove invalid cast in time offset math")
I sent a backport of this change, which is a one liner:
https://lore.kernel.org/stable/878qssr16f.ffs@tglx/
There is no point to backport the whole data struct change series for
that.
Thanks,
tglx
File-scope "__pmic_glink_lock" mutex protects the file-scope
"__pmic_glink", thus reference to it should be obtained under the lock,
just like pmic_glink_rpmsg_remove() is doing. Otherwise we have a race
during if PMIC GLINK device removal: the pmic_glink_rpmsg_probe()
function could store local reference before mutex in driver removal is
acquired.
Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
---
Changes in v3:
1. None
Changes in v2:
1. None
---
drivers/soc/qcom/pmic_glink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c
index caf3f63d940e..11e88053cc11 100644
--- a/drivers/soc/qcom/pmic_glink.c
+++ b/drivers/soc/qcom/pmic_glink.c
@@ -236,10 +236,11 @@ static void pmic_glink_pdr_callback(int state, char *svc_path, void *priv)
static int pmic_glink_rpmsg_probe(struct rpmsg_device *rpdev)
{
- struct pmic_glink *pg = __pmic_glink;
+ struct pmic_glink *pg;
int ret = 0;
mutex_lock(&__pmic_glink_lock);
+ pg = __pmic_glink;
if (!pg) {
ret = dev_err_probe(&rpdev->dev, -ENODEV, "no pmic_glink device to attach to\n");
goto out_unlock;
--
2.43.0
During mass manufacturing, we noticed the mmc_rx_crc_error counter,
as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase
above zero during nuttcp speedtests. Most of the time, this did not
affect the achieved speed, but it prompted this investigation.
Cycling through the rx_delay range on six boards (see table below) of
various ages shows that there is a large good region from 0x12 to 0x35
where we see zero crc errors on all tested boards.
The old rx_delay value (0x10) seems to have always been on the edge for
the KSZ9031RNX that is usually placed on Puma.
Choose "rx_delay = 0x23" to put us smack in the middle of the good
region. This works fine as well with the KSZ9131RNX PHY that was used
for a small number of boards during the COVID chip shortages.
Board S/N PHY rx_delay good region
--------- --- --------------------
Puma TT0069903 KSZ9031RNX 0x11 0x35
Puma TT0157733 KSZ9031RNX 0x11 0x35
Puma TT0681551 KSZ9031RNX 0x12 0x37
Puma TT0681156 KSZ9031RNX 0x10 0x38
Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017)
Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards)
Intersection of good regions = 0x12 0x35
Middle of good region = 0x23
Relates-to: PUMA-111
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Cc: <stable(a)vger.kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz(a)cherry.de>
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher(a)cherry.de>
---
v3: use rx_delay = 0x23 instead of 0x11, which was not enough.
v2: cc stable, add "Fixes:", add omitted "there" to commit msg,
add Reviewed-by.
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 9efcdce0f593..f9b4cd2d7daa 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -181,7 +181,7 @@ &gmac {
snps,reset-active-low;
snps,reset-delays-us = <0 10000 50000>;
tx_delay = <0x10>;
- rx_delay = <0x10>;
+ rx_delay = <0x23>;
status = "okay";
};
--
2.39.5
Konrad pointed out during SM8750 review, that numbers are odd, so I
looked at datasheets and downstream DTS for all previous platforms.
Most numbers are odd.
Older platforms like SM8150, SM8250, SC7280, SC8180X seem fine. I could
not check few like SDX75 or SM6115, due to lack of access to datasheets.
SM8350, SM8450, SM8550 tested on hardware. Others not, but I don't
expect any failures because PAS drivers do not use the address space.
Which also explains why odd numbers did not result in any failures.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (19):
arm64: dts: qcom: sm8350: Fix ADSP memory base and length
arm64: dts: qcom: sm8350: Fix CDSP memory base and length
arm64: dts: qcom: sm8350: Fix MPSS memory length
arm64: dts: qcom: sm8450: Fix ADSP memory base and length
arm64: dts: qcom: sm8450: Fix CDSP memory length
arm64: dts: qcom: sm8450: Fix MPSS memory length
arm64: dts: qcom: sm8550: Fix ADSP memory base and length
arm64: dts: qcom: sm8550: Fix CDSP memory length
arm64: dts: qcom: sm8550: Fix MPSS memory length
arm64: dts: qcom: sm8650: Fix ADSP memory base and length
arm64: dts: qcom: sm8650: Fix CDSP memory length
arm64: dts: qcom: sm8650: Fix MPSS memory length
arm64: dts: qcom: x1e80100: Fix ADSP memory base and length
arm64: dts: qcom: x1e80100: Fix CDSP memory length
arm64: dts: qcom: sm6350: Fix ADSP memory length
arm64: dts: qcom: sm6350: Fix MPSS memory length
arm64: dts: qcom: sm6375: Fix ADSP memory length
arm64: dts: qcom: sm6375: Fix CDSP memory base and length
arm64: dts: qcom: sm6375: Fix MPSS memory base and length
arch/arm64/boot/dts/qcom/sm6350.dtsi | 4 +-
arch/arm64/boot/dts/qcom/sm6375.dtsi | 10 +-
arch/arm64/boot/dts/qcom/sm8350.dtsi | 492 ++++++++++++++++-----------------
arch/arm64/boot/dts/qcom/sm8450.dtsi | 216 +++++++--------
arch/arm64/boot/dts/qcom/sm8550.dtsi | 266 +++++++++---------
arch/arm64/boot/dts/qcom/sm8650.dtsi | 300 ++++++++++----------
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 276 +++++++++---------
7 files changed, 782 insertions(+), 782 deletions(-)
---
base-commit: c245a7a79602ccbee780c004c1e4abcda66aec32
change-id: 20241206-dts-qcom-cdsp-mpss-base-address-ae7c406ac9ac
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
During suspend/resume process all connectors are explicitly disabled and
then reenabled. However resume fails because of the connector_status check:
[ 1185.831970] [dpu error]connector not connected 3
It doesn't make sense to check for the Writeback connected status (and
other drivers don't perform such check), so drop the check.
Fixes: 71174f362d67 ("drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c")
Cc: stable(a)vger.kernel.org
Reported-by: Leonard Lausen <leonard(a)lausen.nl>
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/57
Tested-by: Leonard Lausen <leonard(a)lausen.nl> # on sc7180 lazor
Tested-by: György Kurucz <me(a)kuruczgy.com>
Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org>
Tested-by: Johan Hovold <johan+linaro(a)kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
---
Leonard Lausen reported an issue with suspend/resume of the sc7180
devices. Fix the WB atomic check, which caused the issue.
---
Changes in v3:
- Rebased on top of msm-fixes
- Link to v2: https://lore.kernel.org/r/20240802-dpu-fix-wb-v2-0-7eac9eb8e895@linaro.org
Changes in v2:
- Reworked the writeback to just drop the connector->status check.
- Expanded commit message for the debugging patch.
- Link to v1: https://lore.kernel.org/r/20240709-dpu-fix-wb-v1-0-448348bfd4cb@linaro.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
index 16f144cbc0c986ee266412223d9e605b01f9fb8c..8ff496082902b1ee713e806140f39b4730ed256a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
@@ -42,9 +42,6 @@ static int dpu_wb_conn_atomic_check(struct drm_connector *connector,
if (!conn_state || !conn_state->connector) {
DPU_ERROR("invalid connector state\n");
return -EINVAL;
- } else if (conn_state->connector->status != connector_status_connected) {
- DPU_ERROR("connector not connected %d\n", conn_state->connector->status);
- return -EINVAL;
}
crtc = conn_state->crtc;
---
base-commit: 86313a9cd152330c634b25d826a281c6a002eb77
change-id: 20240709-dpu-fix-wb-6cd57e3eb182
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
Hi,
This series enables USB3 Type-C lane orientation detection and
configuration on platforms that support this (Google gs101), and it
also allows the DWC3 core to enter runtime suspend even when UDC is
active.
For lane orientation, this driver now optionally (based on DT)
subscribes to the TCPC's lane orientation notifier and remembers the
orientation to later be used during phy_init().
To enable DWC3 runtime suspend, the gadget needs to inform the core via
dwc3_gadget_interrupt() with event type == DWC3_DEVICE_EVENT_DISCONNECT
of a cable disconnect. For that to allow to happen, this driver
therefore needs to stop forcing the Vbus and bvalid signals to active
and instead change their state based on actual conditions. The same
TCPC notifier is used to detect this, and program the hardware
accordingly.
That signal state is based on advice given by Thinh in
https://lore.kernel.org/all/20240813230625.jgkatqstyhcmpezv@synopsys.com/
Both changes together now allow cable orientation detection to work, as
the DWC3 will now call phy_exit() on cable disconnect, and we can
reprogram the lane mux in phy_init().
On top of that, there are some small related cleanup patches.
Signed-off-by: André Draszik <andre.draszik(a)linaro.org>
---
Changes in v3:
- patches 1 & 2: update as per Rob's suggestions
- patch 7 & 8: drop init to -1 of phy_drd->orientation (Vinod)
- patch 7: avoid an #ifdef
- Link to v2: https://lore.kernel.org/r/20241203-gs101-phy-lanes-orientation-phy-v2-0-40d…
Changes in v2:
- squash patches #2 and #3 from v1 to actually disallow
orientation-switch on !gs101 (not just optional) (Conor)
- update bindings commit message to clarify that the intention for the
driver is to work with old and new DTS (Conor)
- add cc-stable and fixes tags to power gating patch (Krzysztof)
- fix an #include and typo (Peter)
- Link to v1: https://lore.kernel.org/r/20241127-gs101-phy-lanes-orientation-phy-v1-0-1b7…
---
André Draszik (8):
dt-bindings: phy: samsung,usb3-drd-phy: add blank lines between DT properties
dt-bindings: phy: samsung,usb3-drd-phy: gs101: require Type-C properties
phy: exynos5-usbdrd: convert to dev_err_probe
phy: exynos5-usbdrd: fix EDS distribution tuning (gs101)
phy: exynos5-usbdrd: gs101: ensure power is gated to SS phy in phy_exit()
phy: exynos5-usbdrd: gs101: configure SS lanes based on orientation
phy: exynos5-usbdrd: subscribe to orientation notifier if required
phy: exynos5-usbdrd: allow DWC3 runtime suspend with UDC bound (E850+)
.../bindings/phy/samsung,usb3-drd-phy.yaml | 21 +-
drivers/phy/samsung/Kconfig | 1 +
drivers/phy/samsung/phy-exynos5-usbdrd.c | 215 ++++++++++++++++-----
3 files changed, 190 insertions(+), 47 deletions(-)
---
base-commit: c245a7a79602ccbee780c004c1e4abcda66aec32
change-id: 20241127-gs101-phy-lanes-orientation-phy-29d20c6d84d2
Best regards,
--
André Draszik <andre.draszik(a)linaro.org>
This series fixes various small issues in the drivers, and adds a few
things (a couple of pixel formats and a debugging feature).
It also takes a few steps in adding more i2c read/write error handlings
to the drivers, but covers only the easy places.
Adding error handling to all reads/writes needs more thinking, perhaps
adding a "ret" parameter to the calls, similar to the cci_* functions,
or perhaps adding helpers for writing multiple registers from a given
table. Also, in some places rolling back from an error will require
work.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>
---
Changes in v3:
- Include bitfield.h for FIELD_PREP()
- Cc stable for relevant fixes
- Link to v2: https://lore.kernel.org/r/20241108-ub9xx-fixes-v2-0-c7db3b2ad89f@ideasonboa…
Changes in v2:
- Address comments from Andy
- Add two new patches:
- media: i2c: ds90ub960: Fix shadowing of local variables
- media: i2c: ds90ub960: Use HZ_PER_MHZ
- Link to v1: https://lore.kernel.org/r/20241004-ub9xx-fixes-v1-0-e30a4633c786@ideasonboa…
---
Tomi Valkeinen (15):
media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()
media: i2c: ds90ub960: Fix UB9702 refclk register access
media: i2c: ds90ub960: Fix use of non-existing registers on UB9702
media: i2c: ds90ub960: Fix logging SP & EQ status only for UB9702
media: i2c: ds90ub960: Fix UB9702 VC map
media: i2c: ds90ub960: Use HZ_PER_MHZ
media: i2c: ds90ub960: Add support for I2C_RX_ID
media: i2c: ds90ub960: Add RGB24, RAW8 and RAW10 formats
media: i2c: ds90ub953: Clear CRC errors in ub953_log_status()
media: i2c: ds90ub960: Drop unused indirect block define
media: i2c: ds90ub960: Reduce sleep in ub960_rxport_wait_locks()
media: i2c: ds90ub960: Handle errors in ub960_log_status_ub960_sp_eq()
media: i2c: ds90ub913: Add error handling to ub913_hw_init()
media: i2c: ds90ub953: Add error handling for i2c reads/writes
media: i2c: ds90ub960: Fix shadowing of local variables
drivers/media/i2c/ds90ub913.c | 26 ++++--
drivers/media/i2c/ds90ub953.c | 56 +++++++++----
drivers/media/i2c/ds90ub960.c | 186 ++++++++++++++++++++++++++++--------------
3 files changed, 187 insertions(+), 81 deletions(-)
---
base-commit: adc218676eef25575469234709c2d87185ca223a
change-id: 20241004-ub9xx-fixes-bba80dc48627
Best regards,
--
Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>