[PATCH] dt-bindings: correct white-spaces in examples
Use only one and exactly one space around '=' in DTS example.
Signed-off-by: Krzysztof Kozlowski
---
Merging idea: Rob's DT.
Should apply cleanly on Rob's for-next.
---
.../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +-
.../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml | 2 +-
Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 6 +++---
.../devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml | 2 +-
.../devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml | 2 +-
.../interrupt-controller/st,stih407-irq-syscfg.yaml | 4 ++--
Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 2 +-
Documentation/devicetree/bindings/net/sff,sfp.yaml| 2 +-
.../devicetree/bindings/pci/toshiba,visconti-pcie.yaml| 2 +-
.../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 6 +++---
.../devicetree/bindings/power/supply/richtek,rt9455.yaml | 8
.../devicetree/bindings/regulator/mps,mp5416.yaml | 4 ++--
.../devicetree/bindings/regulator/mps,mpq7920.yaml| 4 ++--
.../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8
14 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
index fde07e4b119d..406a922a714e 100644
--- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
@@ -113,7 +113,7 @@ examples:
hd44780 {
compatible = "hit,hd44780";
display-height-chars = <2>;
-display-width-chars = <16>;
+display-width-chars = <16>;
data-gpios = <&pcf8574 4 0>,
<&pcf8574 5 0>,
<&pcf8574 6 0>,
diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
index 624984d51c10..7f8d98226437 100644
--- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
+++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
@@ -125,7 +125,7 @@ examples:
clk25m: clock-oscillator-25m {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <2500>;
+ clock-frequency = <2500>;
clock-output-names = "clk25m";
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
index 5fcc8dd012f1..be2616ff9af6 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
@@ -80,9 +80,9 @@ examples:
compatible = "adi,ad7780";
reg = <0>;
-avdd-supply = <&vdd_supply>;
-powerdown-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
-adi,gain-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
+avdd-supply = <&vdd_supply>;
+powerdown-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+adi,gain-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
adi,filter-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
index 73def67fbe01..b6a233cd5f6b 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
@@ -58,7 +58,7 @@ examples:
reg = <0x3600>;
interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
qcom,external-resistor-micro-ohms = <1>;
-#io-channel-cells = <1>;
+#io-channel-cells = <1>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
index b3a626389870..64abe9a4cd9e 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
@@ -46,6 +46,6 @@ examples:
pmic_rradc: adc@4500 {
compatible = "qcom,pmi8998-rradc";
reg = <0x4500>;
-#io-channel-cells = <1>;
+#io-channel-cells = <1>;
};
};
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml
b/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml
index 2b153d7c5421..e44e4e5708a7 100644
---
a/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml
+++
b/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml
@@ -55,8 +55,8 @@ examples:
- |
#include
irq-syscfg {
-compatible= "st,stih407-irq-syscfg";
-st,syscfg = <&syscfg_cpu>;
+compatible = "st,stih407-irq-syscfg";
+st,syscfg = <&syscfg_
Re: [PATCH] dt-bindings: correct white-spaces in examples
On Fri, Nov 24, 2023 at 10:21:21AM +0100, Krzysztof Kozlowski wrote:
> Use only one and exactly one space around '=' in DTS example.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Merging idea: Rob's DT.
> Should apply cleanly on Rob's for-next.
> ---
> .../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +-
> .../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml | 2 +-
> Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 6 +++---
> .../devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml | 2 +-
> .../devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml | 2 +-
> .../interrupt-controller/st,stih407-irq-syscfg.yaml | 4 ++--
> Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 2 +-
> Documentation/devicetree/bindings/net/sff,sfp.yaml| 2 +-
> .../devicetree/bindings/pci/toshiba,visconti-pcie.yaml| 2 +-
> .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 6 +++---
> .../devicetree/bindings/power/supply/richtek,rt9455.yaml | 8
> .../devicetree/bindings/regulator/mps,mp5416.yaml | 4 ++--
> .../devicetree/bindings/regulator/mps,mpq7920.yaml| 4 ++--
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8
> 14 files changed, 27 insertions(+), 27 deletions(-)
>
[nip]
> diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> index 624984d51c10..7f8d98226437 100644
> --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> @@ -125,7 +125,7 @@ examples:
> clk25m: clock-oscillator-25m {
>compatible = "fixed-clock";
>#clock-cells = <0>;
> - clock-frequency = <2500>;
> + clock-frequency = <2500>;
>clock-output-names = "clk25m";
> };
> ...
For Baikal-T1 CCU PLL DT-schema
Acked-by: Serge Semin
-Serge(y)
Re: [PATCH v2 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On Fri Nov 24, 2023 at 7:38 AM CET, Vikash Garodia wrote:
>
> On 11/22/2023 7:50 PM, Luca Weiss wrote:
> > On Wed Nov 22, 2023 at 2:17 PM CET, Vikash Garodia wrote:
> >>
> >> On 10/2/2023 7:50 PM, Luca Weiss wrote:
> >>> If the video-firmware node is present, the venus driver assumes we're on
> >>> a system that doesn't use TZ for starting venus, like on ChromeOS
> >>> devices.
> >>>
> >>> Move the video-firmware node to chrome-common.dtsi so we can use venus
> >>> on a non-ChromeOS devices.
> >>>
> >>> At the same time also disable the venus node by default in the dtsi,
> >>> like it's done on other SoCs.
> >>>
> >>> Reviewed-by: Bryan O'Donoghue
> >>> Signed-off-by: Luca Weiss
> >>> ---
> >>> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
> >>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
> >>> 2 files changed, 10 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> index 5d462ae14ba1..cd491e4d 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> @@ -104,6 +104,14 @@ &scm {
> >>> dma-coherent;
> >>> };
> >>>
> >>> +&venus {
> >>> + status = "okay";
> >>> +
> >>> + video-firmware {
> >>> + iommus = <&apps_smmu 0x21a2 0x0>;
> >>> + };
> >>> +};
> >>> +
> >>> &watchdog {
> >>> status = "okay";
> >>> };
> >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> index 66f1eb83cca7..fa53f54d4675 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> @@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
> >>><&apps_smmu 0x2184 0x20>;
> 0x2184 is a secure SID. I think qcm6490-fairphone-fp5.dts needs to override
> the
> iommus property as well to retain only the non secure SID i.e 0x2180 ? I am
> seeing below crash
>
> Call trace:
> [ 47.663593] qcom_smmu_write_s2cr+0x64/0xa4
> [ 47.663616] arm_smmu_attach_dev+0x120/0x284
> [ 47.663647] __iommu_attach_device+0x24/0xf8
> [ 47.676845] __iommu_device_set_domain+0x70/0xd0
> [ 47.681632] __iommu_group_set_domain_internal+0x60/0x1b4
> [ 47.687218] iommu_setup_default_domain+0x358/0x418
> [ 47.692258] __iommu_probe_device+0x3e4/0x404
>
> Could you please reconfirm if Video SID 0x2184 (and mask) is allowed by the
> qcm6490-fairphone-fp5 hardware having TZ ?
Hi,
On FP5 it seems it's no problem to have both SIDs in there, probe and
using venus appears to work fine.
Are you using different firmware than QCM6490.LA.3.0 on the device where
you tested this?
>
> >>> memory-region = <&video_mem>;
> >>>
> >>> + status = "disabled";
> >>> +
> >>> video-decoder {
> >>> compatible = "venus-decoder";
> >>> };
> >>> @@ -3748,10 +3750,6 @@ video-encoder {
> >>> compatible = "venus-encoder";
> >>> };
> >>>
> >>> - video-firmware {
> >>> - iommus = <&apps_smmu 0x21a2 0x0>;
> >>> - };
> >>> -
> >>> venus_opp_table: opp-table {
> >>> compatible = "operating-points-v2";
> >>>
> >>>
> >> Changes look good. Is this tested on SC7280 ?
> >
> > Hi Vikash,
> >
> > I didn't test it myself on sc7280 (just qcm6490-fp5) but dtx_diff
> > reports no differences except for status = okay property being added, so
> > there should be no change on those boards. See below.
> >
> > Regards
> > Luca
>
> I tested on SC7280 (herobrine) and all good.
Great, thanks!
Regards
Luca
>
> Regards,
> Vikash
Re: [PATCH v2 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On 11/24/2023 5:05 PM, Luca Weiss wrote:
> On Fri Nov 24, 2023 at 7:38 AM CET, Vikash Garodia wrote:
>>
>> On 11/22/2023 7:50 PM, Luca Weiss wrote:
>>> On Wed Nov 22, 2023 at 2:17 PM CET, Vikash Garodia wrote:
On 10/2/2023 7:50 PM, Luca Weiss wrote:
> If the video-firmware node is present, the venus driver assumes we're on
> a system that doesn't use TZ for starting venus, like on ChromeOS
> devices.
>
> Move the video-firmware node to chrome-common.dtsi so we can use venus
> on a non-ChromeOS devices.
>
> At the same time also disable the venus node by default in the dtsi,
> like it's done on other SoCs.
>
> Reviewed-by: Bryan O'Donoghue
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> index 5d462ae14ba1..cd491e4d 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> @@ -104,6 +104,14 @@ &scm {
> dma-coherent;
> };
>
> +&venus {
> + status = "okay";
> +
> + video-firmware {
> + iommus = <&apps_smmu 0x21a2 0x0>;
> + };
> +};
> +
> &watchdog {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 66f1eb83cca7..fa53f54d4675 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
><&apps_smmu 0x2184 0x20>;
>> 0x2184 is a secure SID. I think qcm6490-fairphone-fp5.dts needs to override
>> the
>> iommus property as well to retain only the non secure SID i.e 0x2180 ? I am
>> seeing below crash
>>
>> Call trace:
>> [ 47.663593] qcom_smmu_write_s2cr+0x64/0xa4
>> [ 47.663616] arm_smmu_attach_dev+0x120/0x284
>> [ 47.663647] __iommu_attach_device+0x24/0xf8
>> [ 47.676845] __iommu_device_set_domain+0x70/0xd0
>> [ 47.681632] __iommu_group_set_domain_internal+0x60/0x1b4
>> [ 47.687218] iommu_setup_default_domain+0x358/0x418
>> [ 47.692258] __iommu_probe_device+0x3e4/0x404
>>
>> Could you please reconfirm if Video SID 0x2184 (and mask) is allowed by the
>> qcm6490-fairphone-fp5 hardware having TZ ?
>
> Hi,
>
> On FP5 it seems it's no problem to have both SIDs in there, probe and
> using venus appears to work fine.
>
> Are you using different firmware than QCM6490.LA.3.0 on the device where
> you tested this?
I was testing this on RB3 board which uses firmware [1].
Regards,
Vikash
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/vpu-2.0
>>
> memory-region = <&video_mem>;
>
> + status = "disabled";
> +
> video-decoder {
> compatible = "venus-decoder";
> };
> @@ -3748,10 +3750,6 @@ video-encoder {
> compatible = "venus-encoder";
> };
>
> - video-firmware {
> - iommus = <&apps_smmu 0x21a2 0x0>;
> - };
> -
> venus_opp_table: opp-table {
> compatible = "operating-points-v2";
>
>
Changes look good. Is this tested on SC7280 ?
>>>
>>> Hi Vikash,
>>>
>>> I didn't test it myself on sc7280 (just qcm6490-fp5) but dtx_diff
>>> reports no differences except for status = okay property being added, so
>>> there should be no change on those boards. See below.
>>>
>>> Regards
>>> Luca
>>
>> I tested on SC7280 (herobrine) and all good.
>
> Great, thanks!
>
> Regards
> Luca
>
>>
>> Regards,
>> Vikash
>
Re: [PATCH v2 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On Fri, 24 Nov 2023 at 14:30, Vikash Garodia wrote:
>
> On 11/24/2023 5:05 PM, Luca Weiss wrote:
> > On Fri Nov 24, 2023 at 7:38 AM CET, Vikash Garodia wrote:
> >>
> >> On 11/22/2023 7:50 PM, Luca Weiss wrote:
> >>> On Wed Nov 22, 2023 at 2:17 PM CET, Vikash Garodia wrote:
>
> On 10/2/2023 7:50 PM, Luca Weiss wrote:
> > If the video-firmware node is present, the venus driver assumes we're on
> > a system that doesn't use TZ for starting venus, like on ChromeOS
> > devices.
> >
> > Move the video-firmware node to chrome-common.dtsi so we can use venus
> > on a non-ChromeOS devices.
> >
> > At the same time also disable the venus node by default in the dtsi,
> > like it's done on other SoCs.
> >
> > Reviewed-by: Bryan O'Donoghue
> > Signed-off-by: Luca Weiss
> > ---
> > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
> > 2 files changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > index 5d462ae14ba1..cd491e4d 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> > @@ -104,6 +104,14 @@ &scm {
> > dma-coherent;
> > };
> >
> > +&venus {
> > + status = "okay";
> > +
> > + video-firmware {
> > + iommus = <&apps_smmu 0x21a2 0x0>;
> > + };
> > +};
> > +
> > &watchdog {
> > status = "okay";
> > };
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 66f1eb83cca7..fa53f54d4675 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
> ><&apps_smmu 0x2184 0x20>;
> >> 0x2184 is a secure SID. I think qcm6490-fairphone-fp5.dts needs to
> >> override the
> >> iommus property as well to retain only the non secure SID i.e 0x2180 ? I am
> >> seeing below crash
> >>
> >> Call trace:
> >> [ 47.663593] qcom_smmu_write_s2cr+0x64/0xa4
> >> [ 47.663616] arm_smmu_attach_dev+0x120/0x284
> >> [ 47.663647] __iommu_attach_device+0x24/0xf8
> >> [ 47.676845] __iommu_device_set_domain+0x70/0xd0
> >> [ 47.681632] __iommu_group_set_domain_internal+0x60/0x1b4
> >> [ 47.687218] iommu_setup_default_domain+0x358/0x418
> >> [ 47.692258] __iommu_probe_device+0x3e4/0x404
> >>
> >> Could you please reconfirm if Video SID 0x2184 (and mask) is allowed by the
> >> qcm6490-fairphone-fp5 hardware having TZ ?
> >
> > Hi,
> >
> > On FP5 it seems it's no problem to have both SIDs in there, probe and
> > using venus appears to work fine.
> >
> > Are you using different firmware than QCM6490.LA.3.0 on the device where
> > you tested this?
> I was testing this on RB3 board which uses firmware [1].
There is something wrong here.
RB3 board uses venus-5.2
RB5 board uses vpu-1.0
Only sc7280 uses vpu-2.0
>
> Regards,
> Vikash
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/vpu-2.0
>
> >>
> > memory-region = <&video_mem>;
> >
> > + status = "disabled";
> > +
> > video-decoder {
> > compatible = "venus-decoder";
> > };
> > @@ -3748,10 +3750,6 @@ video-encoder {
> > compatible = "venus-encoder";
> > };
> >
> > - video-firmware {
> > - iommus = <&apps_smmu 0x21a2 0x0>;
> > - };
> > -
> > venus_opp_table: opp-table {
> > compatible = "operating-points-v2";
> >
> >
> Changes look good. Is this tested on SC7280 ?
> >>>
> >>> Hi Vikash,
> >>>
> >>> I didn't test it myself on sc7280 (just qcm6490-fp5) but dtx_diff
> >>> reports no differences except for status = okay property being added, so
> >>> there should be no change on those boards. See below.
> >>>
> >>> Regards
> >>> Luca
> >>
> >> I tested on SC7280 (herobrine) and all good.
> >
> > Great, thanks!
> >
> > Regards
> > Luca
> >
> >>
> >> Regards,
> >> Vikash
> >
>
--
With best wishes
Dmitry
Re: [REGRESSION] USB ports do not work after suspend/resume cycle with v6.6.2
+Cc workflows
On 11/24/23 12:43, Greg Kroah-Hartman wrote:
> On Thu, Nov 23, 2023 at 07:20:46PM +0100, Oleksandr Natalenko wrote:
>> Hello.
>>
>> Since v6.6.2 kernel release I'm experiencing a regression with regard
>> to USB ports behaviour after a suspend/resume cycle.
>>
>> If a USB port is empty before suspending, after resuming the machine
>> the port doesn't work. After a device insertion there's no reaction in
>> the kernel log whatsoever, although I do see that the device gets
>> powered up physically. If the machine is suspended with a device
>> inserted into the USB port, the port works fine after resume.
>>
>> This is an AMD-based machine with hci version 0x110 reported. As per
>> the changelog between v6.6.1 and v6.6.2, 603 commits were backported
>> into v6.6.2, and one of the commits was as follows:
>>
>> $ git log --oneline v6.6.1..v6.6.2 -- drivers/usb/host/xhci-pci.c
>> 14a51fa544225 xhci: Loosen RPM as default policy to cover for AMD xHC
>> 1.1
>>
>> It seems that this commit explicitly enables runtime PM specifically
>> for my platform. As per dmesg:
>>
>> v6.6.1: quirks 0x0410 v6.6.2: quirks 0x00020410
>>
>> Here, bit 33 gets set, which, as expected, corresponds to:
>>
>> drivers/usb/host/xhci.h 1895:#define XHCI_DEFAULT_PM_RUNTIME_ALLOW
>> BIT_ULL(33)
>>
>> This commit is backported from the upstream commit 4baf12181509, which
>> is one of 16 commits of the following series named "xhci features":
>>
>> https://lore.kernel.org/all/20231019102924.2797346-1-mathias.ny...@linux.intel.com/
>>
>> It appears that there was another commit in this series, also from
>> Basavaraj (in Cc), a5d6264b638e, which was not picked for v6.6.2, but
>> which stated the following:
>>
>> Use the low-power states of the underlying platform to enable runtime
>> PM. If the platform doesn't support runtime D3, then enabling default
>> RPM will result in the controller malfunctioning, as in the case of
>> hotplug devices not being detected because of a failed interrupt
>> generation.
>>
>> It felt like this was exactly my case. So, I've conducted two tests:
>>
>> 1. Reverted 14a51fa544225 from v6.6.2. With this revert the USB ports
>> started to work fine, just as they did in v6.6.1. 2. Left 14a51fa544225
>> in place, but also applied upstream a5d6264b638e on top of v6.6.2. With
>> this patch added the USB ports also work after a suspend/resume cycle.
>>
>> This runtime PM enablement did also impact my AX200 Bluetooth device,
>> resulting in long delays before headphones/speaker can connect, but
>> I've solved this with btusb.enable_autosuspend=N. I think this has
>> nothing to do with the original issue, and I'm OK with this workaround
>> unless someone has got a different idea.
>>
>> With that, please consider either reverting 14a51fa544225 from the
>> stable kernel, or applying a5d6264b638e in addition to it. Given the
>> mainline kernel has got both of them, I'm in favour of applying
>> additional commit to the stable kernel.
>
> I've applied this other commit as well to all of the affected branches,
> thanks for letting us know.
>
>> I'm also Cc'ing all the people from our Mastodon discussion where I
>> initially complained about the issue as well as about stable kernel
>> branch stability:
>>
>> https://activitypub.natalenko.name/@oleksandr/statuses/01HFRXBYWMXF9G4KYPE3XHH0S8
>>
>> I'm not going to expand more on that in this email, especially given
>> Greg indicated he read the conversation, but I'm open to continuing
>> this discussion as I still think that current workflow brings visible
>> issues to ordinary users, and hence some adjustments should be made.
>
> What type of adjustments exactly? Testing on wide ranges of systems is
> pretty hard, and this patch explicitly was set to be backported when it
> hit Linus's tree,
Are you sure about that "explicitly was set to be backported" part?
According to Documentation/process/stable-kernel-rules.rst:
> There are three options to submit a change to -stable trees:
>
> 1. Add a 'stable tag' to the description of a patch you then submit for
> mainline inclusion.
> 2. Ask the stable team to pick up a patch already mainlined.
> 3. Submit a patch to the stable team that is equivalent to a change already
> mainlined.
I don't see a stable tag in 4baf12181509 ("xhci: Loosen RPM as default
policy to cover for AMD xHC 1.1"), was it option 2 or 3 then?
Do you mean the Fixes: tag? the docs only say that can replace the "# 3.3.x"
part to determine where backporting should stop, but is not itself an
explicit marking for stable backport?
> it just looks like someone forgot to mark the
> follow-up patch that you found also to be properly backported.
>
> We will always make mistakes, we are only human. The best thing to do
> is if we get notified quickly of issues, like you did here, and work to
> resolve them, as we have done here. So again, thanks for letting us
> know about the problem, and be sure to let us
Re: [REGRESSION] USB ports do not work after suspend/resume cycle with v6.6.2
On Fri, Nov 24, 2023 at 01:59:24PM +0100, Vlastimil Babka wrote:
> +Cc workflows
>
> On 11/24/23 12:43, Greg Kroah-Hartman wrote:
> > On Thu, Nov 23, 2023 at 07:20:46PM +0100, Oleksandr Natalenko wrote:
> >> Hello.
> >>
> >> Since v6.6.2 kernel release I'm experiencing a regression with regard
> >> to USB ports behaviour after a suspend/resume cycle.
> >>
> >> If a USB port is empty before suspending, after resuming the machine
> >> the port doesn't work. After a device insertion there's no reaction in
> >> the kernel log whatsoever, although I do see that the device gets
> >> powered up physically. If the machine is suspended with a device
> >> inserted into the USB port, the port works fine after resume.
> >>
> >> This is an AMD-based machine with hci version 0x110 reported. As per
> >> the changelog between v6.6.1 and v6.6.2, 603 commits were backported
> >> into v6.6.2, and one of the commits was as follows:
> >>
> >> $ git log --oneline v6.6.1..v6.6.2 -- drivers/usb/host/xhci-pci.c
> >> 14a51fa544225 xhci: Loosen RPM as default policy to cover for AMD xHC
> >> 1.1
> >>
> >> It seems that this commit explicitly enables runtime PM specifically
> >> for my platform. As per dmesg:
> >>
> >> v6.6.1: quirks 0x0410 v6.6.2: quirks 0x00020410
> >>
> >> Here, bit 33 gets set, which, as expected, corresponds to:
> >>
> >> drivers/usb/host/xhci.h 1895:#define XHCI_DEFAULT_PM_RUNTIME_ALLOW
> >> BIT_ULL(33)
> >>
> >> This commit is backported from the upstream commit 4baf12181509, which
> >> is one of 16 commits of the following series named "xhci features":
> >>
> >> https://lore.kernel.org/all/20231019102924.2797346-1-mathias.ny...@linux.intel.com/
> >>
> >> It appears that there was another commit in this series, also from
> >> Basavaraj (in Cc), a5d6264b638e, which was not picked for v6.6.2, but
> >> which stated the following:
> >>
> >> Use the low-power states of the underlying platform to enable runtime
> >> PM. If the platform doesn't support runtime D3, then enabling default
> >> RPM will result in the controller malfunctioning, as in the case of
> >> hotplug devices not being detected because of a failed interrupt
> >> generation.
> >>
> >> It felt like this was exactly my case. So, I've conducted two tests:
> >>
> >> 1. Reverted 14a51fa544225 from v6.6.2. With this revert the USB ports
> >> started to work fine, just as they did in v6.6.1. 2. Left 14a51fa544225
> >> in place, but also applied upstream a5d6264b638e on top of v6.6.2. With
> >> this patch added the USB ports also work after a suspend/resume cycle.
> >>
> >> This runtime PM enablement did also impact my AX200 Bluetooth device,
> >> resulting in long delays before headphones/speaker can connect, but
> >> I've solved this with btusb.enable_autosuspend=N. I think this has
> >> nothing to do with the original issue, and I'm OK with this workaround
> >> unless someone has got a different idea.
> >>
> >> With that, please consider either reverting 14a51fa544225 from the
> >> stable kernel, or applying a5d6264b638e in addition to it. Given the
> >> mainline kernel has got both of them, I'm in favour of applying
> >> additional commit to the stable kernel.
> >
> > I've applied this other commit as well to all of the affected branches,
> > thanks for letting us know.
> >
> >> I'm also Cc'ing all the people from our Mastodon discussion where I
> >> initially complained about the issue as well as about stable kernel
> >> branch stability:
> >>
> >> https://activitypub.natalenko.name/@oleksandr/statuses/01HFRXBYWMXF9G4KYPE3XHH0S8
> >>
> >> I'm not going to expand more on that in this email, especially given
> >> Greg indicated he read the conversation, but I'm open to continuing
> >> this discussion as I still think that current workflow brings visible
> >> issues to ordinary users, and hence some adjustments should be made.
> >
> > What type of adjustments exactly? Testing on wide ranges of systems is
> > pretty hard, and this patch explicitly was set to be backported when it
> > hit Linus's tree,
>
> Are you sure about that "explicitly was set to be backported" part?
> According to Documentation/process/stable-kernel-rules.rst:
>
> > There are three options to submit a change to -stable trees:
> >
> > 1. Add a 'stable tag' to the description of a patch you then submit for
> > mainline inclusion.
> > 2. Ask the stable team to pick up a patch already mainlined.
> > 3. Submit a patch to the stable team that is equivalent to a change already
> > mainlined.
>
> I don't see a stable tag in 4baf12181509 ("xhci: Loosen RPM as default
> policy to cover for AMD xHC 1.1"), was it option 2 or 3 then?
>
> Do you mean the Fixes: tag? the docs only say that can replace the "# 3.3.x"
> part to determine where backporting should stop, but is not itself an
> explicit marking for stable backport?
No, I mean the "The subsystem maintainer knew this needed to be added to
the stable trees so they told the stable
Re: [PATCH v2 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On 11/24/2023 6:23 PM, Dmitry Baryshkov wrote:
> On Fri, 24 Nov 2023 at 14:30, Vikash Garodia
> wrote:
>>
>> On 11/24/2023 5:05 PM, Luca Weiss wrote:
>>> On Fri Nov 24, 2023 at 7:38 AM CET, Vikash Garodia wrote:
On 11/22/2023 7:50 PM, Luca Weiss wrote:
> On Wed Nov 22, 2023 at 2:17 PM CET, Vikash Garodia wrote:
>>
>> On 10/2/2023 7:50 PM, Luca Weiss wrote:
>>> If the video-firmware node is present, the venus driver assumes we're on
>>> a system that doesn't use TZ for starting venus, like on ChromeOS
>>> devices.
>>>
>>> Move the video-firmware node to chrome-common.dtsi so we can use venus
>>> on a non-ChromeOS devices.
>>>
>>> At the same time also disable the venus node by default in the dtsi,
>>> like it's done on other SoCs.
>>>
>>> Reviewed-by: Bryan O'Donoghue
>>> Signed-off-by: Luca Weiss
>>> ---
>>> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
>>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
>>> 2 files changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
>>> b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
>>> index 5d462ae14ba1..cd491e4d 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
>>> @@ -104,6 +104,14 @@ &scm {
>>> dma-coherent;
>>> };
>>>
>>> +&venus {
>>> + status = "okay";
>>> +
>>> + video-firmware {
>>> + iommus = <&apps_smmu 0x21a2 0x0>;
>>> + };
>>> +};
>>> +
>>> &watchdog {
>>> status = "okay";
>>> };
>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> index 66f1eb83cca7..fa53f54d4675 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> @@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
>>><&apps_smmu 0x2184 0x20>;
0x2184 is a secure SID. I think qcm6490-fairphone-fp5.dts needs to
override the
iommus property as well to retain only the non secure SID i.e 0x2180 ? I am
seeing below crash
Call trace:
[ 47.663593] qcom_smmu_write_s2cr+0x64/0xa4
[ 47.663616] arm_smmu_attach_dev+0x120/0x284
[ 47.663647] __iommu_attach_device+0x24/0xf8
[ 47.676845] __iommu_device_set_domain+0x70/0xd0
[ 47.681632] __iommu_group_set_domain_internal+0x60/0x1b4
[ 47.687218] iommu_setup_default_domain+0x358/0x418
[ 47.692258] __iommu_probe_device+0x3e4/0x404
Could you please reconfirm if Video SID 0x2184 (and mask) is allowed by the
qcm6490-fairphone-fp5 hardware having TZ ?
>>>
>>> Hi,
>>>
>>> On FP5 it seems it's no problem to have both SIDs in there, probe and
>>> using venus appears to work fine.
>>>
>>> Are you using different firmware than QCM6490.LA.3.0 on the device where
>>> you tested this?
>> I was testing this on RB3 board which uses firmware [1].
>
> There is something wrong here.
>
> RB3 board uses venus-5.2
> RB5 board uses vpu-1.0
> Only sc7280 uses vpu-2.0
Tested on QCM6490 IDP board, which is QCOM internal board similar to RB3 gen2.
>>
>> Regards,
>> Vikash
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/vpu-2.0
>>
>>> memory-region = <&video_mem>;
>>>
>>> + status = "disabled";
>>> +
>>> video-decoder {
>>> compatible = "venus-decoder";
>>> };
>>> @@ -3748,10 +3750,6 @@ video-encoder {
>>> compatible = "venus-encoder";
>>> };
>>>
>>> - video-firmware {
>>> - iommus = <&apps_smmu 0x21a2 0x0>;
>>> - };
>>> -
>>> venus_opp_table: opp-table {
>>> compatible = "operating-points-v2";
>>>
>>>
>> Changes look good. Is this tested on SC7280 ?
>
> Hi Vikash,
>
> I didn't test it myself on sc7280 (just qcm6490-fp5) but dtx_diff
> reports no differences except for status = okay property being added, so
> there should be no change on those boards. See below.
>
> Regards
> Luca
I tested on SC7280 (herobrine) and all good.
>>>
>>> Great, thanks!
>>>
>>> Regards
>>> Luca
>>>
Regards,
Vikash
>>>
>>
>
>
[PATCH 1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Fix typos
There are two typos in this dtsi, so fix it.
classis -> chassis.
8070 -> 8060
Signed-off-by: Jianhua Lu
---
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 85e5cf3dc91e..3d4ea428e4cb 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -23,7 +23,7 @@
/delete-node/ &xbl_aop_mem;
/ {
- classis-type = "tablet";
+ chassis-type = "tablet";
/* required for bootloader to select correct board */
qcom,msm-id = ; /* SM8250 v2.1 */
@@ -114,7 +114,7 @@ vreg_s6c_0p88: smpc6-regulator {
};
reserved-memory {
- xbl_aop_mem: xbl-aop@8070 {
+ xbl_aop_mem: xbl-aop@8060 {
reg = <0x0 0x8060 0x0 0x26>;
no-map;
};
--
2.41.0
[PATCH 2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Sort ufs node
ufs node isn't in a right place, 'f' is front of 's', so move it to
above usb node.
Signed-off-by: Jianhua Lu
---
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 32 +--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 3d4ea428e4cb..3de7cb918448 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -657,6 +657,22 @@ &tlmm {
gpio-reserved-ranges = <40 4>;
};
+&ufs_mem_hc {
+ vcc-supply = <&vreg_l17a_3p0>;
+ vcc-max-microamp = <80>;
+ vccq-supply = <&vreg_l6a_1p2>;
+ vccq-max-microamp = <80>;
+ vccq2-supply = <&vreg_s4a_1p8>;
+ vccq2-max-microamp = <80>;
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+ status = "okay";
+};
+
&usb_1 {
/* USB 2.0 only */
qcom,select-utmi-as-pipe-clk;
@@ -678,22 +694,6 @@ &usb_1_hsphy {
status = "okay";
};
-&ufs_mem_hc {
- vcc-supply = <&vreg_l17a_3p0>;
- vcc-max-microamp = <80>;
- vccq-supply = <&vreg_l6a_1p2>;
- vccq-max-microamp = <80>;
- vccq2-supply = <&vreg_s4a_1p8>;
- vccq2-max-microamp = <80>;
- status = "okay";
-};
-
-&ufs_mem_phy {
- vdda-phy-supply = <&vreg_l5a_0p88>;
- vdda-pll-supply = <&vreg_l9a_1p2>;
- status = "okay";
-};
-
&venus {
firmware-name = "qcom/sm8250/xiaomi/elish/venus.mbn";
status = "okay";
--
2.41.0
[PATCH 3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8150b type-c node
Add type-c node to feature otg function.
Signed-off-by: Jianhua Lu
---
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 3de7cb918448..87a83f9bdea5 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "sm8250.dtsi"
#include "pm8150.dtsi"
#include "pm8150b.dtsi"
@@ -627,6 +628,37 @@ vol_up_n: vol-up-n-state {
};
};
+&pm8150b_typec {
+ vdd-pdphy-supply = <&vreg_l2a_3p1>;
+ status = "okay";
+
+ connector {
+ compatible = "usb-c-connector";
+
+ power-role = "source";
+ data-role = "dual";
+ self-powered;
+
+ source-pdos = ;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pm8150b_role_switch_in: endpoint {
+ remote-endpoint =
<&usb_1_role_switch_out>;
+ };
+ };
+ };
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
@@ -694,6 +726,10 @@ &usb_1_hsphy {
status = "okay";
};
+&usb_1_role_switch_out {
+ remote-endpoint = <&pm8150b_role_switch_in>;
+};
+
&venus {
firmware-name = "qcom/sm8250/xiaomi/elish/venus.mbn";
status = "okay";
--
2.41.0
Re: [PATCH] rethook: Use __rcu pointer for rethook::handler
Hi Masami,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.7-rc2 next-20231124]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Masami-Hiramatsu-Google/rethook-Use-__rcu-pointer-for-rethook-handler/20231124-090634
base: linus/master
patch link:
https://lore.kernel.org/r/170078778632.209874.7893551840863388753.stgit%40devnote2
patch subject: [PATCH] rethook: Use __rcu pointer for rethook::handler
config: x86_64-randconfig-r113-20231124
(https://download.01.org/0day-ci/archive/20231124/202311241808.rv9ceuah-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231124/202311241808.rv9ceuah-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202311241808.rv9ceuah-...@intel.com/
sparse warnings: (new ones prefixed by >>)
>> kernel/trace/rethook.c:51:9: sparse: sparse: incompatible types in
>> comparison expression (different address spaces):
>> kernel/trace/rethook.c:51:9: sparse:void ( [noderef] __rcu * )( ... )
>> kernel/trace/rethook.c:51:9: sparse:void ( * )( ... )
kernel/trace/rethook.c:66:9: sparse: sparse: incompatible types in
comparison expression (different address spaces):
kernel/trace/rethook.c:66:9: sparse:void ( [noderef] __rcu * )( ... )
kernel/trace/rethook.c:66:9: sparse:void ( * )( ... )
kernel/trace/rethook.c:110:9: sparse: sparse: incompatible types in
comparison expression (different address spaces):
kernel/trace/rethook.c:110:9: sparse:void ( [noderef] __rcu * )( ... )
kernel/trace/rethook.c:110:9: sparse:void ( * )( ... )
kernel/trace/rethook.c:140:19: sparse: sparse: incompatible types in
comparison expression (different address spaces):
kernel/trace/rethook.c:140:19: sparse:void ( [noderef] __rcu * )( ... )
kernel/trace/rethook.c:140:19: sparse:void ( * )( ... )
kernel/trace/rethook.c:161:19: sparse: sparse: incompatible types in
comparison expression (different address spaces):
kernel/trace/rethook.c:161:19: sparse:void ( [noderef] __rcu * )( ... )
kernel/trace/rethook.c:161:19: sparse:void ( * )( ... )
kernel/trace/rethook.c:305:27: sparse: sparse: incompatible types in
comparison expression (different address spaces):
kernel/trace/rethook.c:305:27: sparse:void ( [noderef] __rcu * )( ... )
kernel/trace/rethook.c:305:27: sparse:void ( * )( ... )
vim +51 kernel/trace/rethook.c
40
41 /**
42 * rethook_stop() - Stop using a rethook.
43 * @rh: the struct rethook to stop.
44 *
45 * Stop using a rethook to prepare for freeing it. If you want to wait
for
46 * all running rethook handler before calling rethook_free(), you need
to
47 * call this first and wait RCU, and call rethook_free().
48 */
49 void rethook_stop(struct rethook *rh)
50 {
> 51 rcu_assign_pointer(rh->handler, NULL);
52 }
53
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Sort ufs node
On 24/11/2023 14:57, Jianhua Lu wrote: > ufs node isn't in a right place, 'f' is front of 's', so move it to > above usb node. Please not. If we change the order to match DTSI, then this patch would be wrong. Best regards, Krzysztof
Re: [PATCH v2 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On Fri Nov 24, 2023 at 2:35 PM CET, Vikash Garodia wrote:
>
>
> On 11/24/2023 6:23 PM, Dmitry Baryshkov wrote:
> > On Fri, 24 Nov 2023 at 14:30, Vikash Garodia
> > wrote:
> >>
> >> On 11/24/2023 5:05 PM, Luca Weiss wrote:
> >>> On Fri Nov 24, 2023 at 7:38 AM CET, Vikash Garodia wrote:
>
> On 11/22/2023 7:50 PM, Luca Weiss wrote:
> > On Wed Nov 22, 2023 at 2:17 PM CET, Vikash Garodia wrote:
> >>
> >> On 10/2/2023 7:50 PM, Luca Weiss wrote:
> >>> If the video-firmware node is present, the venus driver assumes we're
> >>> on
> >>> a system that doesn't use TZ for starting venus, like on ChromeOS
> >>> devices.
> >>>
> >>> Move the video-firmware node to chrome-common.dtsi so we can use venus
> >>> on a non-ChromeOS devices.
> >>>
> >>> At the same time also disable the venus node by default in the dtsi,
> >>> like it's done on other SoCs.
> >>>
> >>> Reviewed-by: Bryan O'Donoghue
> >>> Signed-off-by: Luca Weiss
> >>> ---
> >>> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
> >>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
> >>> 2 files changed, 10 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> index 5d462ae14ba1..cd491e4d 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> >>> @@ -104,6 +104,14 @@ &scm {
> >>> dma-coherent;
> >>> };
> >>>
> >>> +&venus {
> >>> + status = "okay";
> >>> +
> >>> + video-firmware {
> >>> + iommus = <&apps_smmu 0x21a2 0x0>;
> >>> + };
> >>> +};
> >>> +
> >>> &watchdog {
> >>> status = "okay";
> >>> };
> >>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> index 66f1eb83cca7..fa53f54d4675 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >>> @@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
> >>><&apps_smmu 0x2184 0x20>;
> 0x2184 is a secure SID. I think qcm6490-fairphone-fp5.dts needs to
> override the
> iommus property as well to retain only the non secure SID i.e 0x2180 ? I
> am
> seeing below crash
>
> Call trace:
> [ 47.663593] qcom_smmu_write_s2cr+0x64/0xa4
> [ 47.663616] arm_smmu_attach_dev+0x120/0x284
> [ 47.663647] __iommu_attach_device+0x24/0xf8
> [ 47.676845] __iommu_device_set_domain+0x70/0xd0
> [ 47.681632] __iommu_group_set_domain_internal+0x60/0x1b4
> [ 47.687218] iommu_setup_default_domain+0x358/0x418
> [ 47.692258] __iommu_probe_device+0x3e4/0x404
>
> Could you please reconfirm if Video SID 0x2184 (and mask) is allowed by
> the
> qcm6490-fairphone-fp5 hardware having TZ ?
> >>>
> >>> Hi,
> >>>
> >>> On FP5 it seems it's no problem to have both SIDs in there, probe and
> >>> using venus appears to work fine.
> >>>
> >>> Are you using different firmware than QCM6490.LA.3.0 on the device where
> >>> you tested this?
> >> I was testing this on RB3 board which uses firmware [1].
> >
> > There is something wrong here.
> >
> > RB3 board uses venus-5.2
> > RB5 board uses vpu-1.0
> > Only sc7280 uses vpu-2.0
>
> Tested on QCM6490 IDP board, which is QCOM internal board similar to RB3 gen2.
In any case, I don't know much about the venus & iommu setup here. I can
try removing the 0x2184 SID and test if venus still works on FP5.
Also should the chromebooks keep that iommu entry or not?
Regards
Luca
>
> >>
> >> Regards,
> >> Vikash
> >>
> >> [1]
> >> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/vpu-2.0
> >>
>
> >>> memory-region = <&video_mem>;
> >>>
> >>> + status = "disabled";
> >>> +
> >>> video-decoder {
> >>> compatible = "venus-decoder";
> >>> };
> >>> @@ -3748,10 +3750,6 @@ video-encoder {
> >>> compatible = "venus-encoder";
> >>> };
> >>>
> >>> - video-firmware {
> >>> - iommus = <&apps_smmu 0x21a2 0x0>;
> >>> - };
> >>> -
> >>> venus_opp_table: opp-table {
> >>> compatible = "operating-points-v2";
> >>>
> >>>
> >> Changes look good. Is this tested on SC7280 ?
> >
> > Hi Vikash,
> >
> > I didn't test it myself on sc7280 (just qcm6490-fp5) but dtx_diff
> > reports no differences except for status = okay property being added, so
> > there should be no change on those boards
Re: [ANNOUNCE] 5.10.201-rt98
On Wed, Nov 22, 2023 at 10:36:23AM -0300, Luis Claudio R. Goncalves wrote: > On Tue, Nov 21, 2023 at 10:01:25PM -0300, Luis Claudio R. Goncalves wrote: > > Hello RT-list! > > > > I'm pleased to announce the 5.10.201-rt98 stable release. > > > > This release is just an update to the new stable 5.10.201 > > version and no RT changes have been made. > > > > You can get this release via the git tree at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > branch: v5.10-rt > > Head SHA1: 3a93f0a0d49dd0db4c6876ca9a7369350e64320e > > Greg KH, > > While testing v5.10.201-rt98 I stumbled over this warning: > > [ 1000.312397] run blktests nvme/005 at 2023-11-21 21:46:30 > ... > [ 1000.500478] workqueue: WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work > [nvmet_tcp] is flushing !WQ_MEM_RECLAIM events:0x0 > [ 1000.500490] WARNING: CPU: 0 PID: 6 at kernel/workqueue.c:2620 > check_flush_dependency+0x11f/0x140 > > That seems to be fixed by: > > 533d2e8b4d5e4 nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush > during queue teardown > (and depending on what else is backported) > ddd2b8de9f85b nvmet: fix workqueue MEM_RECLAIM flushing dependency > > Is this something that can be added to your v5.10 queue or should I carry > this fix on v5.10-rt in the meantime? That's odd, as this commit is already in the 5.10.138 release, so how can we apply it again? confused, greg k-h
[PATCH] remoteproc: qcom: q6v5: Get crash reason from specific SMEM partition
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the current implementation.
Add support to pass crash_reason_smem_id along with crash_reason item
number in qcom_q6v5_init call and use the same to get the crash
information from SMEM in fatal and watchdog IRQ handlers.
This patch depends on [1] which adds support for IPQ9574 and IPQ5332
remoteproc q5v5_mpd driver.
[1]:
https://lore.kernel.org/all/20231110091939.3025413-1-quic_mmani...@quicinc.com/
Signed-off-by: Vignesh Viswanathan
---
drivers/remoteproc/qcom_q6v5.c | 10 +++---
drivers/remoteproc/qcom_q6v5.h | 4 +++-
drivers/remoteproc/qcom_q6v5_adsp.c | 3 ++-
drivers/remoteproc/qcom_q6v5_mpd.c | 2 +-
drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
drivers/remoteproc/qcom_q6v5_pas.c | 3 ++-
drivers/remoteproc/qcom_q6v5_wcss.c | 4 +++-
7 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 0e32f13c196d..072e41730110 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -100,7 +100,8 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
- msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
+ msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
+ &len);
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "watchdog received: %s\n", msg);
else
@@ -121,7 +122,8 @@ irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
if (!q6v5->running)
return IRQ_HANDLED;
- msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
+ msg = qcom_smem_get(q6v5->crash_reason_smem_id, q6v5->crash_reason,
+ &len);
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "fatal error received: %s\n", msg);
else
@@ -279,7 +281,8 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
* Return: 0 on success, negative errno on failure
*/
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason, const char
*load_state,
+ struct rproc *rproc, int crash_reason,
+ int crash_reason_smem_id, const char *load_state,
void (*handover)(struct qcom_q6v5 *q6v5))
{
int ret;
@@ -287,6 +290,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
platform_device *pdev,
q6v5->rproc = rproc;
q6v5->dev = &pdev->dev;
q6v5->crash_reason = crash_reason;
+ q6v5->crash_reason_smem_id = crash_reason_smem_id;
q6v5->handover = handover;
init_completion(&q6v5->start_done);
diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
index 4e1bb1a68284..21cd879e6e1e 100644
--- a/drivers/remoteproc/qcom_q6v5.h
+++ b/drivers/remoteproc/qcom_q6v5.h
@@ -41,6 +41,7 @@ struct qcom_q6v5 {
struct completion spawn_done;
int crash_reason;
+ int crash_reason_smem_id;
bool running;
@@ -49,7 +50,8 @@ struct qcom_q6v5 {
};
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason, const char
*load_state,
+ struct rproc *rproc, int crash_reason,
+ int crash_reason_smem_id, const char *load_state,
void (*handover)(struct qcom_q6v5 *q6v5));
void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5);
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index 6c67514cc493..30d91205f199 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -732,7 +732,8 @@ static int adsp_probe(struct platform_device *pdev)
goto disable_pm;
ret = qcom_q6v5_init(&adsp->q6v5, pdev, rproc, desc->crash_reason_smem,
-desc->load_state, qcom_adsp_pil_handover);
+QCOM_SMEM_HOST_ANY, desc->load_state,
+qcom_adsp_pil_handover);
if (ret)
goto disable_pm;
diff --git a/drivers/remoteproc/qcom_q6v5_mpd.c
b/drivers/remoteproc/qcom_q6v5_mpd.c
index b133285888c7..839f6a15b88d 100644
--- a/drivers/remoteproc/qcom_q6v5_mpd.c
+++ b/drivers/remoteproc/qcom_q6v5_mpd.c
@@ -726,7 +726,7 @@ static int q6_wcss_probe(struct platform_device *pdev)
goto free_rproc;
ret = qcom_q6v5_init(&wcss->q6, pdev, rproc,
-WCSS_CRASH_REASON, NULL, NULL);
+WCSS_CRASH_REASON, WCSS_SMEM_HOST, NULL, NULL);
if (ret)
Re: [PATCH] remoteproc: qcom: Add NOTIFY_FATAL event type to SSR subdevice
On 9/4/2023 10:23 PM, Vignesh Viswanathan wrote: On 7/16/2023 1:50 AM, Bjorn Andersson wrote: On Wed, May 03, 2023 at 11:51:46AM +0530, Vignesh Viswanathan wrote: Currently the SSR subdevice notifies the client driver on crash of the rproc from the recovery workqueue using the BEFORE_SHUTDOWN event. However the client driver might be interested to know that the device has crashed immediately to pause any further transactions with the rproc. This calls for an event to be sent to the driver in the IRQ context as soon as the rproc crashes. Please make your argumentation more concrete, I can only guess what client driver you're referring to. You can do this either by spelling out which actual problem you're solving, or better yet, include some patches in the series that actually uses this interface. Hi Bjorn, Apologies for the delay in response. The client driver in my scenario is a Wi-Fi driver which is continuously queuing data to the remoteproc and needs to know if remoteproc crashes as soon as possible to stop queuing further data and also dump some debug statistics on the driver side that could potentially help in debug of why the remoteproc crashed. Also in the case with upcoming Wi-Fi 7 targets with multi-link operation, the driver might need to know that the remoteproc has crashed instantly to handle some multi-link specific handling. The ath11k/ath12k WLAN drivers today partially have support for handling such FATAL notification but it has not been upstreamed yet. Reference patch: https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.1.0/mac80211/patches/031-ath11k-print-stats-on-crash.patch -- event SUBSYS_PREPARE_FOR_FATAL_SHUTDOWN. Also, Mukesh mentioned earlier that in some MSM targets with PCIe where latency cannot be tolerated, a similar downstream patch adds support for "early notifier". If this patch is accepted, the early notifier can also be replaced to use the same NOTIFY_FATAL event from SSR Subdevice https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/7583d24de337aa1bf7c375a7da706af9b995b9a1#a840754ebb0e24e88adbf48177e1abd0830b72d2 https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/commit/257de41c63a5a51a081cc7887cdaa4a46e4d1744 Hi Bjorn, Gentle reminder for this patch. Thanks, Vignesh Thanks, Vignesh Regards, Bjorn
Re: [PATCH RFC v2 05/27] mm: page_alloc: Add an arch hook to allow prep_new_page() to fail
On 19.11.23 17:56, Alexandru Elisei wrote: Introduce arch_prep_new_page(), which will be used by arm64 to reserve tag storage for an allocated page. Reserving tag storage can fail, for example, if the tag storage page has a short pin on it, so allow prep_new_page() -> arch_prep_new_page() to similarly fail. But what are the side-effects of this? How does the calling code recover? E.g., what if we need to populate a page into user space, but that particular page we allocated fails to be prepared? So we inject a signal into that poor process? -- Cheers, David / dhildenb
Re: [PATCH RFC v2 06/27] mm: page_alloc: Allow an arch to hook early into free_pages_prepare()
On 19.11.23 17:57, Alexandru Elisei wrote: Add arch_free_pages_prepare() hook that is called before that page flags are cleared. This will be used by arm64 when explicit management of tag storage pages is enabled. Can you elaborate a bit what exactly will be done by that code with that information? -- Cheers, David / dhildenb
Re: [PATCH RFC v2 12/27] arm64: mte: Add tag storage pages to the MIGRATE_CMA migratetype
On 19.11.23 17:57, Alexandru Elisei wrote:
Add the MTE tag storage pages to the MIGRATE_CMA migratetype, which allows
the page allocator to manage them like regular pages.
Ths migratype lends the pages some very desirable properties:
* They cannot be longterm pinned, meaning they will always be migratable.
* The pages can be allocated explicitely by using their PFN (with
alloc_contig_range()) when they are needed to store tags.
Signed-off-by: Alexandru Elisei
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/mte_tag_storage.c | 68 +
include/linux/mmzone.h | 5 +++
mm/internal.h | 3 --
4 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fe8276fdc7a8..047487046e8f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2065,6 +2065,7 @@ config ARM64_MTE
if ARM64_MTE
config ARM64_MTE_TAG_STORAGE
bool "Dynamic MTE tag storage management"
+ select CONFIG_CMA
help
Adds support for dynamic management of the memory used by the hardware
for storing MTE tags. This memory, unlike normal memory, cannot be
diff --git a/arch/arm64/kernel/mte_tag_storage.c
b/arch/arm64/kernel/mte_tag_storage.c
index fa6267ef8392..427f4f1909f3 100644
--- a/arch/arm64/kernel/mte_tag_storage.c
+++ b/arch/arm64/kernel/mte_tag_storage.c
@@ -5,10 +5,12 @@
* Copyright (C) 2023 ARM Ltd.
*/
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -189,6 +191,14 @@ static int __init fdt_init_tag_storage(unsigned long node,
const char *uname,
return ret;
}
+ /* Pages are managed in pageblock_nr_pages chunks */
+ if (!IS_ALIGNED(tag_range->start | range_len(tag_range),
pageblock_nr_pages)) {
+ pr_err("Tag storage region 0x%llx-0x%llx not aligned to pageblock
size 0x%llx",
+ PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end),
+ PFN_PHYS(pageblock_nr_pages));
+ return -EINVAL;
+ }
+
ret = tag_storage_get_memory_node(node, &mem_node);
if (ret)
return ret;
@@ -254,3 +264,61 @@ void __init mte_tag_storage_init(void)
pr_info("MTE tag storage region management disabled");
}
}
+
+static int __init mte_tag_storage_activate_regions(void)
+{
+ phys_addr_t dram_start, dram_end;
+ struct range *tag_range;
+ unsigned long pfn;
+ int i, ret;
+
+ if (num_tag_regions == 0)
+ return 0;
+
+ dram_start = memblock_start_of_DRAM();
+ dram_end = memblock_end_of_DRAM();
+
+ for (i = 0; i < num_tag_regions; i++) {
+ tag_range = &tag_regions[i].tag_range;
+ /*
+* Tag storage region was clipped by arm64_bootmem_init()
+* enforcing addressing limits.
+*/
+ if (PFN_PHYS(tag_range->start) < dram_start ||
+ PFN_PHYS(tag_range->end) >= dram_end) {
+ pr_err("Tag storage region 0x%llx-0x%llx outside addressable
memory",
+ PFN_PHYS(tag_range->start),
PFN_PHYS(tag_range->end));
+ ret = -EINVAL;
+ goto out_disabled;
+ }
+ }
+
+ /*
+* MTE disabled, tag storage pages can be used like any other pages. The
+* only restriction is that the pages cannot be used by kexec because
+* the memory remains marked as reserved in the memblock allocator.
+*/
+ if (!system_supports_mte()) {
+ for (i = 0; i< num_tag_regions; i++) {
+ tag_range = &tag_regions[i].tag_range;
+ for (pfn = tag_range->start; pfn <= tag_range->end;
pfn++)
+ free_reserved_page(pfn_to_page(pfn));
+ }
+ ret = 0;
+ goto out_disabled;
+ }
+
+ for (i = 0; i < num_tag_regions; i++) {
+ tag_range = &tag_regions[i].tag_range;
+ for (pfn = tag_range->start; pfn <= tag_range->end; pfn +=
pageblock_nr_pages)
+ init_cma_reserved_pageblock(pfn_to_page(pfn));
+ totalcma_pages += range_len(tag_range);
+ }
You shouldn't be doing that manually in arm code. Likely you want some
cma.c helper for something like that.
But, can you elaborate on why you took this hacky (sorry) approach as
documented in the cover letter:
"The arm64 code manages this memory directly instead of using
cma_declare_contiguous/cma_alloc for performance reasons."
What is the exact problem?
--
Cheers,
David / dhildenb
Re: [PATCH RFC v2 13/27] arm64: mte: Make tag storage depend on ARCH_KEEP_MEMBLOCK
On 19.11.23 17:57, Alexandru Elisei wrote: Tag storage memory requires that the tag storage pages used for data are always migratable when they need to be repurposed to store tags. If ARCH_KEEP_MEMBLOCK is enabled, kexec will scan all non-reserved memblocks to find a suitable location for copying the kernel image. The kernel image, once loaded, cannot be moved to another location in physical memory. The initialization code for the tag storage reserves the memblocks for the tag storage pages, which means kexec will not use them, and the tag storage pages can be migrated at any time, which is the desired behaviour. However, if ARCH_KEEP_MEMBLOCK is not selected, kexec will not skip a region unless the memory resource has the IORESOURCE_SYSRAM_DRIVER_MANAGED flag, which isn't currently set by the tag storage initialization code. Make ARM64_MTE_TAG_STORAGE depend on ARCH_KEEP_MEMBLOCK to make it explicit that that the Kconfig option required for it to work correctly. Signed-off-by: Alexandru Elisei --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 047487046e8f..efa5b7958169 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2065,6 +2065,7 @@ config ARM64_MTE if ARM64_MTE config ARM64_MTE_TAG_STORAGE bool "Dynamic MTE tag storage management" + depends on ARCH_KEEP_MEMBLOCK select CONFIG_CMA help Adds support for dynamic management of the memory used by the hardware Doesn't arm64 select that unconditionally? Why is this required then? -- Cheers, David / dhildenb
Re: [PATCH RFC v2 14/27] arm64: mte: Disable dynamic tag storage management if HW KASAN is enabled
On 19.11.23 17:57, Alexandru Elisei wrote: To be able to reserve the tag storage associated with a page requires that the tag storage page can be migrated. When HW KASAN is enabled, the kernel allocates pages, which are now tagged, in non-preemptible contexts, which can make reserving the associate tag storage impossible. I assume that it's the only in-kernel user that actually requires tagged memory (besides for user space), correct? -- Cheers, David / dhildenb
Re: [PATCH RFC v2 15/27] arm64: mte: Check that tag storage blocks are in the same zone
On 19.11.23 17:57, Alexandru Elisei wrote:
alloc_contig_range() requires that the requested pages are in the same
zone. Check that this is indeed the case before initializing the tag
storage blocks.
Signed-off-by: Alexandru Elisei
---
arch/arm64/kernel/mte_tag_storage.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/kernel/mte_tag_storage.c
b/arch/arm64/kernel/mte_tag_storage.c
index 8b9bedf7575d..fd63430d4dc0 100644
--- a/arch/arm64/kernel/mte_tag_storage.c
+++ b/arch/arm64/kernel/mte_tag_storage.c
@@ -265,6 +265,35 @@ void __init mte_tag_storage_init(void)
}
}
+/* alloc_contig_range() requires all pages to be in the same zone. */
+static int __init mte_tag_storage_check_zone(void)
+{
+ struct range *tag_range;
+ struct zone *zone;
+ unsigned long pfn;
+ u32 block_size;
+ int i, j;
+
+ for (i = 0; i < num_tag_regions; i++) {
+ block_size = tag_regions[i].block_size;
+ if (block_size == 1)
+ continue;
+
+ tag_range = &tag_regions[i].tag_range;
+ for (pfn = tag_range->start; pfn <= tag_range->end; pfn +=
block_size) {
+ zone = page_zone(pfn_to_page(pfn));
+ for (j = 1; j < block_size; j++) {
+ if (page_zone(pfn_to_page(pfn + j)) != zone) {
+ pr_err("Tag storage block pages in different
zones");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+
+return 0;
+}
+
Looks like something that ordinary CMA provides. See cma_activate_area().
Can't we find a way to let CMA do CMA thingies and only be a user of
that? What would be required to make the performance issue you spelled
out in the cover letter be gone and not have to open-code that in arch code?
--
Cheers,
David / dhildenb
[mhiramat:topic/fprobe-on-fgraph] [function_graph] 1c96d64aa1: WARNING:at_kernel/trace/trace.c:#run_tracer_selftest
exc_overflow (arch/x86/kernel/traps.c:250) [ 10.967306][ T1] ? run_tracer_selftest (kernel/trace/trace.c:2030) [ 10.968289][ T1] register_tracer (kernel/trace/trace.c:2064 kernel/trace/trace.c:2187) [ 10.969155][ T1] ? init_graph_tracefs (kernel/trace/trace_functions_graph.c:1448) [ 10.969155][ T1] init_graph_trace (kernel/trace/trace_functions_graph.c:1462) [ 10.969155][ T1] do_one_initcall (init/main.c:1232) [ 10.969155][ T1] ? parameq (include/linux/fortify-string.h:214 kernel/params.c:98) [ 10.969155][ T1] do_initcalls (init/main.c:1293 init/main.c:1310) [ 10.969155][ T1] ? rest_init (init/main.c:1429) [ 10.969155][ T1] kernel_init_freeable (init/main.c:1549) [ 10.969155][ T1] kernel_init (init/main.c:1439) [ 10.969155][ T1] ret_from_fork (arch/x86/kernel/process.c:153) [ 10.969155][ T1] ? rest_init (init/main.c:1429) [ 10.973466][ T1] ret_from_fork_asm (arch/x86/entry/entry_32.S:741) [ 10.974376][ T1] entry_INT80_32 (arch/x86/entry/entry_32.S:947) [ 10.975233][T1] irq event stamp: 4679531 [ 10.976101][ T1] hardirqs last enabled at (4679541): console_unlock (arch/x86/include/asm/irqflags.h:42 arch/x86/include/asm/irqflags.h:77 arch/x86/include/asm/irqflags.h:135 kernel/printk/printk.c:347 kernel/printk/printk.c:2718 kernel/printk/printk.c:3037) [ 10.977685][ T1] hardirqs last disabled at (4679552): console_unlock (kernel/printk/printk.c:345 kernel/printk/printk.c:2718 kernel/printk/printk.c:3037) [ 10.979295][ T1] softirqs last enabled at (4679152): __do_softirq (arch/x86/include/asm/preempt.h:27 kernel/softirq.c:400 kernel/softirq.c:582) [ 10.980885][ T1] softirqs last disabled at (4679147): do_softirq_own_stack (arch/x86/kernel/irq_32.c:57 arch/x86/kernel/irq_32.c:147) [ 10.981739][T1] ---[ end trace ]--- [ 10.983191][T1] pinctrl core: initialized pinctrl subsystem The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20231124/202311241731.d1159c9f-oliver.s...@intel.com -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH 2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Sort ufs node
On Fri, Nov 24, 2023 at 04:54:20PM +0100, Krzysztof Kozlowski wrote: > On 24/11/2023 14:57, Jianhua Lu wrote: > > ufs node isn't in a right place, 'f' is front of 's', so move it to > > above usb node. > > Please not. > > If we change the order to match DTSI, then this patch would be wrong. > Acked. I will drop this patch. > Best regards, > Krzysztof >
[PATCH v2 1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Fix typos
There are two typos in this dtsi, so fix it.
classis -> chassis.
8070 -> 8060
Signed-off-by: Jianhua Lu
---
No changes in v2.
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 85e5cf3dc91e..3d4ea428e4cb 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -23,7 +23,7 @@
/delete-node/ &xbl_aop_mem;
/ {
- classis-type = "tablet";
+ chassis-type = "tablet";
/* required for bootloader to select correct board */
qcom,msm-id = ; /* SM8250 v2.1 */
@@ -114,7 +114,7 @@ vreg_s6c_0p88: smpc6-regulator {
};
reserved-memory {
- xbl_aop_mem: xbl-aop@8070 {
+ xbl_aop_mem: xbl-aop@8060 {
reg = <0x0 0x8060 0x0 0x26>;
no-map;
};
--
2.41.0
[PATCH v2 2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8150b type-c node
Add type-c node to feature otg function.
Signed-off-by: Jianhua Lu
---
No changes in v2.
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 3d4ea428e4cb..ba2119da1979 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "sm8250.dtsi"
#include "pm8150.dtsi"
#include "pm8150b.dtsi"
@@ -627,6 +628,37 @@ vol_up_n: vol-up-n-state {
};
};
+&pm8150b_typec {
+ vdd-pdphy-supply = <&vreg_l2a_3p1>;
+ status = "okay";
+
+ connector {
+ compatible = "usb-c-connector";
+
+ power-role = "source";
+ data-role = "dual";
+ self-powered;
+
+ source-pdos = ;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pm8150b_role_switch_in: endpoint {
+ remote-endpoint =
<&usb_1_role_switch_out>;
+ };
+ };
+ };
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
@@ -678,6 +710,10 @@ &usb_1_hsphy {
status = "okay";
};
+&usb_1_role_switch_out {
+ remote-endpoint = <&pm8150b_role_switch_in>;
+};
+
&ufs_mem_hc {
vcc-supply = <&vreg_l17a_3p0>;
vcc-max-microamp = <80>;
--
2.41.0
[PATCH v2 3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Enable usb_1 otg
Change dr_mode to otg and set usb_role_swith property to enable
usb otg.
Signed-off-by: Jianhua Lu
---
Changes in v2:
1. a new patch that I missed to generate.
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index ba2119da1979..6abca574398d 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -696,11 +696,12 @@ &usb_1 {
};
&usb_1_dwc3 {
- dr_mode = "peripheral";
+ dr_mode = "otg";
maximum-speed = "high-speed";
/* Remove USB3 phy */
phys = <&usb_1_hsphy>;
phy-names = "usb2-phy";
+ usb-role-switch;
};
&usb_1_hsphy {
--
2.41.0
