[PATCH v4] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium requires DSI
labibb regulators and panel dts nodes to be added.
It is also required to keep some of the regulators as
always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
Reviewed-by: Konrad Dybcio
---
v4: Added Konrad's reviewed-by from v3. Added over current
protection, pull-down and soft-start properties. Couldn't
boot with downstream max-microamp values, so skipped it.
Smoke tested on v5.12-rc5.
v3: Addressed Konrad's concerns. Configured labibb regulators
explicitly based on downstream microvolt values. Display
comes up fine with default discharge-resistor-kohms and
soft-start-us properties, so didn't touch them.
Smoke tested on next-20210209.
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 71 +++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..7d029425336e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@ vreg_l13a_2p95: ldo13 {
regulator-initial-mode = ;
};
+ vreg_l14a_1p8: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@ vreg_l26a_1p2: ldo26 {
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -200,6 +209,43 @@ _pas {
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+ {
+ status = "okay";
+ vdda-supply = <_l26a_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <_l14a_1p8>;
+ vddpos-supply = <>;
+ vddneg-supply = <>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+_out {
+ remote-endpoint = <_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+};
+
+_phy {
+ status = "okay";
+ vdds-supply = <_l1a_0p875>;
+};
+
{
protected-clocks = ,
,
@@ -215,6 +261,31 @@ zap-shader {
};
};
+ {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+ regulator-over-current-protection;
+ regulator-pull-down;
+ regulator-soft-start;
+ qcom,discharge-resistor-kohms = <300>;
+};
+
+ {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+ regulator-over-current-protection;
+ regulator-pull-down;
+ regulator-soft-start;
+};
+
+ {
+ status = "okay";
+};
+
+_mdp {
+ status = "okay";
+};
+
_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.25.1
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi Angelo,
On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
wrote:
>
> Il 10/02/21 09:18, Amit Pundir ha scritto:
> > From: Sumit Semwal
> >
> > Enabling the Display panel for beryllium requires DSI
> > labibb regulators and panel dts nodes to be added.
> > It is also required to keep some of the regulators as
> > always-on.
> >
> > Signed-off-by: Sumit Semwal
> > Signed-off-by: Amit Pundir
> > ---
>
> Hello!
> Your patch looks good, however, I have a few concerns...
>
> > + {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> I think you want to also configure overvoltage and overcurrent
> protection values for both LAB and IBB, as these regulators may be a bit
> dangerous if used without.
It turned out I can't boot if I set regulator-max-microamp lab/ibb
values from downstream DT. Verified it a few times and same result.
Here is the decompiled downstream DTB for reference:
https://pastebin.ubuntu.com/p/4nPxzq6zf7/, just in case.
I'm not sure if over current protection value is tied to max-microamp,
but I added it anyway along with pull-down and soft-start properties
in next version of this patch.
Regards,
Amit Pundir
> Besides that, even if it wouldn't be that dangerous, since the
> protection features are present, it would be nice to configure them
> properly as in the rare event that something bad happens, you would be
> able to save the hardware (or at least have a chance to!).
>
> > + {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> Same here.
>
> Yours,
> -- Angelo
Re: [PATCH v2 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
On Sat, 13 Mar 2021 at 05:13, Bjorn Andersson
wrote:
>
> The reserved-memory regions used for carrying firmware to be run on the
> various cores and co-processors in a Qualcomm platform differs in size,
> placement and presence based on each device's feature set and security
> configuration.
>
> Rather than providing some basic set that works on the MTP and then
> piecemeal patch this up on the various devices, push the configuration
> of these regions out to the individual device dts files.
>
Smoke tested on sdm845-xiaomi-beryllium.
Tested-by: Amit Pundir
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v1:
> - Added lost memory-region to the db845c wlan node, as spotted by Doug.
>
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 90 +--
> arch/arm64/boot/dts/qcom/sdm845-db845c.dts| 87 ++
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 87 ++
> .../boot/dts/qcom/sdm845-oneplus-common.dtsi | 78 +++-
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 45 ++
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 83 -
> .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 86 ++
> 7 files changed, 431 insertions(+), 125 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> index 216a74f0057c..71ef92fd8909 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -153,36 +153,66 @@ panel_in_edp: endpoint {
> * all modifications to the memory map (from sdm845.dtsi) in one place.
> */
>
> -/*
> - * Our mpss_region is 8MB bigger than the default one and that conflicts
> - * with venus_mem and cdsp_mem.
> - *
> - * For venus_mem we'll delete and re-create at a different address.
> - *
> - * cdsp_mem isn't used on cheza right now so we won't bother re-creating it;
> but
> - * that also means we need to delete cdsp_pas.
> - */
> -/delete-node/ _mem;
> -/delete-node/ _mem;
> -/delete-node/ _pas;
> -/delete-node/ _mem;
> -
> -/* Increase the size from 120 MB to 128 MB */
> -_region {
> - reg = <0 0x8e00 0 0x800>;
> -};
> -
> -/* Increase the size from 2MB to 8MB */
> -_mem {
> - reg = <0 0x88f0 0 0x80>;
> -};
> -
> / {
> reserved-memory {
> + tz_mem: memory@8620 {
> + reg = <0 0x8620 0 0x2d0>;
> + no-map;
> + };
> +
> + rmtfs_mem: memory@88f0 {
> + compatible = "qcom,rmtfs-mem";
> + reg = <0 0x88f0 0 0x80>;
> + no-map;
> +
> + qcom,client-id = <1>;
> + qcom,vmid = <15>;
> + };
> +
> + ipa_fw_mem: memory@8c40 {
> + reg = <0 0x8c40 0 0x1>;
> + no-map;
> + };
> +
> + ipa_gsi_mem: memory@8c41 {
> + reg = <0 0x8c41 0 0x5000>;
> + no-map;
> + };
> +
> + adsp_mem: memory@8c50 {
> + reg = <0 0x8c50 0 0x1a0>;
> + no-map;
> + };
> +
> + wlan_msa_mem: memory@8df0 {
> + reg = <0 0x8df0 0 0x10>;
> + no-map;
> + };
> +
> + mpss_region: memory@8e00 {
> + reg = <0 0x8e00 0 0x800>;
> + no-map;
> + };
> +
> venus_mem: memory@9600 {
> reg = <0 0x9600 0 0x50>;
> no-map;
> };
> +
> + mba_region: memory@9650 {
> + reg = <0 0x9650 0 0x20>;
> + no-map;
> + };
> +
> + slpi_mem: memory@9670 {
> + reg = <0 0x9670 0 0x140>;
> + no-map;
> + };
> +
> + spss_mem: memory@97b0 {
> + reg = <0 0x97b0 0 0x10>;
> + no-map;
> + };
> };
> };
>
> @@ -206,7 +236,6 @@ flash@0 {
> };
> };
>
> -
> _rsc {
> pm8998-rpmh-regulators {
> compatible = "qcom,pm8998-rpmh-regulators&qu
Re: [PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add audio support
On Sun, 14 Mar 2021 at 22:32, Joel Selvaraj wrote:
>
> This patch adds audio support for Xiaomi Poco F1 phone. Phone's primary
> Mic and 3.5mm Headphone jack are handled through the SDM845 sound card
> and WCD9340 codec.
>
Tested-by: Amit Pundir
> Signed-off-by: Joel Selvaraj
> ---
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 117 ++
> 1 file changed, 117 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> index 86cbae63eaf7..5b5786595cdb 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> @@ -5,6 +5,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "sdm845.dtsi"
> #include "pm8998.dtsi"
> #include "pmi8998.dtsi"
> @@ -240,6 +242,28 @@ resin {
> };
> };
>
> +/* QUAT I2S Uses 1 I2S SD Line for audio on TAS2559/60 amplifiers */
> + {
> + qi2s@22 {
> + reg = <22>;
> + qcom,sd-lines = <0>;
> + };
> +};
> +
> + {
> + dai@0 {
> + reg = <0>;
> + };
> +
> + dai@1 {
> + reg = <1>;
> + };
> +
> + dai@2 {
> + reg = <2>;
> + };
> +};
> +
> _id_0 {
> status = "okay";
> };
> @@ -257,6 +281,73 @@ _2 {
> cd-gpios = < 126 GPIO_ACTIVE_HIGH>;
> };
>
> + {
> + compatible = "qcom,db845c-sndcard";
> + pinctrl-0 = <_mi2s_active
> + _mi2s_sd0_active>;
> + pinctrl-names = "default";
> + model = "Xiaomi Poco F1";
> + audio-routing =
> + "RX_BIAS", "MCLK",
> + "AMIC1", "MIC BIAS1",
> + "AMIC2", "MIC BIAS2",
> + "AMIC3", "MIC BIAS3",
> + "MM_DL1", "MultiMedia1 Playback",
> + "MM_DL2", "MultiMedia2 Playback",
> + "MultiMedia3 Capture", "MM_UL3";
> +
> + mm1-dai-link {
> + link-name = "MultiMedia1";
> + cpu {
> + sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA1>;
> + };
> + };
> +
> + mm2-dai-link {
> + link-name = "MultiMedia2";
> + cpu {
> + sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA2>;
> + };
> + };
> +
> + mm3-dai-link {
> + link-name = "MultiMedia3";
> + cpu {
> + sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA3>;
> + };
> + };
> +
> + slim-dai-link {
> + link-name = "SLIM Playback";
> + cpu {
> + sound-dai = < SLIMBUS_0_RX>;
> + };
> +
> + platform {
> + sound-dai = <>;
> + };
> +
> + codec {
> + sound-dai = < 0>;
> + };
> + };
> +
> + slimcap-dai-link {
> + link-name = "SLIM Capture";
> + cpu {
> + sound-dai = < SLIMBUS_0_TX>;
> + };
> +
> + platform {
> + sound-dai = <>;
> + };
> +
> + codec {
> + sound-dai = < 1>;
> + };
> + };
> +};
> +
> {
> gpio-reserved-ranges = <0 4>, <81 4>;
>
> @@ -285,6 +376,15 @@ sdc2_card_det_n: sd-card-det-n {
> function = "gpio";
> bias-pull-up;
> };
> +
> + wcd_intr_default: wcd_intr_default {
> + pins = <54>;
> + function = "gpio";
> +
> + input-enable;
> + bias-pull-down;
> + drive-strength = <2>;
> + };
> };
>
> {
> @@ -345,6 +445,23 @@ _1_qmpphy {
> vdda-pll-supply = <_l1a_0p875>;
> };
>
> +{
> + pinctrl-0 = <_intr_default>;
> + pinctrl-names = "default";
> + clock-names = "extclk";
> + clocks = < RPMH_LN_BB_CLK2>;
> + reset-gpios = < 64 0>;
> + vdd-buck-supply = <_s4a_1p8>;
> + vdd-buck-sido-supply = <_s4a_1p8>;
> + vdd-tx-supply = <_s4a_1p8>;
> + vdd-rx-supply = <_s4a_1p8>;
> + vdd-io-supply = <_s4a_1p8>;
> + qcom,micbias1-microvolt = <270>;
> + qcom,micbias2-microvolt = <180>;
> + qcom,micbias3-microvolt = <270>;
> + qcom,micbias4-microvolt = <270>;
> +};
> +
> {
> status = "okay";
>
> --
> 2.25.1
>
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Fri, 12 Feb 2021 at 23:11, AngeloGioacchino Del Regno
wrote:
>
> Il 12/02/21 10:24, Amit Pundir ha scritto:
> > Hi,
> >
> > On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
> > wrote:
> >>
> >> Il 10/02/21 09:18, Amit Pundir ha scritto:
> >>> From: Sumit Semwal
> >>>
> >>> Enabling the Display panel for beryllium requires DSI
> >>> labibb regulators and panel dts nodes to be added.
> >>> It is also required to keep some of the regulators as
> >>> always-on.
> >>>
> >>> Signed-off-by: Sumit Semwal
> >>> Signed-off-by: Amit Pundir
> >>> ---
> >>
> >> Hello!
> >> Your patch looks good, however, I have a few concerns...
> >>
> >>> v3: Addressed Konrad's concerns. Configured labibb regulators
> >>> explicitly based on downstream microvolt values. Display
> >>> comes up fine with default discharge-resistor-kohms and
> >>> soft-start-us properties, so didn't touch them.
> >>> Smoke tested on next-20210209.
> >>> v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
> >>>
> >>>.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64
> >>> ++
> >>>1 file changed, 64 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> index 86cbae63eaf7..5ac049a247e1 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> @@ -157,6 +157,14 @@
> >>>regulator-initial-mode = ;
> >>>};
> >>>
> >>> + vreg_l14a_1p8: ldo14 {
> >>> + regulator-min-microvolt = <180>;
> >>> + regulator-max-microvolt = <180>;
> >>> + regulator-initial-mode = ;
> >>> + regulator-boot-on;
> >>> + regulator-always-on;
> >>> + };
> >>> +
> >>>vreg_l17a_1p3: ldo17 {
> >>>regulator-min-microvolt = <1304000>;
> >>>regulator-max-microvolt = <1304000>;
> >>> @@ -191,6 +199,7 @@
> >>>regulator-min-microvolt = <120>;
> >>>regulator-max-microvolt = <120>;
> >>>regulator-initial-mode = ;
> >>> + regulator-boot-on;
> >>>};
> >>>};
> >>>};
> >>> @@ -200,6 +209,43 @@
> >>>firmware-name = "qcom/sdm845/cdsp.mdt";
> >>>};
> >>>
> >>> + {
> >>> + status = "okay";
> >>> + vdda-supply = <_l26a_1p2>;
> >>> +
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + panel@0 {
> >>> + compatible = "tianma,fhd-video";
> >>> + reg = <0>;
> >>> + vddi0-supply = <_l14a_1p8>;
> >>> + vddpos-supply = <>;
> >>> + vddneg-supply = <>;
> >>> +
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> >>> +
> >>> + port {
> >>> + tianma_nt36672a_in_0: endpoint {
> >>> + remote-endpoint = <_out>;
> >>> + };
> >>> + };
> >>> + };
> >>> +};
> >>> +
> >>> +_out {
> >>> + remote-endpoint = <_nt36672a_in_0>;
> >>> + data-lanes = <0 1 2 3>;
> >>> +};
> >>> +
> >>> +_phy {
> >>> + status = "okay";
> >>> + vdds-supply = <_l1a_0p875>;
> >>> +};
> >>> +
> >>> {
> >>>protected-clocks = ,
> >>> ,
> &
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
wrote:
>
> Il 10/02/21 09:18, Amit Pundir ha scritto:
> > From: Sumit Semwal
> >
> > Enabling the Display panel for beryllium requires DSI
> > labibb regulators and panel dts nodes to be added.
> > It is also required to keep some of the regulators as
> > always-on.
> >
> > Signed-off-by: Sumit Semwal
> > Signed-off-by: Amit Pundir
> > ---
>
> Hello!
> Your patch looks good, however, I have a few concerns...
>
> > v3: Addressed Konrad's concerns. Configured labibb regulators
> > explicitly based on downstream microvolt values. Display
> > comes up fine with default discharge-resistor-kohms and
> > soft-start-us properties, so didn't touch them.
> > Smoke tested on next-20210209.
> > v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
> >
> > .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64
> > ++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > index 86cbae63eaf7..5ac049a247e1 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > @@ -157,6 +157,14 @@
> > regulator-initial-mode = ;
> > };
> >
> > + vreg_l14a_1p8: ldo14 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > + regulator-initial-mode = ;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > vreg_l17a_1p3: ldo17 {
> > regulator-min-microvolt = <1304000>;
> > regulator-max-microvolt = <1304000>;
> > @@ -191,6 +199,7 @@
> > regulator-min-microvolt = <120>;
> > regulator-max-microvolt = <120>;
> > regulator-initial-mode = ;
> > + regulator-boot-on;
> > };
> > };
> > };
> > @@ -200,6 +209,43 @@
> > firmware-name = "qcom/sdm845/cdsp.mdt";
> > };
> >
> > + {
> > + status = "okay";
> > + vdda-supply = <_l26a_1p2>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > + compatible = "tianma,fhd-video";
> > + reg = <0>;
> > + vddi0-supply = <_l14a_1p8>;
> > + vddpos-supply = <>;
> > + vddneg-supply = <>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> > +
> > + port {
> > + tianma_nt36672a_in_0: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +_out {
> > + remote-endpoint = <_nt36672a_in_0>;
> > + data-lanes = <0 1 2 3>;
> > +};
> > +
> > +_phy {
> > + status = "okay";
> > + vdds-supply = <_l1a_0p875>;
> > +};
> > +
> >{
> > protected-clocks = ,
> > ,
> > @@ -215,6 +261,24 @@
> > };
> > };
> >
> > + {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> I think you want to also configure overvoltage and overcurrent
> protection values for both LAB and IBB, as these regulators may be a bit
> dangerous if used without.
Can you point me to the relevant DT properties please. I didn't find
any DT properties which set the over voltage/current protection
properties explicitly in upstream as well as in downstream kernel.
Plus I also do not see "regulator-min/max-microamp" values set
downstream, otherwise I'd have used that as well atleast.
Regards,
Amit Pundir
> Besides that, even if it wouldn't be that dangerous, since the
> protection features are present, it would be nice to configure them
> properly as in the rare event that something bad happens, you would be
> able to save the hardware (or at least have a chance to!).
>
> > + {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> Same here.
>
> Yours,
> -- Angelo
>
> > + {
> > + status = "okay";
> > +};
> > +
> > +_mdp {
> > + status = "okay";
> > +};
> > +
> > _pil {
> > status = "okay";
> > firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> >
>
Re: [PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Mon, 8 Feb 2021 at 20:11, Konrad Dybcio wrote:
>
>
> >>> + ports {
> >>> + port@1 {
> >>> + endpoint {
> >>> + remote-endpoint = <_nt36672a_in_0>;
> >>> + data-lanes = <0 1 2 3>;
> >>> + };
> >>> + };
> >>> + };
> >> The endpoint has a label, you can simply use _out {};.
> > I didn't get what you meant there. Care to point to some reference dts
> > snippet please?
>
> sdm845.dtsi, L4139 as of v5.11-rc7:
>
>
> port@1 {
> reg = <1>;
> dsi0_out: endpoint {
> };
> };
>
>
> This means you can essentially do:
>
> _out {
>
> remote-endpoint = <_nt36672a_in_0>;
> lanes = <0 1 2 3>;
>
> };
>
>
> in your dt :)
>
Thank you. Added in v3.
>
> >>> + vddpos-supply = <>;
> >>> + vddneg-supply = <>;
> >> With Angelo's latest series [1] merged in, I reckon you should explicitly
> >> configure lab/ibb (like in [2]),
> >> as wrong settings (which CAN BE SET BY THE BOOTLOADER in some instances!!)
> >> can lead to hardware damage.
> > So iirc in the case of beryllium device, these regulators are pre set
> > by the bootloader and I can't find any reference of we
> > setting/resetting it explicitly to switch ON the panel and display. So
> > far default lab/ibb nodes are working fine for us and I'm hesitant to
> > tinker around anything regulator related that can potentially damage
> > the hardware. Having said that, I do see lab/ibb nodes being set in
> > the downstream dts, with relevant soft-start and discharge-resistor
> > properties and I can try switching to that once the new lab/ibb
> > changes land upstream.
> >
> > Regards,
> > Amit Pundir
> >
> I understand your concerns, however we actually did find out that at least
> one device had LAB/IBB set up by the bootloader in a way that could
> potentially damage the electronics, so I'm just making you aware. If it works
> as-is, it's probably OK.
Device seem to be booting fine with downstream labibb regulator node
changes, hence added them in v3 as well. Smoke tested on
5.11.0-rc7-next-20210209.
Regards,
Amit Pundir
>
>
> Konrad
>
[PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium requires DSI
labibb regulators and panel dts nodes to be added.
It is also required to keep some of the regulators as
always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
---
v3: Addressed Konrad's concerns. Configured labibb regulators
explicitly based on downstream microvolt values. Display
comes up fine with default discharge-resistor-kohms and
soft-start-us properties, so didn't touch them.
Smoke tested on next-20210209.
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64 ++
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..5ac049a247e1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@
regulator-initial-mode = ;
};
+ vreg_l14a_1p8: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -200,6 +209,43 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+ {
+ status = "okay";
+ vdda-supply = <_l26a_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <_l14a_1p8>;
+ vddpos-supply = <>;
+ vddneg-supply = <>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+_out {
+ remote-endpoint = <_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+};
+
+_phy {
+ status = "okay";
+ vdds-supply = <_l1a_0p875>;
+};
+
{
protected-clocks = ,
,
@@ -215,6 +261,24 @@
};
};
+ {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+};
+
+ {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+};
+
+ {
+ status = "okay";
+};
+
+_mdp {
+ status = "okay";
+};
+
_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.7.4
Re: [PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi Konrad,
On Thu, 4 Feb 2021 at 19:46, Konrad Dybcio wrote:
>
> Hi!
>
> >vreg_l14a_1p88: ldo14 {
> >+ regulator-min-microvolt = <180>;
> >+ regulator-max-microvolt = <180>;
>
> Should probably be renamed to vreg_l14a_1p8 then.
ack.
>
>
> >+ ports {
> >+ port@1 {
> >+ endpoint {
> >+ remote-endpoint = <_nt36672a_in_0>;
> >+ data-lanes = <0 1 2 3>;
> >+ };
> >+ };
> >+ };
>
> The endpoint has a label, you can simply use _out {};.
I didn't get what you meant there. Care to point to some reference dts
snippet please?
>
> >+ vddpos-supply = <>;
> >+ vddneg-supply = <>;
>
> With Angelo's latest series [1] merged in, I reckon you should explicitly
> configure lab/ibb (like in [2]),
> as wrong settings (which CAN BE SET BY THE BOOTLOADER in some instances!!)
> can lead to hardware damage.
So iirc in the case of beryllium device, these regulators are pre set
by the bootloader and I can't find any reference of we
setting/resetting it explicitly to switch ON the panel and display. So
far default lab/ibb nodes are working fine for us and I'm hesitant to
tinker around anything regulator related that can potentially damage
the hardware. Having said that, I do see lab/ibb nodes being set in
the downstream dts, with relevant soft-start and discharge-resistor
properties and I can try switching to that once the new lab/ibb
changes land upstream.
Regards,
Amit Pundir
>
>
>
> Konrad
>
> [1]
> https://lore.kernel.org/linux-arm-msm/20210119174421.226541-1-angelogioacchino.delre...@somainline.org/
> [2]
> https://github.com/SoMainline/linux/commit/4f4853b2e252b5f9d03e90119110aac80258fc53
[PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium phone (Xiaomi
Pocophone F1) requires DSI labibb regulators and panel
dts nodes to be added. It is also required to keep some
of the regulators as always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
---
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 58 ++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..034246b5c529 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@
regulator-initial-mode = ;
};
+ vreg_l14a_1p88: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -200,6 +209,47 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+ {
+ status = "okay";
+ vdda-supply = <_l26a_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <_l14a_1p88>;
+ vddpos-supply = <>;
+ vddneg-supply = <>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+_phy {
+ status = "okay";
+ vdds-supply = <_l1a_0p875>;
+};
+
{
protected-clocks = ,
,
@@ -215,6 +265,14 @@
};
};
+ {
+ status = "okay";
+};
+
+_mdp {
+ status = "okay";
+};
+
_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.7.4
Re: [PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Argh.. This patch is not formatted on top of mainline. It doesn't
apply cleanly. Sorry about that. I'll fix that in the next version.
Regards,
Amit Pundir
On Wed, 3 Feb 2021 at 15:29, Amit Pundir wrote:
>
> From: Sumit Semwal
>
> Enabling the Display panel for beryllium phone (Xiaomi
> Pocophone F1) requires DSI labibb regulators and panel
> dts nodes to be added. It is also required to keep some
> of the regulators as always-on.
>
> Signed-off-by: Sumit Semwal
> Signed-off-by: Amit Pundir
> ---
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 55
> ++
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> index cd15ae0347e8..e09effa555f1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> @@ -160,6 +160,14 @@
> regulator-initial-mode = ;
> };
>
> + vreg_l14a_1p88: ldo14 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> vreg_l17a_1p3: ldo17 {
> regulator-min-microvolt = <1304000>;
> regulator-max-microvolt = <1304000>;
> @@ -194,6 +202,7 @@
> regulator-min-microvolt = <120>;
> regulator-max-microvolt = <120>;
> regulator-initial-mode = ;
> + regulator-boot-on;
> };
> };
> };
> @@ -207,6 +216,44 @@
> firmware-name = "qcom/sdm845/cdsp.mdt";
> };
>
> + {
> + status = "okay";
> + vdda-supply = <_l26a_1p2>;
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <_nt36672a_in_0>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +
> + panel@0 {
> + compatible = "tianma,fhd-video";
> + reg = <0>;
> + vddi0-supply = <_l14a_1p88>;
> + vddpos-supply = <>;
> + vddneg-supply = <>;
> +
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port {
> + tianma_nt36672a_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +};
> +
> +_phy {
> + status = "okay";
> + vdds-supply = <_l1a_0p875>;
> +};
> +
> {
> protected-clocks = ,
>,
> @@ -274,6 +321,14 @@
>
> };
>
> + {
> + status = "okay";
> +};
> +
> +_mdp {
> + status = "okay";
> +};
> +
> _pil {
> status = "okay";
> firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> --
> 2.7.4
>
[PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium phone (Xiaomi
Pocophone F1) requires DSI labibb regulators and panel
dts nodes to be added. It is also required to keep some
of the regulators as always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
---
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 55 ++
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index cd15ae0347e8..e09effa555f1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -160,6 +160,14 @@
regulator-initial-mode = ;
};
+ vreg_l14a_1p88: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -194,6 +202,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -207,6 +216,44 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+ {
+ status = "okay";
+ vdda-supply = <_l26a_1p2>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <_l14a_1p88>;
+ vddpos-supply = <>;
+ vddneg-supply = <>;
+
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+_phy {
+ status = "okay";
+ vdds-supply = <_l1a_0p875>;
+};
+
{
protected-clocks = ,
,
@@ -274,6 +321,14 @@
};
+ {
+ status = "okay";
+};
+
+_mdp {
+ status = "okay";
+};
+
_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.7.4
Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
Hi Kalle, On Mon, 7 Dec 2020 at 22:25, Kalle Valo wrote: > > This is firmware version specific, right? There's also enum > ath10k_fw_features which is embedded within firmware-N.bin, we could add > a new flag there. But that means that a correct firmware-N.bin is needed > for each firmware version, not sure if that would work out. Just > throwing out ideas here. Apologies for this late reply. I was out for a while. If by that (the firmware version) you mean "QC_IMAGE_VERSION_STRING", then that may be a bit tricky. Pocophone F1 use the same firmware family version (WLAN.HL.2.0.XXX), used by Dragonboard 845c (which has Wi-Fi working upstream). Regards, Amit Pundir > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v9 0/3] Add Novatek NT36xxx touchscreen driver
On Thu, 29 Oct 2020 at 06:32, wrote: > > From: AngeloGioacchino Del Regno > > This patch series adds support for the Novatek NT36xxx Series' In-Cell > touchscreen (integrated into the DriverIC). > > This patch series has been tested against the following devices: > - Sony Xperia 10(SDM630 Ganges Kirin) > - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) > Tested the patch series on Xiaomi Poco F1 (SDM845 Beryllium, Novatek NT36672A IC). For the whole series: Tested-by: Amit Pundir Regards, Amit Pundir > Changes in v2: > - Fixed sparse warnings from lkp kernel test robot > > Changes in v3 (as requested by Dmitry Torokhov): > - Using shorthand u16/u32 (sorry for the overlook!) > - Now using more input and touchscreen APIs > - Fixed useless workqueue involvements > - Removed useless locking > - Switched reads and writes to use regmap > - Moved header contents to nt36xxx.c > - Fixed reset gpio handling > - Other cleanups > - P.S.: Thanks, Dmitry! > > Changes in v4: > - Fixed regmap read length for CRC_ERR_FLAG final check > - Fixed YAML binding, as requested by Krzysztof Kozlowski > > Changes in v5: > - Replaced subsystem maintainer's name with .. mine, > usage of additionalProperties to unevaluatedProperties > and a typo fix for reset-gpios as per Rob Herring's review > - Changed compatible string as per Krzysztof K. request > - Renamed the novatek,nt36xxx.yaml file to just nt36xxx.yaml > in order to now reflect the driver name instead of the DT > compatible > - Fixed blank line at EOF > > Changes in v6: > - Removed include of_gpio.h, added mod_devicetable.h and > gpio/consumer.h > - Added kerneldoc to relevant functions/enum > - Used traditional patterns for error checking where possible > - Documented calls to usleep/msleep > - Using be16_to_cpu / get_unaligned_be16 where possible > - Added helper for CRC error check on retrieved buffer > - Decreased indentation in the CRC reboot recovery function > - Removed instances of error code sum > - Dropped all likely/unlikely optimization as per request > - Removed redundant reset_gpio checks > - Dropped of_match_ptr and ifdefs for CONFIG_OF > > Changes in v7: > - Fixed typo in nt36xxx.c > > Changes in v8: > - Fixed typo reset-gpio -> reset-gpios in dt-bindings > > Changes in v9: > - Includes are now sorted > - Used proposed sizeof variable instead of sizeof type > - Fixed a return value check for common pattern > - Added NULL check to devm_kasprintf call > - Returning ret on probe function to be consistent > > AngeloGioacchino Del Regno (3): > dt-bindings: Add vendor prefix for Novatek Microelectronics Corp. > Input: Add Novatek NT36xxx touchscreen driver > dt-bindings: touchscreen: Add binding for Novatek NT36xxx series > driver > > .../bindings/input/touchscreen/nt36xxx.yaml | 59 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > drivers/input/touchscreen/Kconfig | 12 + > drivers/input/touchscreen/Makefile| 1 + > drivers/input/touchscreen/nt36xxx.c | 894 ++ > drivers/input/touchscreen/nt36xxx.h | 122 +++ > 6 files changed, 1090 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml > create mode 100644 drivers/input/touchscreen/nt36xxx.c > create mode 100644 drivers/input/touchscreen/nt36xxx.h > > -- > 2.28.0 >
Re: [v1] drm/msm/dpu: consider vertical front porch in the prefill bw calculation
On Wed, 25 Nov 2020 at 15:33, Kalyan Thota wrote: > > In case of panels with low vertical back porch, the prefill bw > requirement will be high as we will have less time(vbp+pw) to > fetch and fill the hw latency buffers before start of first line > in active period. > > For ex: > Say hw_latency_line_buffers = 24, and if blanking vbp+pw = 10 > Here we need to fetch 24 lines of data in 10 line times. > This will increase the bw to the ratio of linebuffers to blanking. > > DPU hw can also fetch data during vertical front porch provided > interface prefetch is enabled. Use vfp in the prefill calculation > as dpu driver enables prefetch if the blanking is not sufficient > to fill the latency lines. Tested on Xiaomi Poco F1 (sdm845). Tested-by: Amit Pundir > > Signed-off-by: Kalyan Thota > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > index 7ea90d2..315b999 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > @@ -151,7 +151,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, > u64 plane_bw; > u32 hw_latency_lines; > u64 scale_factor; > - int vbp, vpw; > + int vbp, vpw, vfp; > > pstate = to_dpu_plane_state(plane->state); > mode = >state->crtc->mode; > @@ -164,6 +164,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, > fps = drm_mode_vrefresh(mode); > vbp = mode->vtotal - mode->vsync_end; > vpw = mode->vsync_end - mode->vsync_start; > + vfp = mode->vsync_start - mode->vdisplay; > hw_latency_lines = dpu_kms->catalog->perf.min_prefill_lines; > scale_factor = src_height > dst_height ? > mult_frac(src_height, 1, dst_height) : 1; > @@ -176,7 +177,13 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, > src_width * hw_latency_lines * fps * fmt->bpp * > scale_factor * mode->vtotal; > > - do_div(plane_prefill_bw, (vbp+vpw)); > + if ((vbp+vpw) > hw_latency_lines) > + do_div(plane_prefill_bw, (vbp+vpw)); > + else if ((vbp+vpw+vfp) < hw_latency_lines) > + do_div(plane_prefill_bw, (vbp+vpw+vfp)); > + else > + do_div(plane_prefill_bw, hw_latency_lines); > + > > pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw); > } > -- > 2.7.4 >
Re: [Freedreno] [PATCH 3/3] drm/msm/dpu: add support for clk and bw scaling for display
Hi Kalyan, On Tue, 24 Nov 2020 at 18:27, wrote: > > On 2020-11-08 23:25, Amit Pundir wrote: > > On Tue, 4 Aug 2020 at 21:09, Rob Clark wrote: > >> > >> On Thu, Jul 16, 2020 at 4:36 AM Kalyan Thota > >> wrote: > >> > > >> > This change adds support to scale src clk and bandwidth as > >> > per composition requirements. > >> > > >> > Interconnect registration for bw has been moved to mdp > >> > device node from mdss to facilitate the scaling. > >> > > >> > Changes in v1: > >> > - Address armv7 compilation issues with the patch (Rob) > >> > > >> > Signed-off-by: Kalyan Thota > >> > >> Reviewed-by: Rob Clark > >> > > > > Hi Kalyan, Rob, > > > > This patch broke the display on the PocoF1 phone > > (sdm845-xiaomi-beryllium.dts) running AOSP. > > I can boot to UI but the display is frozen soon after that and > > dmesg is full of following errors: > > > > [drm:dpu_core_perf_crtc_update:397] [dpu error]crtc-65: failed to > > update bus bw vote > > [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: > > 7649746kb > 680kb > > [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance > > check -7 > > [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: > > 7649746kb > 680kb > > [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance > > check -7 > > [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: > > 7649746kb > 680kb > > [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance > > check -7 > > > > Here is the full dmesg https://pastebin.ubuntu.com/p/PcSdNgMnYw/. > > Georgi pointed out following patch but it didn't help, > > https://lore.kernel.org/dri-devel/20201027102304.945424-1-dmitry.barysh...@linaro.org/ > > Am I missing any other followup fix? > > > > Regards, > > Amit Pundir > > __ > > Hi Amit, > > Apologies for the delay. No worries at all. > > I have gone through the logs and referred to the below panel file for > the timings. > https://github.com/Matheus-Garbelini/Kernel-Sphinx-Pocophone-F1/blob/master/arch/arm64/boot/dts/qcom/dsi-panel-tianma-fhd-nt36672a-video.dtsi > > if the above is correct file, then below could be the possible root > cause. > > The panel back porch and pw is less and it is causing the prefill bw > requirement to shoot up per layer as currently we are not considering > front porch in the calculation. can you please try the attached patch in > the email as a solution and provide me the feedback, i'll post it as a > formal change. The attached patch worked for me. Thanks a lot for looking closely into this issue. Regards, Amit Pundir > > Thanks, > Kalyan > > _ > > Freedreno mailing list > > freedr...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/freedreno
[PATCH v2] ath10k: qmi: Skip host capability request for Xiaomi Poco F1
Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
message in ath10k_qmi_host_cap_send_sync(), but we can still
bring up WiFi services successfully on AOSP if we ignore it.
We suspect either the host cap is not implemented or there
may be firmware specific issues. Firmware version is
QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
quirk, then the host capability request does get accepted,
but we run into fatal "msa info req rejected" error and
WiFi interface doesn't come up.
Attempts are being made to debug the failure reasons but no
luck so far. Hence this device specific workaround instead
of checking for QMI_ERR_MALFORMED_MSG_V01 error message.
Tried ath10k/WCN3990/hw1.0/wlanmdsp.mbn from the upstream
linux-firmware project but it didn't help and neither did
building board-2.bin file from stock bdwlan* files.
This workaround will be removed once we have a viable fix.
Thanks to postmarketOS guys for catching this.
Signed-off-by: Amit Pundir
---
We dropped this workaround last time in the favor of
a generic dts quirk to skip host cap check. But that
is under under discussion for a while now,
https://lkml.org/lkml/2020/9/25/1119, so resending
this short term workaround for the time being.
v2: ath10k-check complained about a too long line last
time, so moved the comment to a new line.
drivers/net/wireless/ath/ath10k/qmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index ae6b1f402adf..1c58b0ff1d29 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -653,7 +653,9 @@ static int ath10k_qmi_host_cap_send_sync(struct ath10k_qmi
*qmi)
/* older FW didn't support this request, which is not fatal */
if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
- resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01) {
+ resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01 &&
+ /* Xiaomi Poco F1 workaround */
+ !of_machine_is_compatible("xiaomi,beryllium")) {
ath10k_err(ar, "host capability request rejected: %d\n",
resp.resp.error);
ret = -EINVAL;
goto out;
--
2.7.4
Re: [PATCH v9 0/3] Add Novatek NT36xxx touchscreen driver
Hi,
On Thu, 29 Oct 2020 at 06:32, wrote:
>
> From: AngeloGioacchino Del Regno
>
> This patch series adds support for the Novatek NT36xxx Series' In-Cell
> touchscreen (integrated into the DriverIC).
>
> This patch series has been tested against the following devices:
> - Sony Xperia 10(SDM630 Ganges Kirin)
> - Sony Xperia 10 Plus (SDM636 Ganges Mermaid)
Tested the patch series on Xiaomi Poco F1 (SDM845 Beryllium) using
Novatek NT36672A IC. May I suggest adding "novatek,nt36672a" in the
list of compatible of_device_id{} as well.
Regards,
Amit Pundir
>
> Changes in v2:
> - Fixed sparse warnings from lkp kernel test robot
>
> Changes in v3 (as requested by Dmitry Torokhov):
> - Using shorthand u16/u32 (sorry for the overlook!)
> - Now using more input and touchscreen APIs
> - Fixed useless workqueue involvements
> - Removed useless locking
> - Switched reads and writes to use regmap
> - Moved header contents to nt36xxx.c
> - Fixed reset gpio handling
> - Other cleanups
> - P.S.: Thanks, Dmitry!
>
> Changes in v4:
> - Fixed regmap read length for CRC_ERR_FLAG final check
> - Fixed YAML binding, as requested by Krzysztof Kozlowski
>
> Changes in v5:
> - Replaced subsystem maintainer's name with .. mine,
> usage of additionalProperties to unevaluatedProperties
> and a typo fix for reset-gpios as per Rob Herring's review
> - Changed compatible string as per Krzysztof K. request
> - Renamed the novatek,nt36xxx.yaml file to just nt36xxx.yaml
> in order to now reflect the driver name instead of the DT
> compatible
> - Fixed blank line at EOF
>
> Changes in v6:
> - Removed include of_gpio.h, added mod_devicetable.h and
> gpio/consumer.h
> - Added kerneldoc to relevant functions/enum
> - Used traditional patterns for error checking where possible
> - Documented calls to usleep/msleep
> - Using be16_to_cpu / get_unaligned_be16 where possible
> - Added helper for CRC error check on retrieved buffer
> - Decreased indentation in the CRC reboot recovery function
> - Removed instances of error code sum
> - Dropped all likely/unlikely optimization as per request
> - Removed redundant reset_gpio checks
> - Dropped of_match_ptr and ifdefs for CONFIG_OF
>
> Changes in v7:
> - Fixed typo in nt36xxx.c
>
> Changes in v8:
> - Fixed typo reset-gpio -> reset-gpios in dt-bindings
>
> Changes in v9:
> - Includes are now sorted
> - Used proposed sizeof variable instead of sizeof type
> - Fixed a return value check for common pattern
> - Added NULL check to devm_kasprintf call
> - Returning ret on probe function to be consistent
>
> AngeloGioacchino Del Regno (3):
> dt-bindings: Add vendor prefix for Novatek Microelectronics Corp.
> Input: Add Novatek NT36xxx touchscreen driver
> dt-bindings: touchscreen: Add binding for Novatek NT36xxx series
> driver
>
> .../bindings/input/touchscreen/nt36xxx.yaml | 59 ++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile| 1 +
> drivers/input/touchscreen/nt36xxx.c | 894 ++
> drivers/input/touchscreen/nt36xxx.h | 122 +++
> 6 files changed, 1090 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml
> create mode 100644 drivers/input/touchscreen/nt36xxx.c
> create mode 100644 drivers/input/touchscreen/nt36xxx.h
>
> --
> 2.28.0
>
Re: [PATCH 3/3] drm/msm/dpu: add support for clk and bw scaling for display
On Tue, 4 Aug 2020 at 21:09, Rob Clark wrote: > > On Thu, Jul 16, 2020 at 4:36 AM Kalyan Thota wrote: > > > > This change adds support to scale src clk and bandwidth as > > per composition requirements. > > > > Interconnect registration for bw has been moved to mdp > > device node from mdss to facilitate the scaling. > > > > Changes in v1: > > - Address armv7 compilation issues with the patch (Rob) > > > > Signed-off-by: Kalyan Thota > > Reviewed-by: Rob Clark > Hi Kalyan, Rob, This patch broke the display on the PocoF1 phone (sdm845-xiaomi-beryllium.dts) running AOSP. I can boot to UI but the display is frozen soon after that and dmesg is full of following errors: [drm:dpu_core_perf_crtc_update:397] [dpu error]crtc-65: failed to update bus bw vote [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: 7649746kb > 680kb [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance check -7 [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: 7649746kb > 680kb [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance check -7 [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: 7649746kb > 680kb [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance check -7 Here is the full dmesg https://pastebin.ubuntu.com/p/PcSdNgMnYw/. Georgi pointed out following patch but it didn't help, https://lore.kernel.org/dri-devel/20201027102304.945424-1-dmitry.barysh...@linaro.org/ Am I missing any other followup fix? Regards, Amit Pundir
Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
Hi Rob, Bjorn, Kalle, On Thu, 29 Oct 2020 at 19:10, Bjorn Andersson wrote: > > On Tue 29 Sep 14:08 CDT 2020, Rob Herring wrote: > > > On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote: > > > There are firmware versions which do not support host capability > > > QMI request. We suspect either the host cap is not implemented or > > > there may be firmware specific issues, but apparently there seem > > > to be a generation of firmware that has this particular behavior. > > > > > > For example, firmware build on Xiaomi Poco F1 (sdm845) phone: > > > "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1" > > > > > > If we do not skip the host cap QMI request on Poco F1, then we > > > get a QMI_ERR_MALFORMED_MSG_V01 error message in the > > > ath10k_qmi_host_cap_send_sync(). But this error message is not > > > fatal to the firmware nor to the ath10k driver and we can still > > > bring up the WiFi services successfully if we just ignore it. > > > > > > Hence introducing this DeviceTree quirk to skip host capability > > > QMI request for the firmware versions which do not support this > > > feature. > > > > So if you change the WiFi firmware, you may force a DT change too. Those > > are pretty independent things otherwise. > > > > Yes and that's not good. But I looked at somehow derive this from > firmware version numbers etc and it's not working out, so I'm out of > ideas for alternatives. > > > Why can't you just always ignore this error? If you can't deal with this > > entirely in the driver, then it should be part of the WiFi firmware so > > it's always in sync. > > > > Unfortunately the firmware versions I've hit this problem on has gone > belly up when receiving this request, that's why I asked Amit to add a > flag to skip it. So what is next for this DT quirk? I'm OK to go back to my previous of_machine_is_compatible() device specific hack, for now, https://patchwork.kernel.org/project/linux-wireless/patch/1600328501-8832-1-git-send-email-amit.pun...@linaro.org/ till we have a reasonable fix in place or receive a vendor firmware drop which fixes this problem (which I believe is highly unlikely though, for this 2+ years old device). Regards, Amit Pundir > > That said, in the devices I've hit this I've managed to get newer > firmware working, which doesn't have either problem. > > Regards, > Bjorn
Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
On Wed, 30 Sep 2020 at 00:38, Rob Herring wrote: > > On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote: > > There are firmware versions which do not support host capability > > QMI request. We suspect either the host cap is not implemented or > > there may be firmware specific issues, but apparently there seem > > to be a generation of firmware that has this particular behavior. > > > > For example, firmware build on Xiaomi Poco F1 (sdm845) phone: > > "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1" > > > > If we do not skip the host cap QMI request on Poco F1, then we > > get a QMI_ERR_MALFORMED_MSG_V01 error message in the > > ath10k_qmi_host_cap_send_sync(). But this error message is not > > fatal to the firmware nor to the ath10k driver and we can still > > bring up the WiFi services successfully if we just ignore it. > > > > Hence introducing this DeviceTree quirk to skip host capability > > QMI request for the firmware versions which do not support this > > feature. > > So if you change the WiFi firmware, you may force a DT change too. Those > are pretty independent things otherwise. This is a valid concern and I'm not sure about the other devices, but on PocoF1 I have tried all the three released firmware version updates: WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1 WLAN.HL.2.0.c3-00445-QCAHLSWMTPLZ-1 WLAN.HL.2.0.c3-00534-QCAHLSWMTPLZ-1 and none of them works without this skip host-cap patch or equivalent hack. PocoF1 is already 2+ years old device and sadly I do not expect any major vendor update coming its way. > > Why can't you just always ignore this error? If you can't deal with this > entirely in the driver, then it should be part of the WiFi firmware so > it's always in sync. I don't know the technical details of the ath10k/qmi driver, but I'm OK if we just ignore the return value of ath10k_qmi_host_cap_send_sync() and move along. Regards, Amit Pundir > > Rob
Re: [PATCH v2 2/3] Input: Add Novatek NT36xxx touchscreen driver
On Tue, 29 Sep 2020 at 03:21, Dmitry Torokhov wrote: > > On Mon, Sep 28, 2020 at 03:18:18PM +0530, Amit Pundir wrote: > > On Sun, 27 Sep 2020 at 18:06, wrote: > > > > > > From: AngeloGioacchino Del Regno > > > > > > This is a driver for the Novatek in-cell touch controller and > > > supports various chips from the NT36xxx family, currently > > > including NT36525, NT36672A, NT36676F, NT36772 and NT36870. > > > > > > Functionality like wake gestures and firmware flashing is not > > > included: I am not aware of any of these DrIC+Touch combo > > > chips not including a non-volatile memory and it should be > > > highly unlikely to find one, since the touch firmware is > > > embedded into the DriverIC one, which is obviously necessary > > > to drive the display unit. > > > > > > However, the necessary address for the firmware update > > > procedure was included into the address table in this driver > > > so, in the event that someone finds the need to implement it > > > for a reason or another, it will be pretty straightforward to. > > > > > > This driver is lightly based on the downstream implementation [1]. > > > [1] https://github.com/Rasenkai/caf-tsoft-Novatek-nt36xxx > > > > > > > This is so cool! > > > > Xiaomi PocoF1 phone uses same family touchscreen IC and I could > > test this series on that phone as well. > > > > However I do have to make a minor change to get it working. The > > downstream driver and even the github code you linked above use > > GPIO mapped IRQ, and I had to switch to that to get touchscreen > > working with your driver > > https://github.com/pundiramit/linux/commit/0a73eb656c1e80787dc195641ce7b0076fddb38e. > > I wonder if I'm missing any devicetree property other than interrupts? > > Simply specifying GPIO controller/pin as interrupt property should work, > there should be no need to parse custom GPIO property and convert it to > IRQ in the driver. > Indeed. I don't know what was tripping me off yesterday, but I got it working today with interrupt properties. Thank you. Regards, Amit Pundir > Thanks. > > -- > Dmitry
Re: [PATCH v2 2/3] Input: Add Novatek NT36xxx touchscreen driver
On Sun, 27 Sep 2020 at 18:06, wrote:
>
> From: AngeloGioacchino Del Regno
>
> This is a driver for the Novatek in-cell touch controller and
> supports various chips from the NT36xxx family, currently
> including NT36525, NT36672A, NT36676F, NT36772 and NT36870.
>
> Functionality like wake gestures and firmware flashing is not
> included: I am not aware of any of these DrIC+Touch combo
> chips not including a non-volatile memory and it should be
> highly unlikely to find one, since the touch firmware is
> embedded into the DriverIC one, which is obviously necessary
> to drive the display unit.
>
> However, the necessary address for the firmware update
> procedure was included into the address table in this driver
> so, in the event that someone finds the need to implement it
> for a reason or another, it will be pretty straightforward to.
>
> This driver is lightly based on the downstream implementation [1].
> [1] https://github.com/Rasenkai/caf-tsoft-Novatek-nt36xxx
>
This is so cool!
Xiaomi PocoF1 phone uses same family touchscreen IC and I could
test this series on that phone as well.
However I do have to make a minor change to get it working. The
downstream driver and even the github code you linked above use
GPIO mapped IRQ, and I had to switch to that to get touchscreen
working with your driver
https://github.com/pundiramit/linux/commit/0a73eb656c1e80787dc195641ce7b0076fddb38e.
I wonder if I'm missing any devicetree property other than interrupts?
Regards,
Amit Pundir
> Signed-off-by: AngeloGioacchino Del Regno
> ---
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/nt36xxx.c | 742
> drivers/input/touchscreen/nt36xxx.h | 122 +
> 4 files changed, 877 insertions(+)
> create mode 100644 drivers/input/touchscreen/nt36xxx.c
> create mode 100644 drivers/input/touchscreen/nt36xxx.h
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 35c867b2d9a7..6d118b967021 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -605,6 +605,18 @@ config TOUCHSCREEN_MTOUCH
> To compile this driver as a module, choose M here: the
> module will be called mtouch.
>
> +config TOUCHSCREEN_NT36XXX
> + tristate "Novatek NT36XXX In-Cell I2C touchscreen controller"
> + depends on I2C
> + help
> + Say Y here if you have a Novatek NT36xxx series In-Cell
> + touchscreen connected to your system over I2C.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called nt36xxx.
> +
> config TOUCHSCREEN_IMX6UL_TSC
> tristate "Freescale i.MX6UL touchscreen controller"
> depends on (OF && GPIOLIB) || COMPILE_TEST
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index 30d1e1b42492..424a555e03d5 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_TOUCHSCREEN_MIGOR) += migor_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MMS114) += mms114.o
> obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
> obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o
> +obj-$(CONFIG_TOUCHSCREEN_NT36XXX) += nt36xxx.o
> obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o
> obj-$(CONFIG_TOUCHSCREEN_HP7XX)+= jornada720_ts.o
> obj-$(CONFIG_TOUCHSCREEN_IPAQ_MICRO) += ipaq-micro-ts.o
> diff --git a/drivers/input/touchscreen/nt36xxx.c
> b/drivers/input/touchscreen/nt36xxx.c
> new file mode 100644
> index ..57e189938d12
> --- /dev/null
> +++ b/drivers/input/touchscreen/nt36xxx.c
> @@ -0,0 +1,742 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2010 - 2017 Novatek, Inc.
> + * Copyright (C) 2020 AngeloGioacchino Del Regno
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "nt36xxx.h"
> +
> +static const struct nt36xxx_mem_map nt36xxx_memory_maps[] = {
> + [NT36525_IC] = { 0x11a00, 0x1, 0x12000, 0x14000, 0x14002 },
> + [NT36672A_IC] = { 0x21c00, 0x2, 0x23000, 0x24000, 0x24002 },
> + [NT36676F_IC] = { 0x11a00, 0x1, 0x12000, 0x14000, 0x14002 },
> + [NT36772_IC] = { 0x11e00, 0x1, 0x12000, 0x14000, 0x14002 },
> + [NT36870_IC] = { 0x25000, 0x2, 0x23000, 0x24000, 0x24002 },
> +};
> +
> +static const struct nt36xxx_trim_table trim_id_table[] = {
> + {
> +.id =
Re: [PATCH] ath10k: qmi: Skip host capability request for Xiaomi Poco F1
On Fri, 25 Sep 2020 at 20:57, Bjorn Andersson
wrote:
>
> On Thu 24 Sep 11:31 CDT 2020, Kalle Valo wrote:
>
> > Amit Pundir writes:
> >
> > > Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
> > > phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
> > > message in ath10k_qmi_host_cap_send_sync(), but we can still
> > > bring up WiFi services successfully on AOSP if we ignore it.
> > >
> > > We suspect either the host cap is not implemented or there
> > > may be firmware specific issues. Firmware version is
> > > QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
> > >
> > > qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > > quirk, then the host capability request does get accepted,
> > > but we run into fatal "msa info req rejected" error and
> > > WiFi interface doesn't come up.
> > >
> > > Attempts are being made to debug the failure reasons but no
> > > luck so far. Hence this device specific workaround instead
> > > of checking for QMI_ERR_MALFORMED_MSG_V01 error message.
> > > Tried ath10k/WCN3990/hw1.0/wlanmdsp.mbn from the upstream
> > > linux-firmware project but it didn't help and neither did
> > > building board-2.bin file from stock bdwlan* files.
> > >
> > > This workaround will be removed once we have a viable fix.
> > > Thanks to postmarketOS guys for catching this.
> > >
> > > Signed-off-by: Amit Pundir
> >
> > Bjorn, is this ok to take?
> >
>
> As I wrote in the answer to Amit I think we should introduce a generic
> quirk to skip host_cap instead.
>
> So if you pick this up (which is an ok short term workaround) I think we
> should revert it once we have a generic mechanism.
Hi Bjorn, just sent out a generic skip quirk for review.
Regards,
Amit Pundir
>
> Regards,
> Bjorn
>
> > > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > > @@ -651,7 +651,8 @@ static int ath10k_qmi_host_cap_send_sync(struct
> > > ath10k_qmi *qmi)
> > >
> > > /* older FW didn't support this request, which is not fatal */
> > > if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
> > > - resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01) {
> > > + resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01 &&
> > > + !of_machine_is_compatible("xiaomi,beryllium")) { /* Xiaomi Poco
> > > F1 workaround */
> > > ath10k_err(ar, "host capability request rejected: %d\n",
> > > resp.resp.error);
> >
> > ath10k-check complained about a too long line, so in the pending branch
> > I moved the comment before the if statement.
> >
> > --
> > https://patchwork.kernel.org/project/linux-wireless/list/
> >
> > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
There are firmware versions which do not support host capability
QMI request. We suspect either the host cap is not implemented or
there may be firmware specific issues, but apparently there seem
to be a generation of firmware that has this particular behavior.
For example, firmware build on Xiaomi Poco F1 (sdm845) phone:
"QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
If we do not skip the host cap QMI request on Poco F1, then we
get a QMI_ERR_MALFORMED_MSG_V01 error message in the
ath10k_qmi_host_cap_send_sync(). But this error message is not
fatal to the firmware nor to the ath10k driver and we can still
bring up the WiFi services successfully if we just ignore it.
Hence introducing this DeviceTree quirk to skip host capability
QMI request for the firmware versions which do not support this
feature.
Suggested-by: Bjorn Andersson
Signed-off-by: Amit Pundir
---
.../devicetree/bindings/net/wireless/qcom,ath10k.txt| 5 +
drivers/net/wireless/ath/ath10k/qmi.c | 13 ++---
drivers/net/wireless/ath/ath10k/snoc.c | 3 +++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
4 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 65ee68efd574..135c7ecd4487 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -86,6 +86,11 @@ Optional properties:
Value type:
Definition: Quirk specifying that the firmware expects the 8bit version
of the host capability QMI request
+- qcom,snoc-host-cap-skip-quirk:
+ Usage: Optional
+ Value type:
+ Definition: Quirk specifying that the firmware wants to skip the host
+ capability QMI request
- qcom,xo-cal-data: xo cal offset to be configured in xo trim register.
- qcom,msa-fixed-perm: Boolean context flag to disable SCM call for statically
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index 5468a41e928e..5adff7695e18 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -770,6 +770,7 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi
*qmi)
static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
{
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
int ret;
ret = ath10k_qmi_ind_register_send_sync_msg(qmi);
@@ -781,9 +782,15 @@ static void ath10k_qmi_event_server_arrive(struct
ath10k_qmi *qmi)
return;
}
- ret = ath10k_qmi_host_cap_send_sync(qmi);
- if (ret)
- return;
+ /*
+* Skip the host capability request for the firmware versions which
+* do not support this feature.
+*/
+ if (!test_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, _snoc->flags)) {
+ ret = ath10k_qmi_host_cap_send_sync(qmi);
+ if (ret)
+ return;
+ }
ret = ath10k_qmi_msa_mem_info_send_sync_msg(qmi);
if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c
b/drivers/net/wireless/ath/ath10k/snoc.c
index 354d49b1cd45..4efbf1339c80 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -1281,6 +1281,9 @@ static void ath10k_snoc_quirks_init(struct ath10k *ar)
if (of_property_read_bool(dev->of_node,
"qcom,snoc-host-cap-8bit-quirk"))
set_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, _snoc->flags);
+
+ if (of_property_read_bool(dev->of_node,
"qcom,snoc-host-cap-skip-quirk"))
+ set_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, _snoc->flags);
}
int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h
b/drivers/net/wireless/ath/ath10k/snoc.h
index a3dd06f6ac62..2a0045f0af7e 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -47,6 +47,7 @@ enum ath10k_snoc_flags {
ATH10K_SNOC_FLAG_UNREGISTERING,
ATH10K_SNOC_FLAG_RECOVERY,
ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK,
+ ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK,
};
struct clk_bulk_data;
--
2.7.4
Re: [PATCH] ath10k: qmi: Skip host capability request for Xiaomi Poco F1
On Thu, 17 Sep 2020 at 21:35, Bjorn Andersson
wrote:
>
> On Thu 17 Sep 02:41 CDT 2020, Amit Pundir wrote:
>
> > Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
> > phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
> > message in ath10k_qmi_host_cap_send_sync(), but we can still
> > bring up WiFi services successfully on AOSP if we ignore it.
> >
> > We suspect either the host cap is not implemented or there
> > may be firmware specific issues. Firmware version is
> > QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
> >
> > qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > quirk, then the host capability request does get accepted,
> > but we run into fatal "msa info req rejected" error and
> > WiFi interface doesn't come up.
> >
>
> What happens if you skip sending the host-cap message? I had one
> firmware version for which I implemented a
> "qcom,snoc-host-cap-skip-quirk".
>
> But testing showed that the link was pretty unusable - pushing any real
> amount of data would cause it to silently stop working - and I realized
> that I could use the linux-firmware wlanmdsp.mbn instead, which works
> great on all my devices...
I skipped the ath10k_qmi_host_cap_send_sync block altogether
(if that is what you meant by qcom,snoc-host-cap-skip-quirk) and
so far did not run into any issues with youtube auto-playback loop
(3+ hours and counting). Does that count as a valid use case?
Otherwise let me know how could I reproduce a reasonable test
setup?
>
> > Attempts are being made to debug the failure reasons but no
> > luck so far. Hence this device specific workaround instead
> > of checking for QMI_ERR_MALFORMED_MSG_V01 error message.
> > Tried ath10k/WCN3990/hw1.0/wlanmdsp.mbn from the upstream
> > linux-firmware project but it didn't help and neither did
> > building board-2.bin file from stock bdwlan* files.
> >
>
> "Didn't work" as in the wlanmdsp.mbn from linux-firmware failed to load
> or some laer problem?
While using the wlanmdsp.mbn from linux-firmware, I run into
the following crash 4 times before tqftpserv service gets killed
eventually:
[ 46.504502] qcom-q6v5-mss 408.remoteproc: fatal error received:
dog_virtual_root.c:89:User-PD grace timer expired for wlan_process
(ASID: 1)
[ 46.504527] remoteproc remoteproc0: crash detected in
408.remoteproc: type fatal error
[ 46.504558] remoteproc remoteproc0: handling crash #1 in 408.remoteproc
[ 46.504563] remoteproc remoteproc0: recovering 408.remoteproc
[ 56.542400] 408.remoteproc:glink-edge: intent request timed out
[ 56.644617] qcom-q6v5-mss 408.remoteproc: port failed halt
[ 56.652321] remoteproc remoteproc0: stopped remote processor
408.remoteproc
[ 59.017963] qcom-q6v5-mss 408.remoteproc: MBA booted without
debug policy, loading mpss
[ 61.514552] remoteproc remoteproc0: remote processor
408.remoteproc is now up
< snip >
[ 214.161946] failed to send del client cmd
[ 214.161952] failed while handling packet from 1:16689
[ 214.185826] failed to send del client cmd
[ 214.185832] failed while handling packet from 1:16688
[ 214.201951] failed to send del client cmd
< snip >
[ 219.682148] failed to send del client cmd
[ 219.682154] failed while handling packet from 1:16394
[ 219.714707] init: Service 'tqftpserv' (pid 321) received signal 6
oneshot service took 215.852005 seconds in background
[ 219.714754] init: Sending signal 9 to service 'tqftpserv' (pid 321)
process group...
Regards,
Amit Pundir
>
> Regards,
> Bjorn
>
> > This workaround will be removed once we have a viable fix.
> > Thanks to postmarketOS guys for catching this.
> >
> > Signed-off-by: Amit Pundir
> > ---
> > Device-tree for Xiaomi Poco F1(Beryllium) got merged in
> > qcom/arm64-for-5.10 last week
> > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?id=77809cf74a8c
> >
> > drivers/net/wireless/ath/ath10k/qmi.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
> > b/drivers/net/wireless/ath/ath10k/qmi.c
> > index 0dee1353d395..37c5350eb8b1 100644
> > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > @@ -651,7 +651,8 @@ static int ath10k_qmi_host_cap_send_sync(struct
> > ath10k_qmi *qmi)
> >
> > /* older FW didn't support this request, which is not fatal */
> > if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
> > - resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01) {
> > + resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01 &&
> > + !of_machine_is_compatible("xiaomi,beryllium")) { /* Xiaomi Poco
> > F1 workaround */
> > ath10k_err(ar, "host capability request rejected: %d\n",
> > resp.resp.error);
> > ret = -EINVAL;
> > goto out;
> > --
> > 2.7.4
> >
[PATCH] ath10k: qmi: Skip host capability request for Xiaomi Poco F1
Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
message in ath10k_qmi_host_cap_send_sync(), but we can still
bring up WiFi services successfully on AOSP if we ignore it.
We suspect either the host cap is not implemented or there
may be firmware specific issues. Firmware version is
QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
quirk, then the host capability request does get accepted,
but we run into fatal "msa info req rejected" error and
WiFi interface doesn't come up.
Attempts are being made to debug the failure reasons but no
luck so far. Hence this device specific workaround instead
of checking for QMI_ERR_MALFORMED_MSG_V01 error message.
Tried ath10k/WCN3990/hw1.0/wlanmdsp.mbn from the upstream
linux-firmware project but it didn't help and neither did
building board-2.bin file from stock bdwlan* files.
This workaround will be removed once we have a viable fix.
Thanks to postmarketOS guys for catching this.
Signed-off-by: Amit Pundir
---
Device-tree for Xiaomi Poco F1(Beryllium) got merged in
qcom/arm64-for-5.10 last week
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?id=77809cf74a8c
drivers/net/wireless/ath/ath10k/qmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index 0dee1353d395..37c5350eb8b1 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -651,7 +651,8 @@ static int ath10k_qmi_host_cap_send_sync(struct ath10k_qmi
*qmi)
/* older FW didn't support this request, which is not fatal */
if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
- resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01) {
+ resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01 &&
+ !of_machine_is_compatible("xiaomi,beryllium")) { /* Xiaomi Poco F1
workaround */
ath10k_err(ar, "host capability request rejected: %d\n",
resp.resp.error);
ret = -EINVAL;
goto out;
--
2.7.4
[RESEND][PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all.
Signed-off-by: Amit Pundir
---
My WIP tree with a few out-of-tree patches to support
display, touchscreen, wifi, audio etc is here:
https://github.com/pundiramit/linux/commits/beryllium-mainline
v6: Renamed dts file to include vendor (xiaomi) name. Moved
reserved memory changes in the main node. Renamed model to
phone's pretty name. Removed the mmc drive strength comment
to avoid further confusion. Sorted the entries in alphabetical
order, but additional pinctrl entries are still defined at the
end to align with the upstream db845c dts.
v5: Bumped _mem size from 0x2d0 to 0x490 (to include
downstream _region), all the way up to _mem.
v4: Added more downstream reserved memory regions. It probably
need more work, but for now I see adsp/cdsp/wlan remoteprocs
powering up properly. Removed the regulator nodes not
required for the device, as suggested by Bjorn. Also added
couple of clocks to protected clocks, which is needed for
display to work.
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 380 +
2 files changed, 381 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d8f1466e6758..9adc269252d3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -30,6 +30,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-xiaomi-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8250-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
new file mode 100644
index ..86cbae63eaf7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/*
+ * Delete following upstream (sdm845.dtsi) reserved
+ * memory mappings which are different in this device.
+ */
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _msa_mem;
+/delete-node/ _region;
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _region;
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _mem;
+
+/ {
+ model = "Xiaomi Pocophone F1";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ /* Reserved memory changes from downstream */
+ reserved-memory {
+ tz_mem: memory@8620 {
+ reg = <0 0x8620 0 0x490>;
+ no-map;
+ };
+
+ adsp_mem: memory@8c50 {
+
Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings
On Fri, 4 Sep 2020 at 21:25, Bjorn Andersson wrote: > > Based on previous attempts and discussions this is the latest attempt at > inheriting stream mappings set up by the bootloader, for e.g. boot splash or > efifb. > > Per Will's request this builds on the work by Jordan and Rob for the Adreno > SMMU support. It applies cleanly ontop of v16 of their series, which can be > found at > https://lore.kernel.org/linux-arm-msm/20200901164707.2645413-1-robdcl...@gmail.com/ > Boot tested the series on Xiaomi Poco F1 phone (sdm845) Tested-by: Amit Pundir > Bjorn Andersson (8): > iommu/arm-smmu: Refactor context bank allocation > iommu/arm-smmu: Delay modifying domain during init > iommu/arm-smmu: Consult context bank allocator for identify domains > iommu/arm-smmu-qcom: Emulate bypass by using context banks > iommu/arm-smmu-qcom: Consistently initialize stream mappings > iommu/arm-smmu: Add impl hook for inherit boot mappings > iommu/arm-smmu: Provide helper for allocating identity domain > iommu/arm-smmu-qcom: Setup identity domain for boot mappings > > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 111 ++- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 122 ++--- > drivers/iommu/arm/arm-smmu/arm-smmu.h | 14 ++- > 3 files changed, 205 insertions(+), 42 deletions(-) > > -- > 2.28.0 >
Re: [PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
On Mon, 31 Aug 2020 at 13:28, Konrad Dybcio wrote: > > > Hi Konrad, > > > > I couldn't find answer to your question around missing > > (regulatorname)-supply properties. Need help in figuring out that > > part. > > When the phone boots up and RPM(H) kicks in, you should see regulators > probing like "s1 supplied by foo". Without the *-supply stuff, you > will likely get "supplied by regulator-dummy". This happens here [1] > and to my knowledge it is the "eletrical wiring" for Linux, as in it > makes Linux aware of which regulators are connected electrically to > the same supply (so that kernel knows when the supply is on and what > voltage it's at). For qcom platforms, this is common per-pmic (afaik, > please check if you are able to!), so you can likely just copy-paste > that part from msm8998-mtp.dtsi, which also uses pm(i)8998. Thank you for the pointer. I dug around the vph_pwr fixed-regulator node used by fellow sdm845 devices. I assume it is safe to copy it from sdm845-mtp but I couldn't verify it in the downstream device-tree, so I'm a bit hesitant. My main concern is that I don't want to burn down my only device :) I did find a few regulator nodes downstream which matches with upstream sdm845-mtp but since I'm not using any of them in my beryllium dts, I'm going to skip them for now. As you pointed out, in case of regulator lookup failure Linux will fall back to dummy regulators, which is working fine for me so far. Also I see that vdd-*-supply properties are optional according to Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt, so I assume it is safe to skip them? Regards, Amit Pundir > > Konrad
Re: [PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Hi Konrad,
I couldn't find answer to your question around missing
(regulatorname)-supply properties. Need help in figuring out that
part.
Regards,
Amit Pundir
On Mon, 31 Aug 2020 at 10:54, Amit Pundir wrote:
>
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS, USB-C (peripheral),
> microSD card and Vol+/Vol-/power keys. Bluetooth should work
> too but couldn't be verified from adb command line, it is
> verified when enabled from UI with few WIP display patches.
>
> Just like initial db845c support, initializing the SMMU is
> clearing the mapping used for the splash screen framebuffer,
> which causes the device to hang during boot and recovery
> needs a hard power reset. This can be worked around using:
>
> fastboot oem select-display-panel none
>
> To switch ON the display back run:
>
> fastboot oem select-display-panel
>
> But this only works on Beryllium devices running bootloader
> version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> Android-9 based release. Newer bootloader version do not
> support switching OFF the display panel at all.
>
> Signed-off-by: Amit Pundir
> ---
> My WIP tree with a few out-of-tree patches to support
> display, touchscreen, wifi, audio etc is here:
> https://github.com/pundiramit/linux/commits/beryllium-mainline
>
> v6: Renamed dts file to include vendor (xiaomi) name. Moved
> reserved memory changes in the main node. Renamed model to
> phone's pretty name. Removed the mmc drive strength comment
> to avoid further confusion. Sorted the entries in alphabetical
> order, but additional pinctrl entries are still defined at the
> end to align with the upstream db845c dts.
> v5: Bumped _mem size from 0x2d0 to 0x490 (to include
> downstream _region), all the way up to _mem.
> v4: Added more downstream reserved memory regions. It probably
> need more work, but for now I see adsp/cdsp/wlan remoteprocs
> powering up properly. Removed the regulator nodes not
> required for the device, as suggested by Bjorn. Also added
> couple of clocks to protected clocks, which is needed for
> display to work.
> v3: Added a reserved-memory region from downstream kernel to fix
> a boot regression with recent dma-pool changes in v5.8-rc6.
> v2: Updated machine compatible string for seemingly inevitable
> future quirks.
>
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 383
> +
> 2 files changed, 384 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index d8f1466e6758..9adc269252d3 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -30,6 +30,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-xiaomi-beryllium.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sm8250-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> new file mode 100644
> index ..cd25d5d8c0c9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +
> +/*
> + * Delete following upstream (sdm845.dtsi) reserved
> + * memory mappings which are different in this device.
> + */
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +/delete-node/ _msa_mem;
> +/delete-node/ _region;
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +/delete-node/ _region;
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +/delete-node/ _mem;
> +
> +/ {
> + model = "Xiaomi Pocophone F1";
> + compatible = "xiaomi,beryllium", "qcom,sdm845";
> +
> + /* required for bootloader to select correct board */
> + qcom,board-id = <69 0>;
> + qcom,msm-id = <321 0x20001>;
> +
>
[PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all.
Signed-off-by: Amit Pundir
---
My WIP tree with a few out-of-tree patches to support
display, touchscreen, wifi, audio etc is here:
https://github.com/pundiramit/linux/commits/beryllium-mainline
v6: Renamed dts file to include vendor (xiaomi) name. Moved
reserved memory changes in the main node. Renamed model to
phone's pretty name. Removed the mmc drive strength comment
to avoid further confusion. Sorted the entries in alphabetical
order, but additional pinctrl entries are still defined at the
end to align with the upstream db845c dts.
v5: Bumped _mem size from 0x2d0 to 0x490 (to include
downstream _region), all the way up to _mem.
v4: Added more downstream reserved memory regions. It probably
need more work, but for now I see adsp/cdsp/wlan remoteprocs
powering up properly. Removed the regulator nodes not
required for the device, as suggested by Bjorn. Also added
couple of clocks to protected clocks, which is needed for
display to work.
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 383 +
2 files changed, 384 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d8f1466e6758..9adc269252d3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -30,6 +30,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-xiaomi-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8250-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
new file mode 100644
index ..cd25d5d8c0c9
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/*
+ * Delete following upstream (sdm845.dtsi) reserved
+ * memory mappings which are different in this device.
+ */
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _msa_mem;
+/delete-node/ _region;
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _region;
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _mem;
+
+/ {
+ model = "Xiaomi Pocophone F1";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ /* Reserved memory changes from downstream */
+ reserved-memory {
+ tz_mem: memory@8620 {
+ reg = <0 0x8620 0 0x490>;
+ no-map;
+ };
+
+ adsp_mem: memory@8c50 {
+
Re: [PATCH] staging: ion: remove from the tree
On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > The ION android code has long been marked to be removed, now that we > > > dma-buf support merged into the real part of the kernel. > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > quite a bit, and any Android device using the ion interface uses that > > > forked version and not this in-tree version, the in-tree copy of the > > > code is abandonded and not used by anyone. > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > order to keep the kernel building properly, which then causes merge > > > issues when merging those changes into the out-of-tree Android code, and > > > you end up with two different groups of people (the in-kernel-tree > > > developers, and the Android kernel developers) who are both annoyed at > > > the current situation. Because of this problem, just drop the in-kernel > > > copy of the ion code now, as it's not used, and is only causing problems > > > for everyone involved. > > > > > > Cc: "Arve Hjønnevåg" > > > Cc: "Christian König" > > > Cc: Christian Brauner > > > Cc: Christoph Hellwig > > > Cc: Hridya Valsaraju > > > Cc: Joel Fernandes > > > Cc: John Stultz > > > Cc: Laura Abbott > > > Cc: Martijn Coenen > > > Cc: Shuah Khan > > > Cc: Sumit Semwal > > > Cc: Suren Baghdasaryan > > > Cc: Todd Kjos > > > Cc: de...@driverdev.osuosl.org > > > Cc: dri-de...@lists.freedesktop.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Signed-off-by: Greg Kroah-Hartman > > > > We discussed this at the Android MC on Monday and the plan was to > > remove it after the next LTS release. > > I know it was discussed, my point is that it is actually causing > problems now (with developers who want to change the internal kernel api > hitting issues, and newbies trying to clean up code in ways that isn't > exactly optimal wasting maintainer cycles), and that anyone who uses > this code, is not actually using this version of the code. Everyone who > relies on ion right now, is using the version that is in the Android > common kernel tree, which has diverged from this in-kernel way quite a > bit now for the reason that we didn't want to take any of those new > features in the in-kernel version. > > So this is a problem that we have caused by just wanting to wait, no one > is using this code, combined with it causing problems for the upstream > developers. > > There is nothing "magic" about the last kernel of the year that requires > this code to sit here until then. At that point in time, all users > will, again, be using the forked Android kernel version, and if we > delete this now here, that fork can remain just fine, with the added > benifit of it reducing developer workloads here in-kernel. > > So why wait? Hi, I don't know what is the right thing to do here. I just want to highlight that AOSP's audio (codec2) HAL depends on the ION system heap and it will break AOSP for people who boot mainline on their devices, even for just testing purpose like we do in Linaro. Right now we need only 1 (Android specific out-of-tree) patch to boot AOSP with mainline and Sumit is already trying to upstream that vma naming patch. Removal of in-kernel ION, will just add more to that delta. Regards, Amit Pundir > > thanks, > > greg k-h
Re: [PATCH v5] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Hi Konrad,
On Sat, 22 Aug 2020 at 02:51, Konrad Dybcio wrote:
>
> Hi
>
> First of all, sorry if anybody sees this twice. I've been messing with
> Thunderbird lately.
>
>
>
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb
>
> [B]eryllium should come before [C]heza, no? Also, aren't the non-development
> boards supposed to include the vendor name? i.e.
> sdm845-(xiaomi/poco)-beryllium.dtb
Ack. I didn't pay attention to that part. I'll fix that.
>
>
> > + model = "Xiaomi Technologies Inc. Beryllium";
>
> At least with Xperias, we settled on setting the model property to the
> "pretty" name, in this case Poco F1
Ack.
>
>
> > + pm8998-rpmh-regulators {
> > + compatible = "qcom,pm8998-rpmh-regulators";
> > + qcom,pmic-id = "a";
> > +
> > + vreg_l1a_0p875: ldo1 {
>
> I think you forgot to include (regulatorname)-supply properties which should
> cause havoc with all things regulators..
I didn't know that. Thanks for pointing that out. I just copied db845c
dts and started removing the nodes/properties which I didn't seem fit.
There is a very good probability that I goofed up big time.
FWIW in my limited testing so far (Booted AOSP to UI, with working
Touchscreen/BT/WiFi/Audio with out-of-tree drivers [1]), I didn't run
into issues with mainline (v5.9-rc1) or Android GKI (v5.4.58). May be
I just got lucky. I'll check up on the usage of (regulatorname)-supply
properties.
>
>
> > + vreg_l1a_0p875: ldo1 {
> > + regulator-min-microvolt = <88>;
> > + regulator-max-microvolt = <88>;
> 0p88? Unless it's a PMIC limitation.. Please also confirm names for the rest
> of the regulators.
>
> Also why are there so few regulators? And none from pmi8998? Are the rest
> WIP/coming in a followup commit, or are they disabled on this board? AFAICS
> you only include SoC/PMIC DTs which would suggest they should be there.
I intend to add more regulators and feature nodes in follow up commits.
>
>
> > +/* Reserved memory changes from downstream */
>
> Wouldn't it look better if you included that in the main {} node instead of
> reopening it in the middle of the file? I mean, it works, but let's hear what
> others have to say.
Ack. I'll fix that if necessary.
>
>
> > + * It seems that mmc_test reports errors if drive
> > + * strength is not 16 on clk, cmd, and data pins.
>
> You say that, but then you set "drive-strength = <10>;" for cmd and data,
> please confirm it's intentional.
In sync with db845c as well as downstream dts but I'll check on this as well.
>
>
> > +_mem_hc {
>
> UFS comes before USB alphabetically.
Ack. I'll add them alphabetically if that is the common norm.
Regards,
Amit Pundir
[1] https://github.com/pundiramit/linux/commits/beryllium-mainline
>
>
> > +_mem_phy
>
> Ditto
>
>
> > +_uart6_default
>
> Ditto
>
>
> Konrad
[PATCH v5] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v5: Bumped _mem size from 0x2d0 to 0x490 (to include
downstream _region), all the way up to _mem.
v4: Added more downstream reserved memory regions. It probably
need more work, but for now I see adsp/cdsp/wlan remoteprocs
powering up properly. Removed the regulator nodes not
required for the device, as suggested by Bjorn. Also added
couple of clocks to protected clocks, which is needed for
display to work.
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 382 ++
2 files changed, 383 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d8f1466e6758..477b72dca0fc 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..5c03994bcbdd
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vreg_s4a_1p8: vreg-s4a-1p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s4a_1p8";
+
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+};
+
+_pas {
+ status = "okay";
+ firmware-name = "qcom/sdm845/adsp.mdt";
+};
+
+_rsc {
+ pm8998-rpmh-regulators {
+ compatible = "qcom,pm8998-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_l1a_0p875: ldo1 {
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <88>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l5a_0p8: ldo5 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <80>;
+ regulator-initial-mode = ;
+
Re: your mail
On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
wrote:
>
> On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
>
> > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1
> > (Beryllium)
> >
> > >// This removed_region is needed to boot the device
> > > // TODO: Find out the user of this reserved memory
> > > removed_region: memory@88f0 {
> >
> > This region seems to belong to the Trust Zone. When Linux tries to access
> > it, TZ bites and shuts the device down.
> >
>
> This is in line with what the documentation indicates and then it would
> be better to just bump _mem to a size of 0x490.
Hi, so just to be sure that I got this right, you want me to extend
_mem to the size of 0x490 from the default size of 0x2D0 by
including this downstream _region (of size 0x1A0) +
previously unreserved downstream memory region (of size 0x20), to
align with the starting address of _mem?
I just gave this _mem change a spin and I do not see any obvious
regression in my limited smoke testing (Boots AOSP to UI with
v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
Regards,
Amit Pundir
>
> Regards,
> Bjorn
Re: [PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot
On Mon, 8 Jun 2020 at 17:07, Kalle Valo wrote: > > I don't agree with this. If you read through the replies to the bug report, > > it is clear that NS migration uncovered a corner case or even a bug. So we > > should try to fix that indeed. > > I'm with Mani, we should try to fix ath10k instead. Hopefully we can > find a fix soon. Hi Team, Any updates on this? I can reproduce this hard crash on v5.9-rc1 as well. It is not a blocker for us because we switched to a userspace workaround, where we do not wait for modem to shutdown gracefully and SIGKILL it instead, during the shutdown/reboot process. But I'm happy to take a swing at any intermediate/in-progress solution available. Regards, Amit Pundir > > Forcing QCA6390 users to use the userspace qrtr-ns would be bad user > experience, I really would want to avoid that. > > -- > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v4 0/2] dma-pool fixes
On Fri, 14 Aug 2020 at 15:56, Nicolas Saenz Julienne wrote: > > Now that we have an explanation to Amir's issue, we can re-spin this > series. Hi, Smoke tested (boots AOSP to UI with Touch/WiFi/BT working) on my Poco F1 phone, with upstream commit 00e4db51259a (+ 30 odd out of tree patches [1]) and I see no obvious regressions. For both the patches in the series: Tested-by: Amit Pundir [1] https://github.com/pundiramit/linux/commits/beryllium-mainline-display > > --- > Changes since v3: > - Do not use memblock_start_of_DRAM() > > Changes since v2: > - Go back to v1's behavior for patch #2 > > Changes since v1: > - Make cma_in_zone() more strict, GFP_KERNEL doesn't default to true >now > > - Check if phys_addr_ok() exists prior calling it > > Christoph Hellwig (1): > dma-pool: fix coherent pool allocations for IOMMU mappings > > Nicolas Saenz Julienne (1): > dma-pool: Only allocate from CMA when in same memory zone > > drivers/iommu/dma-iommu.c | 4 +- > include/linux/dma-direct.h | 3 - > include/linux/dma-mapping.h | 5 +- > kernel/dma/direct.c | 13 +++- > kernel/dma/pool.c | 145 +++- > 5 files changed, 92 insertions(+), 78 deletions(-) > > -- > 2.28.0 >
Re:
On Fri, 7 Aug 2020 at 04:02, Konrad Dybcio wrote:
>
> Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1
> (Beryllium)
>
> >// This removed_region is needed to boot the device
> > // TODO: Find out the user of this reserved memory
> > removed_region: memory@88f0 {
>
> This region seems to belong to the Trust Zone. When Linux tries to access it,
> TZ bites and shuts the device down.
That is totally possible. Plus it falls right in between TZ and QSEE
reserved-memory regions. However, I do not find any credible source
of information which can confirm this. So I'm hesitant to update the
TODO item in the above comment.
>
> Konrad
Re: [PATCH] arm64: dts: sdm845: Fixup OPP table for all qup devices
On Wed, 12 Aug 2020 at 15:52, Rajendra Nayak wrote:
>
> This OPP table was based on the clock VDD-FMAX tables seen in
> downstream code, however it turns out the downstream clock
> driver does update these tables based on later/production
> rev of the chip and whats seen in the tables belongs to an
> early engineering rev of the SoC.
> Fix up the OPP tables such that it now matches with the
> production rev of sdm845 SoC.
>
> Fixes: 13cadb34e593 ("arm64: dts: sdm845: Add OPP table for all qup
> devices")
Fixes BT on Xiaomi Poco F1 phone running AOSP.
Tested-by: Amit Pundir
> Reported-by: John Stultz
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 2884577..eca81cf 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1093,8 +1093,8 @@
> qup_opp_table: qup-opp-table {
> compatible = "operating-points-v2";
>
> - opp-1920 {
> - opp-hz = /bits/ 64 <1920>;
> + opp-5000 {
> + opp-hz = /bits/ 64 <5000>;
> required-opps = <_opp_min_svs>;
> };
>
> @@ -1107,6 +1107,11 @@
> opp-hz = /bits/ 64 <1>;
> required-opps = <_opp_svs>;
> };
> +
> + opp-12800 {
> + opp-hz = /bits/ 64 <12800>;
> + required-opps = <_opp_nom>;
> + };
> };
>
> qupv3_id_0: geniqup@8c {
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
Hi Rajendra, On Wed, 12 Aug 2020 at 11:18, Rajendra Nayak wrote: > > > On 8/12/2020 7:03 AM, John Stultz wrote: > > On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote: > >> > >> On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak > >> wrote: > >>> > >>> geni serial needs to express a perforamnce state requirement on CX > >>> depending on the frequency of the clock rates. Use OPP table from > >>> DT to register with OPP framework and use dev_pm_opp_set_rate() to > >>> set the clk/perf state. > >>> > >>> Signed-off-by: Rajendra Nayak > >>> Signed-off-by: Stephen Boyd > >>> --- > >>> drivers/tty/serial/qcom_geni_serial.c | 15 +-- > >>> 1 file changed, 13 insertions(+), 2 deletions(-) > >>> > >> > >> Hey, > >>I just wanted to follow up on this patch, as I've bisected it > >> (a5819b548af0) down as having broken qca bluetooth on the Dragonboard > >> 845c. > >> > >> I haven't yet had time to debug it yet, but wanted to raise the issue > >> in case anyone else has seen similar trouble. > > > > So I dug in a bit further, and this chunk seems to be causing the issue: > >> @@ -961,7 +963,7 @@ static void qcom_geni_serial_set_termios(struct > >> uart_port *uport, > >> goto out_restart_rx; > >> > >> uport->uartclk = clk_rate; > >> - clk_set_rate(port->se.clk, clk_rate); > >> + dev_pm_opp_set_rate(port->dev, clk_rate); > >> ser_clk_cfg = SER_CLK_EN; > >> ser_clk_cfg |= clk_div << CLK_DIV_SHFT; > >> > > > > > > With that applied, I see the following errors in dmesg and bluetooth > > fails to function: > > [4.763467] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: > > failed to find OPP for freq 10240 (-34) > > [4.773493] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: > > failed to find OPP for freq 10240 (-34) > > > > With just that chunk reverted on linus/HEAD, bluetooth seems to work ok. > > This seems like the same issue that was also reported on venus [1] because the > clock frequency tables apparently don;t exactly match the achievable clock > frequencies (which we also used to construct the OPP tables) > > Can you try updating the OPP table for QUP to have 10240 instead of the > current 1 and see if that fixes it? That worked. Thanks. Should this change be common to base sdm845.dtsi or platform specific dts? For what it's worth, we see this BT breakage on PocoF1 phone too. Regards, Amit Pundir > > [1] https://lkml.org/lkml/2020/7/27/507 > > > > > thanks > > -john > > > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here to
boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v4: Added more downstream reserved memory regions. It probably
need more work, but for now I see adsp/cdsp/wlan remoteprocs
powering up properly. Also removed the regulator nodes not
required for the device, as suggested by Bjorn.
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383 ++
2 files changed, 384 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..0f9f61bf9fa4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vreg_s4a_1p8: vreg-s4a-1p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s4a_1p8";
+
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+};
+
+_pas {
+ status = "okay";
+ firmware-name = "qcom/sdm845/adsp.mdt";
+};
+
+_rsc {
+ pm8998-rpmh-regulators {
+ compatible = "qcom,pm8998-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_l1a_0p875: ldo1 {
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <88>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l5a_0p8: ldo5 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <80>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l7a_1p8: ldo7 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>
Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
On Wed, 5 Aug 2020 at 16:21, Amit Pundir wrote:
>
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS, USB-C (peripheral),
> microSD card and Vol+/Vol-/power keys. Bluetooth should work
> too but couldn't be verified from adb command line, it is
> verified when enabled from UI with few WIP display patches.
>
> Just like initial db845c support, initializing the SMMU is
> clearing the mapping used for the splash screen framebuffer,
> which causes the device to hang during boot and recovery
> needs a hard power reset. This can be worked around using:
>
> fastboot oem select-display-panel none
>
> To switch ON the display back run:
>
> fastboot oem select-display-panel
>
> But this only works on Beryllium devices running bootloader
> version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> Android-9 based release. Newer bootloader version do not
> support switching OFF the display panel at all. So we need
> a few additional smmu patches (under review) from here to
> boot to shell:
> https://github.com/pundiramit/linux/commits/beryllium-mainline
>
> Signed-off-by: Amit Pundir
> ---
> v4: Added more downstream reserved memory regions. It probably
> need more work, but for now I see adsp/cdsp/wlan remoteprocs
> powering up properly. Also removed the regulator nodes not
> required for the device, as suggested by Bjorn.
Forgot to mention that I added couple of clocks to protected clocks in v4,
which need for display to work.
> v3: Added a reserved-memory region from downstream kernel to fix
> a boot regression with recent dma-pool changes in v5.8-rc6.
> v2: Updated machine compatible string for seemingly inevitable
> future quirks.
>
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383
> ++
> 2 files changed, 384 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 0f2c33d611df..3ef1b48bc0cb 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> new file mode 100644
> index ..0f9f61bf9fa4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +
> +/ {
> + model = "Xiaomi Technologies Inc. Beryllium";
> + compatible = "xiaomi,beryllium", "qcom,sdm845";
> +
> + /* required for bootloader to select correct board */
> + qcom,board-id = <69 0>;
> + qcom,msm-id = <321 0x20001>;
> +
> + aliases {
> + hsuart0 =
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_up_pin_a>;
> +
> + vol-up {
> + label = "Volume Up";
> + linux,code = ;
> + gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + vreg_s4a_1p8: vreg-s4a-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vreg_s4a_1p8";
> +
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +};
> +
> +_pas {
> + status = "okay";
> + firmware-name = "qcom/sdm845/adsp.mdt";
> +};
> +
> +_rsc {
> + pm8998-rpmh-regulators {
> +
Re: [PATCH v3] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
On Tue, 4 Aug 2020 at 11:46, Bjorn Andersson wrote:
>
> On Sat 01 Aug 08:55 PDT 2020, Amit Pundir wrote:
>
> > Add initial dts support for Xiaomi Poco F1 (Beryllium).
> >
> > This initial support is based on upstream Dragonboard 845c
> > (sdm845) device. With this dts, Beryllium boots AOSP up to
> > ADB shell over USB-C.
> >
> > Supported functionality includes UFS, USB-C (peripheral),
> > microSD card and Vol+/Vol-/power keys. Bluetooth should work
> > too but couldn't be verified from adb command line, it is
> > verified when enabled from UI with few WIP display patches.
> >
> > Just like initial db845c support, initializing the SMMU is
> > clearing the mapping used for the splash screen framebuffer,
> > which causes the device to hang during boot and recovery
> > needs a hard power reset. This can be worked around using:
> >
> > fastboot oem select-display-panel none
> >
> > To switch ON the display back run:
> >
> > fastboot oem select-display-panel
> >
> > But this only works on Beryllium devices running bootloader
> > version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> > Android-9 based release. Newer bootloader version do not
> > support switching OFF the display panel at all. So we need
> > a few additional smmu patches (under review) from here to
> > boot to shell:
> > https://github.com/pundiramit/linux/commits/beryllium-mainline
> >
> > Signed-off-by: Amit Pundir
> > ---
> > v3: Added a reserved-memory region from downstream kernel to fix
> > a boot regression with recent dma-pool changes in v5.8-rc6.
> > v2: Updated machine compatible string for seemingly inevitable
> > future quirks.
> >
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 331
> > ++
> > 2 files changed, 332 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile
> > b/arch/arm64/boot/dts/qcom/Makefile
> > index 0f2c33d611df..3ef1b48bc0cb 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> > b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> > new file mode 100644
> > index ..af66459712fe
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> > @@ -0,0 +1,331 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/dts-v1/;
> > +
> > +#include
> > +#include
> > +#include
> > +#include "sdm845.dtsi"
> > +#include "pm8998.dtsi"
> > +#include "pmi8998.dtsi"
> > +
> > +/ {
> > + model = "Xiaomi Technologies Inc. Beryllium";
> > + compatible = "xiaomi,beryllium", "qcom,sdm845";
> > +
> > + /* required for bootloader to select correct board */
> > + qcom,board-id = <69 0>;
> > + qcom,msm-id = <321 0x20001>;
> > +
> > + aliases {
> > + hsuart0 =
> > + };
> > +
> > + dc12v: dc12v-regulator {
>
> This is a phone, it doesn't have a 12V DC jack. So while I don't know
> the exact power grid for this device, this node shouldn't be here.
Ack. Will remove it in next version.
>
> > + compatible = "regulator-fixed";
> > + regulator-name = "DC12V";
> > + regulator-min-microvolt = <1200>;
> > + regulator-max-microvolt = <1200>;
> > + regulator-always-on;
> > + };
> > +
> > + gpio_keys {
>
> y/_/-/
Ack.
>
> > + compatible = "gpio-keys";
> > + autorepeat;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_up_pin_a>;
> > +
> > + vol-up {
> > + label = &q
[PATCH v3] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here to
boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 331 ++
2 files changed, 332 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..af66459712fe
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: vdc-5v-regulator {
+ compatible = "regulator-fixed&quo
[PATCH v2] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here to
boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 321 ++
2 files changed, 322 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..714c5157d9f8
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: vdc-5v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_5V";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <50&g
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
1 returned > status 0x > [1.780871] ALSA device list: > [1.783960] No soundcards found. > [1.787633] Waiting for root device PARTUUID=45a8dd8a-02... > > I am unsure if it is related to the issue that Amit is having or > if that makes sense at all but I can reliably reproduce it. > > v5.8-rc1: OK > v5.8-rc1 + d9765e41d8e9e: OK > v5.8-rc1 + "of_address: Add bus type match for pci ranges parser": OK > v5.8-rc1 + both: BROKEN > > I wanted to test the series to see if this fixes anything. If you would > prefer a different thread for this or further information, please let > me know. Hi Nathan, Here is the patch series: https://lists.linuxfoundation.org/pipermail/iommu/2020-July/047008.html https://lists.linuxfoundation.org/pipermail/iommu/2020-July/047010.html I hope it works for you, it didn't work for me. More details in this thread here: https://lists.linuxfoundation.org/pipermail/iommu/2020-July/047009.html Regards, Amit Pundir > > Cheers, > Nathan
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Fri, 24 Jul 2020 at 19:11, Christoph Hellwig wrote:
>
> Yes, the iommu is an interesting case, and the current code is
> wrong for that. Can you try the patch below? It contains a modified
> version of Nicolas' patch to try CMA again for the expansion and a new
> (for now hackish) way to not apply the addressability check for dma-iommu
> allocations.
Thank you. The below patch worked on today's linux/master (f37e99aca03f).
Regards,
Amit Pundir
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 6bc74a2d51273e..ec5e525d2b9309 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -3,7 +3,9 @@
> * Copyright (C) 2012 ARM Ltd.
> * Copyright (C) 2020 Google LLC
> */
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -55,6 +57,31 @@ static void dma_atomic_pool_size_add(gfp_t gfp, size_t
> size)
> pool_size_kernel += size;
> }
>
> +static bool cma_in_zone(gfp_t gfp)
> +{
> + phys_addr_t end;
> + unsigned long size;
> + struct cma *cma;
> +
> + cma = dev_get_cma_area(NULL);
> + if (!cma)
> + return false;
> +
> + size = cma_get_size(cma);
> + if (!size)
> + return false;
> + end = cma_get_base(cma) - memblock_start_of_DRAM() + size - 1;
> +
> + /* CMA can't cross zone boundaries, see cma_activate_area() */
> + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA) &&
> + end <= DMA_BIT_MASK(zone_dma_bits))
> + return true;
> + if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32) &&
> + end <= DMA_BIT_MASK(32))
> + return true;
> + return true;
> +}
> +
> static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
> gfp_t gfp)
> {
> @@ -68,7 +95,11 @@ static int atomic_pool_expand(struct gen_pool *pool,
> size_t pool_size,
>
> do {
> pool_size = 1 << (PAGE_SHIFT + order);
> - page = alloc_pages(gfp, order);
> + if (cma_in_zone(gfp))
> + page = dma_alloc_from_contiguous(NULL, 1 << order,
> +order, false);
> + if (!page)
> + page = alloc_pages(gfp, order);
> } while (!page && order-- > 0);
> if (!page)
> goto out;
> @@ -251,7 +282,11 @@ void *dma_alloc_from_pool(struct device *dev, size_t
> size,
> continue;
>
> phys = gen_pool_virt_to_phys(pool, val);
> - if (dma_coherent_ok(dev, phys, size))
> + /*
> +* Only apply the addressability check for dma-direct.
> +* This is a nasty hack and won't work e.g. for arm.
> +*/
> + if (get_dma_ops(dev) || dma_coherent_ok(dev, phys, size))
> break;
>
> gen_pool_free(pool, val, size);
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Fri, 24 Jul 2020 at 15:06, Nicolas Saenz Julienne wrote: > > Hi Amit, > > On Thu, 2020-07-23 at 10:44 +0530, Amit Pundir wrote: > > Hi Nicolas, > > > > Sorry I got stuck on other things yesterday. > > No worries :) > > > On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne > > [...] > > > > > > > Let's get a bigger hammer, I'm just looking for clues here. Can you > > > apply this and provide the dmesg output. > > > > > > diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c > > > index 6bc74a2d5127..2160676bf488 100644 > > > --- a/kernel/dma/pool.c > > > +++ b/kernel/dma/pool.c > > > @@ -268,6 +268,8 @@ void *dma_alloc_from_pool(struct device *dev, size_t > > > size, > > > schedule_work(_pool_work); > > > } > > > > > > + dev_info(dev, "%s: size %lx, phys addr %llx, flags 0x%x\n", > > > __func__, size, phys, flags); > > > + > > > return ptr; > > > } > > > > I never made it to dma_alloc_from_pool() call from > > dma_direct_alloc_pages(), dma_should_alloc_from_pool() returns False > > from gfpflags_allow_blocking() block. > > I'm a little sceptical about this. The only way you can get memory from these > pools is through dma_alloc_from_pool(), and given how changes in the pool > initialization affected the phone, it's pretty clear some amount of pool > allocation is happening. Maybe from here iommu_dma_alloc_remap()? I see two paths to dma_alloc_from_pool(), one from dma_direct_alloc_pages() which I mentioned above and 2nd one is thru iommu_dma_alloc(), but the flow doesn't reach up to dma_alloc_from_pool(), and always returns from iommu_dma_alloc_remap(). Regards, Amit Pundir > > Regards, > Nicolas >
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
Hi Nicolas,
Sorry I got stuck on other things yesterday.
On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne
wrote:
>
> On Tue, 2020-07-21 at 20:52 +0530, Amit Pundir wrote:
>
> [...]
>
> > > > > Can you try booting *without* my patch and this in the kernel
> > > > > command
> > > > > line: "cma=16M@0x1-0x2".
> > > >
> > > > It doesn't boot with this added kernel command line.
> > >
> > > For the record, this placed the CMA in the [4GB, 8GB] address space
> > > instead of you setup's default: [3GB, 4GB]. All atomic pools fall
> > > in
> > > that memory area without my patch, which makes me think some of the
> > > devices on your board might not like higher addresses.
> > >
> >
> > Thank you Nicolas for the details. Though we don't set the CMA
> > alloc-ranges explicitly in upstream sdm845 dts, but I dug around and
> > found that CMA alloc-ranges in the downstream kernel are indeed in
> > lower address space.
> > https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/dipper-q-oss/arch/arm64/boot/dts/qcom/sdm845.dtsi#L662
> >
> > /* global autoconfigured region for contiguous allocations */
> > linux,cma {
> > compatible = "shared-dma-pool";
> > alloc-ranges = <0 0x 0 0x>;
> > reusable;
> > alignment = <0 0x40>;
> > size = <0 0x200>;
> > linux,cma-default;
> > };
>
> Pretty standard, and similar to what it's being used upstream by
> default.
>
> >
> > > What happens if you boot with my troublesome patch with this in
> > > your
> > > device tree? (insert it at the bottom of sdm845-beryllium.dts)
> > >
> > > {
> > > dma-ranges = <0 0 0 0 0x1 0>;
> > > };
> > >
> >
> > Device still doesn't boot up to adb shell.
>
> Let's get a bigger hammer, I'm just looking for clues here. Can you
> apply this and provide the dmesg output.
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 6bc74a2d5127..2160676bf488 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -268,6 +268,8 @@ void *dma_alloc_from_pool(struct device *dev, size_t size,
> schedule_work(_pool_work);
> }
>
> + dev_info(dev, "%s: size %lx, phys addr %llx, flags 0x%x\n", __func__,
> size, phys, flags);
> +
> return ptr;
> }
I never made it to dma_alloc_from_pool() call from
dma_direct_alloc_pages(), dma_should_alloc_from_pool() returns False
from gfpflags_allow_blocking() block.
Regards,
Amit Pundir
>
>
> Regards,
> Nicolas
>
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Tue, 21 Jul 2020 at 18:15, Nicolas Saenz Julienne
wrote:
>
> On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote:
> > On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne
> > wrote:
> > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> > > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> > > > wrote:
> > > > > Hi Amit,
> > > > > > Hi Nicolas,
> > > > > >
> > > > > > I see a boot regression with this commit d9765e41d8e9 "dma-
> > > > > > pool:
> > > > > > Do not allocate pool memory from CMA" on my Xiaomi Poco F1
> > > > > > (Qcom sdm845) phone running v5.8-rc6. I can't boot past the
> > > > > > bootloader splash screen with this patch.
> > > > > >
> > > > > > Phone boots fine if I revert this patch. I carry only one out
> > > > > > of
> > > > > > tree
> > > > > > dts patch https://lkml.org/lkml/2020/6/25/52. And since this
> > > > > > is a
> > > > > > stock
> > > > > > phone, I don't have access to serial/dmesg logs until I boot
> > > > > > to
> > > > > > AOSP
> > > > > > (adb) shell.
> > > > > >
> > > > > > Any thoughts as to what might be going wrong here? I'd be
> > > > > > happy
> > > > > > to
> > > > > > help debug things. For what it's worth, I don't see this
> > > > > > regression
> > > > > > on
> > > > > > other two sdm845 devices (db845c and Pixel 3) I tested on.
> > > > >
> > > > > Can you provide a boot log (even if without my patch) and the
> > > > > device-
> > > > > tree files? It'd help a lot figuring things out.
> > > >
> > > > Thank you for the prompt reply Nicolas.
> > > >
> > > > Here is the boot log with the reverted patch
> > > > https://pastebin.ubuntu.com/p/BrhPf83nKF/
> > > >
> > > > Here is my phone's dts
> > > > https://github.com/pundiramit/linux/commit/2a394c199deeaf4c91e0e008e8fba2a72f494d8c
> > >
> > > I'm at loss at what could be failing here. Your device should be
> > > able
> > > to address the whole 8GB memory space, which AFAIK is the max
> > > available
> > > on that smartphone family. But maybe the device-tree is lying, who
> > > knows...
> >
> > If it helps, my phone has 6GB memory space.
> >
> > > Can you try booting *without* my patch and this in the kernel
> > > command
> > > line: "cma=16M@0x1-0x2".
> >
> > It doesn't boot with this added kernel command line.
>
>
> For the record, this placed the CMA in the [4GB, 8GB] address space
> instead of you setup's default: [3GB, 4GB]. All atomic pools fall in
> that memory area without my patch, which makes me think some of the
> devices on your board might not like higher addresses.
>
Thank you Nicolas for the details. Though we don't set the CMA
alloc-ranges explicitly in upstream sdm845 dts, but I dug around and
found that CMA alloc-ranges in the downstream kernel are indeed in
lower address space.
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/dipper-q-oss/arch/arm64/boot/dts/qcom/sdm845.dtsi#L662
/* global autoconfigured region for contiguous allocations */
linux,cma {
compatible = "shared-dma-pool";
alloc-ranges = <0 0x 0 0x>;
reusable;
alignment = <0 0x40>;
size = <0 0x200>;
linux,cma-default;
};
> What happens if you boot with my troublesome patch with this in your
> device tree? (insert it at the bottom of sdm845-beryllium.dts)
>
> {
> dma-ranges = <0 0 0 0 0x1 0>;
> };
>
Device still doesn't boot up to adb shell.
Regards,
Amit Pundir
> Regards,
> Nicolas
>
> > Regards,
> > Amit Pundir
> >
> > > Regards,
> > > Nicolas
> > >
> > > And here is my kernel tree just in case
> > > > https://github.com/pundiramit/linux/commits/beryllium-mainline
> > > >
> > > > Regards,
> > > > Amit Pundir
> > > >
> > > >
> > > > > Regards,
> > > > > Nicolas
> > > > >
> > > > > > Regards,
> > > > > > Amit Pundir
> > > > > >
> > > > > > > Reported-by: Jeremy Linton
> > > > > > > Signed-off-by: Nicolas Saenz Julienne <
> > > > > > > nsaenzjulie...@suse.de>
> > > > > > > ---
> > > > > > >
> > > > > > > An more costly alternative would be adding an option to
> > > > > > > dma_alloc_from_contiguous() so it fails when the allocation
> > > > > > > doesn't
> > > > > > > fall
> > > > > > > in a specific zone.
> > > > > > >
> > > > > > > kernel/dma/pool.c | 11 ++-
>
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Tue, 21 Jul 2020 at 17:07, Nicolas Saenz Julienne wrote: > > On Tue, 2020-07-21 at 13:28 +0200, Christoph Hellwig wrote: > > On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne > > wrote: > > > I'm at loss at what could be failing here. Your device should be > > > able > > > to address the whole 8GB memory space, which AFAIK is the max > > > available > > > on that smartphone family. But maybe the device-tree is lying, who > > > knows... > > > > Maybe we should give your patch to allocate from CMA but check the > > address a try? (just because we can..) > > Yes, good idea! > > Amir, could you also test this patch[1] (having reverted the one that > casues trouble) and report on whether it boots or not? Can't boot with that patch either. Regards, Amit Pundir > > Regards, > Nicolas > > [1] https://lore.kernel.org/linux-iomhttps://lore.kernel.org/linux-iom > mu/fe14037b02fd887a73cd91c115dccc4485f8446e.ca...@suse.de/T/#t > >
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne wrote: > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote: > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne > > wrote: > > > Hi Amit, > > > > Hi Nicolas, > > > > > > > > I see a boot regression with this commit d9765e41d8e9 "dma-pool: > > > > Do not allocate pool memory from CMA" on my Xiaomi Poco F1 > > > > (Qcom sdm845) phone running v5.8-rc6. I can't boot past the > > > > bootloader splash screen with this patch. > > > > > > > > Phone boots fine if I revert this patch. I carry only one out of > > > > tree > > > > dts patch https://lkml.org/lkml/2020/6/25/52. And since this is a > > > > stock > > > > phone, I don't have access to serial/dmesg logs until I boot to > > > > AOSP > > > > (adb) shell. > > > > > > > > Any thoughts as to what might be going wrong here? I'd be happy > > > > to > > > > help debug things. For what it's worth, I don't see this > > > > regression > > > > on > > > > other two sdm845 devices (db845c and Pixel 3) I tested on. > > > > > > Can you provide a boot log (even if without my patch) and the > > > device- > > > tree files? It'd help a lot figuring things out. > > > > Thank you for the prompt reply Nicolas. > > > > Here is the boot log with the reverted patch > > https://pastebin.ubuntu.com/p/BrhPf83nKF/ > > > > Here is my phone's dts > > https://github.com/pundiramit/linux/commit/2a394c199deeaf4c91e0e008e8fba2a72f494d8c > > I'm at loss at what could be failing here. Your device should be able > to address the whole 8GB memory space, which AFAIK is the max available > on that smartphone family. But maybe the device-tree is lying, who > knows... If it helps, my phone has 6GB memory space. > > Can you try booting *without* my patch and this in the kernel command > line: "cma=16M@0x1-0x2". It doesn't boot with this added kernel command line. Regards, Amit Pundir > > Regards, > Nicolas > > And here is my kernel tree just in case > > https://github.com/pundiramit/linux/commits/beryllium-mainline > > > > Regards, > > Amit Pundir > > > > > > > Regards, > > > Nicolas > > > > > > > Regards, > > > > Amit Pundir > > > > > > > > > Reported-by: Jeremy Linton > > > > > Signed-off-by: Nicolas Saenz Julienne > > > > > --- > > > > > > > > > > An more costly alternative would be adding an option to > > > > > dma_alloc_from_contiguous() so it fails when the allocation > > > > > doesn't > > > > > fall > > > > > in a specific zone. > > > > > > > > > > kernel/dma/pool.c | 11 ++- >
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
wrote:
>
> Hi Amit,
>
> On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote:
> > On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne
> > wrote:
> > > There is no guarantee to CMA's placement, so allocating a zone
> > > specific
> > > atomic pool from CMA might return memory from a completely
> > > different
> > > memory zone. So stop using it.
> > >
> > > Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to
> > > map to gfp mask")
> >
> > Hi Nicolas,
> >
> > I see a boot regression with this commit d9765e41d8e9 "dma-pool:
> > Do not allocate pool memory from CMA" on my Xiaomi Poco F1
> > (Qcom sdm845) phone running v5.8-rc6. I can't boot past the
> > bootloader splash screen with this patch.
> >
> > Phone boots fine if I revert this patch. I carry only one out of tree
> > dts patch https://lkml.org/lkml/2020/6/25/52. And since this is a
> > stock
> > phone, I don't have access to serial/dmesg logs until I boot to AOSP
> > (adb) shell.
> >
> > Any thoughts as to what might be going wrong here? I'd be happy to
> > help debug things. For what it's worth, I don't see this regression
> > on
> > other two sdm845 devices (db845c and Pixel 3) I tested on.
>
> Can you provide a boot log (even if without my patch) and the device-
> tree files? It'd help a lot figuring things out.
Thank you for the prompt reply Nicolas.
Here is the boot log with the reverted patch
https://pastebin.ubuntu.com/p/BrhPf83nKF/
Here is my phone's dts
https://github.com/pundiramit/linux/commit/2a394c199deeaf4c91e0e008e8fba2a72f494d8c
And here is my kernel tree just in case
https://github.com/pundiramit/linux/commits/beryllium-mainline
Regards,
Amit Pundir
>
> Regards,
> Nicolas
>
> > Regards,
> > Amit Pundir
> >
> > > Reported-by: Jeremy Linton
> > > Signed-off-by: Nicolas Saenz Julienne
> > > ---
> > >
> > > An more costly alternative would be adding an option to
> > > dma_alloc_from_contiguous() so it fails when the allocation doesn't
> > > fall
> > > in a specific zone.
> > >
> > > kernel/dma/pool.c | 11 ++-
> > > 1 file changed, 2 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> > > index 8cfa01243ed2..4bc1c46ae6ef 100644
> > > --- a/kernel/dma/pool.c
> > > +++ b/kernel/dma/pool.c
> > > @@ -6,7 +6,6 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > #include
> > > #include
> > > @@ -69,12 +68,7 @@ static int atomic_pool_expand(struct gen_pool
> > > *pool, size_t pool_size,
> > >
> > > do {
> > > pool_size = 1 << (PAGE_SHIFT + order);
> > > -
> > > - if (dev_get_cma_area(NULL))
> > > - page = dma_alloc_from_contiguous(NULL, 1 <<
> > > order,
> > > -order,
> > > false);
> > > - else
> > > - page = alloc_pages(gfp, order);
> > > + page = alloc_pages(gfp, order);
> > > } while (!page && order-- > 0);
> > > if (!page)
> > > goto out;
> > > @@ -118,8 +112,7 @@ static int atomic_pool_expand(struct gen_pool
> > > *pool, size_t pool_size,
> > > dma_common_free_remap(addr, pool_size);
> > > #endif
> > > free_page: __maybe_unused
> > > - if (!dma_release_from_contiguous(NULL, page, 1 << order))
> > > - __free_pages(page, order);
> > > + __free_pages(page, order);
> > > out:
> > > return ret;
> > > }
> > > --
> > > 2.27.0
> > >
>
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne
wrote:
>
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. So stop using it.
>
> Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp
> mask")
Hi Nicolas,
I see a boot regression with this commit d9765e41d8e9 "dma-pool:
Do not allocate pool memory from CMA" on my Xiaomi Poco F1
(Qcom sdm845) phone running v5.8-rc6. I can't boot past the
bootloader splash screen with this patch.
Phone boots fine if I revert this patch. I carry only one out of tree
dts patch https://lkml.org/lkml/2020/6/25/52. And since this is a stock
phone, I don't have access to serial/dmesg logs until I boot to AOSP
(adb) shell.
Any thoughts as to what might be going wrong here? I'd be happy to
help debug things. For what it's worth, I don't see this regression on
other two sdm845 devices (db845c and Pixel 3) I tested on.
Regards,
Amit Pundir
> Reported-by: Jeremy Linton
> Signed-off-by: Nicolas Saenz Julienne
> ---
>
> An more costly alternative would be adding an option to
> dma_alloc_from_contiguous() so it fails when the allocation doesn't fall
> in a specific zone.
>
> kernel/dma/pool.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 8cfa01243ed2..4bc1c46ae6ef 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -6,7 +6,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -69,12 +68,7 @@ static int atomic_pool_expand(struct gen_pool *pool,
> size_t pool_size,
>
> do {
> pool_size = 1 << (PAGE_SHIFT + order);
> -
> - if (dev_get_cma_area(NULL))
> - page = dma_alloc_from_contiguous(NULL, 1 << order,
> -order, false);
> - else
> - page = alloc_pages(gfp, order);
> + page = alloc_pages(gfp, order);
> } while (!page && order-- > 0);
> if (!page)
> goto out;
> @@ -118,8 +112,7 @@ static int atomic_pool_expand(struct gen_pool *pool,
> size_t pool_size,
> dma_common_free_remap(addr, pool_size);
> #endif
> free_page: __maybe_unused
> - if (!dma_release_from_contiguous(NULL, page, 1 << order))
> - __free_pages(page, order);
> + __free_pages(page, order);
> out:
> return ret;
> }
> --
> 2.27.0
>
[PATCH] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts patch Beryllium boots AOSP up
to ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a couple of additional smmu patches (under review) from here
to boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 320 ++
2 files changed, 321 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..68ccf53d88ca
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies, Inc. Beryllium";
+ compatible = "qcom,sdm845";
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 =
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: vdc-5v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_5V";
+
+ vin-supply = <>;
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <50>;
+ regulator-always-on;
Re: [PATCH 4.9 00/71] 4.9.134-stable review
Hi,
On Tue, 16 Oct 2018 at 22:52, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.134 release.
> There are 71 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
..
> Paul Burton
> MIPS: VDSO: Always map near top of user memory
This patch broke stable-rc/linux-4.9.y build on kernelci
https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.133-72-gda849e5647be/,
mostly because of missing mips_gic_present() definition. It is added
in 582e2b4aecda ("MIPS: GIC: Introduce asm/mips-gic.h with accessor
functions"), which need to be backported too because it doesn't apply
cleanly on linux-4.9.y.
Regards,
Amit Pundir
>
> Jann Horn
> mm/vmstat.c: fix outdated vmstat_text
>
> Daniel Rosenberg
> ext4: Fix error code in ext4_xattr_set_entry()
>
> Amber Lin
> drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
>
> Vitaly Kuznetsov
> x86/kvm/lapic: always disable MMIO interface in x2APIC mode
>
> Nicolas Ferre
> ARM: dts: at91: add new compatibility string for macb on sama5d3
>
> Nicolas Ferre
> net: macb: disable scatter-gather for macb on sama5d3
>
> Jongsung Kim
> stmmac: fix valid numbers of unicast filter entries
>
> Yu Zhao
> sound: enable interrupt after dma buffer initialization
>
> Dan Carpenter
> scsi: qla2xxx: Fix an endian bug in fcpcmd_is_corrupted()
>
> Laura Abbott
> scsi: iscsi: target: Don't use stack buffer for scatterlist
>
> Tony Lindgren
> mfd: omap-usb-host: Fix dts probe of children
>
> Lei Yang
> selftests: memory-hotplug: add required configs
>
> Lei Yang
> selftests/efivarfs: add required kernel configs
>
> Danny Smith
> ASoC: sigmadsp: safeload should not have lower byte limit
>
> Pierre-Louis Bossart
> ASoC: wm8804: Add ACPI support
>
>
> -
>
> Diffstat:
>
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> Documentation/networking/ip-sysctl.txt | 13 +-
> Makefile | 4 +-
> arch/arm/boot/dts/sama5d3_emac.dtsi| 2 +-
> arch/mips/include/asm/processor.h | 10 +-
> arch/mips/kernel/process.c | 25 +
> arch/mips/kernel/vdso.c| 18 +-
> arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +-
> arch/x86/include/asm/pgtable_types.h | 2 +-
> arch/x86/include/uapi/asm/kvm.h| 1 +
> arch/x86/kvm/lapic.c | 22 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
> drivers/i2c/busses/i2c-scmi.c | 1 +
> drivers/mfd/omap-usb-host.c| 11 +-
> drivers/net/bonding/bond_main.c| 43 +-
> drivers/net/dsa/bcm_sf2.c | 12 +-
> drivers/net/ethernet/broadcom/bcmsysport.c | 22 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 +-
> drivers/net/ethernet/cadence/macb.c| 8 +
> drivers/net/ethernet/hisilicon/hns/hnae.c | 2 +-
> drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 +-
> drivers/net/ethernet/marvell/mvpp2.c | 10 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic.h| 8 +-
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c| 3 +-
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h| 3 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h | 3 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 12 +-
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +-
> drivers/net/team/team.c| 5 +
> drivers/net/usb/qmi_wwan.c | 1 +
> drivers/net/usb/smsc75xx.c | 1 +
> drivers/scsi/qla2xxx/qla_target.h | 4 +-
> drivers/target/iscsi/iscsi_target.c| 22 +-
> drivers/usb/host/xhci-hub.c| 18 +-
> drivers/video/fbdev/aty/atyfb.h| 3 +-
> drivers/video/fbdev/aty/atyfb_base.c | 7 +-
> drivers/video/fbdev/aty/mach64_ct.c| 10 +-
> fs/ext4/xattr.c| 2 +-
> include/linux/netdevice.h | 7 +
> include/linux/rhashtable.h | 4 +-
> include/linux/skbuff.h | 34 +-
> include/net/bonding.h | 7 +-
> include/net/inet_frag.h| 133 +++--
> include/
Re: [PATCH 4.9 00/71] 4.9.134-stable review
Hi,
On Tue, 16 Oct 2018 at 22:52, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.134 release.
> There are 71 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
..
> Paul Burton
> MIPS: VDSO: Always map near top of user memory
This patch broke stable-rc/linux-4.9.y build on kernelci
https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.133-72-gda849e5647be/,
mostly because of missing mips_gic_present() definition. It is added
in 582e2b4aecda ("MIPS: GIC: Introduce asm/mips-gic.h with accessor
functions"), which need to be backported too because it doesn't apply
cleanly on linux-4.9.y.
Regards,
Amit Pundir
>
> Jann Horn
> mm/vmstat.c: fix outdated vmstat_text
>
> Daniel Rosenberg
> ext4: Fix error code in ext4_xattr_set_entry()
>
> Amber Lin
> drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
>
> Vitaly Kuznetsov
> x86/kvm/lapic: always disable MMIO interface in x2APIC mode
>
> Nicolas Ferre
> ARM: dts: at91: add new compatibility string for macb on sama5d3
>
> Nicolas Ferre
> net: macb: disable scatter-gather for macb on sama5d3
>
> Jongsung Kim
> stmmac: fix valid numbers of unicast filter entries
>
> Yu Zhao
> sound: enable interrupt after dma buffer initialization
>
> Dan Carpenter
> scsi: qla2xxx: Fix an endian bug in fcpcmd_is_corrupted()
>
> Laura Abbott
> scsi: iscsi: target: Don't use stack buffer for scatterlist
>
> Tony Lindgren
> mfd: omap-usb-host: Fix dts probe of children
>
> Lei Yang
> selftests: memory-hotplug: add required configs
>
> Lei Yang
> selftests/efivarfs: add required kernel configs
>
> Danny Smith
> ASoC: sigmadsp: safeload should not have lower byte limit
>
> Pierre-Louis Bossart
> ASoC: wm8804: Add ACPI support
>
>
> -
>
> Diffstat:
>
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> Documentation/networking/ip-sysctl.txt | 13 +-
> Makefile | 4 +-
> arch/arm/boot/dts/sama5d3_emac.dtsi| 2 +-
> arch/mips/include/asm/processor.h | 10 +-
> arch/mips/kernel/process.c | 25 +
> arch/mips/kernel/vdso.c| 18 +-
> arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +-
> arch/x86/include/asm/pgtable_types.h | 2 +-
> arch/x86/include/uapi/asm/kvm.h| 1 +
> arch/x86/kvm/lapic.c | 22 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
> drivers/i2c/busses/i2c-scmi.c | 1 +
> drivers/mfd/omap-usb-host.c| 11 +-
> drivers/net/bonding/bond_main.c| 43 +-
> drivers/net/dsa/bcm_sf2.c | 12 +-
> drivers/net/ethernet/broadcom/bcmsysport.c | 22 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 +-
> drivers/net/ethernet/cadence/macb.c| 8 +
> drivers/net/ethernet/hisilicon/hns/hnae.c | 2 +-
> drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 +-
> drivers/net/ethernet/marvell/mvpp2.c | 10 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic.h| 8 +-
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c| 3 +-
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h| 3 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h | 3 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 12 +-
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +-
> drivers/net/team/team.c| 5 +
> drivers/net/usb/qmi_wwan.c | 1 +
> drivers/net/usb/smsc75xx.c | 1 +
> drivers/scsi/qla2xxx/qla_target.h | 4 +-
> drivers/target/iscsi/iscsi_target.c| 22 +-
> drivers/usb/host/xhci-hub.c| 18 +-
> drivers/video/fbdev/aty/atyfb.h| 3 +-
> drivers/video/fbdev/aty/atyfb_base.c | 7 +-
> drivers/video/fbdev/aty/mach64_ct.c| 10 +-
> fs/ext4/xattr.c| 2 +-
> include/linux/netdevice.h | 7 +
> include/linux/rhashtable.h | 4 +-
> include/linux/skbuff.h | 34 +-
> include/net/bonding.h | 7 +-
> include/net/inet_frag.h| 133 +++--
> include/
Re: [PATCH 4.14 29/45] cgroup/cpuset: remove circular dependency deadlock
On Fri, 12 Oct 2018 at 16:35, Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 11, 2018 at 08:33:34PM +0100, Sudip Mukherjee wrote:
> > Hi Greg,
> >
> > On Thu, Oct 11, 2018 at 4:54 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > > --
> > >
> > > From: Prateek Sood
> > >
> > > commit aa24163b2ee5c92120e32e99b5a93143a0f4258e upstream.
> >
> > This has been already reverted in upstream.
> > bdfbbda90aeb ("Revert "cgroup/cpuset: remove circular dependency deadlock"")
> >
> > Might be better to add e8b3f8db7aad ("workqueue/hotplug: simplify
> > workqueue_offline_cpu()") instead which is mentioned in the revert
> > commit.
>
> Good point. I'm dropping this patch for now.
>
> Amit, can you test the above patch instead and figure out why you wanted
> to add a patch to the tree that ended up being reverted? :)
Sorry I goofed up here. Thank you Sudip for catching this.
I forgot to look up for the upstream followup fixes for the patches
which I submitted lately and missed out on this Revert.
msm-4.9 tree, which I'm currently looking at, didn't revert this
particular patch either. It did cherry-pick e8b3f8db7aad
("workqueue/hotplug: simplify workqueue_offline_cpu()") as well
though.
About e8b3f8db7aad ("workqueue/hotplug: simplify workqueue_offline_cpu()"):
commit e8b3f8db7aad99fcc5234fc5b89984ff6620de3d
Author: Lai Jiangshan
Date: Fri Dec 1 22:20:36 2017 +0800
workqueue/hotplug: simplify workqueue_offline_cpu()
Since the recent cpu/hotplug refactoring, workqueue_offline_cpu() is
guaranteed to run on the local cpu which is going offline.
This also fixes the following deadlock by removing work item
scheduling and flushing from CPU hotplug path.
http://lkml.kernel.org/r/1504764252-29091-1-git-send-email-prs...@codeaurora.org
This patch applies cleanly to 4.14.y and 4.9.y. But I'm confused if
this particular patch alone is good enough for these stable kernels,
since the commit message talks about some "recent cpu/hotplug
refactoring" dependency(?).
Regards,
Amit Pundir
>
> thanks,
>
> greg k-h
>
> >
> > --
> > Regards
> > Sudip
Re: [PATCH 4.14 29/45] cgroup/cpuset: remove circular dependency deadlock
On Fri, 12 Oct 2018 at 16:35, Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 11, 2018 at 08:33:34PM +0100, Sudip Mukherjee wrote:
> > Hi Greg,
> >
> > On Thu, Oct 11, 2018 at 4:54 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > > --
> > >
> > > From: Prateek Sood
> > >
> > > commit aa24163b2ee5c92120e32e99b5a93143a0f4258e upstream.
> >
> > This has been already reverted in upstream.
> > bdfbbda90aeb ("Revert "cgroup/cpuset: remove circular dependency deadlock"")
> >
> > Might be better to add e8b3f8db7aad ("workqueue/hotplug: simplify
> > workqueue_offline_cpu()") instead which is mentioned in the revert
> > commit.
>
> Good point. I'm dropping this patch for now.
>
> Amit, can you test the above patch instead and figure out why you wanted
> to add a patch to the tree that ended up being reverted? :)
Sorry I goofed up here. Thank you Sudip for catching this.
I forgot to look up for the upstream followup fixes for the patches
which I submitted lately and missed out on this Revert.
msm-4.9 tree, which I'm currently looking at, didn't revert this
particular patch either. It did cherry-pick e8b3f8db7aad
("workqueue/hotplug: simplify workqueue_offline_cpu()") as well
though.
About e8b3f8db7aad ("workqueue/hotplug: simplify workqueue_offline_cpu()"):
commit e8b3f8db7aad99fcc5234fc5b89984ff6620de3d
Author: Lai Jiangshan
Date: Fri Dec 1 22:20:36 2017 +0800
workqueue/hotplug: simplify workqueue_offline_cpu()
Since the recent cpu/hotplug refactoring, workqueue_offline_cpu() is
guaranteed to run on the local cpu which is going offline.
This also fixes the following deadlock by removing work item
scheduling and flushing from CPU hotplug path.
http://lkml.kernel.org/r/1504764252-29091-1-git-send-email-prs...@codeaurora.org
This patch applies cleanly to 4.14.y and 4.9.y. But I'm confused if
this particular patch alone is good enough for these stable kernels,
since the commit message talks about some "recent cpu/hotplug
refactoring" dependency(?).
Regards,
Amit Pundir
>
> thanks,
>
> greg k-h
>
> >
> > --
> > Regards
> > Sudip
Re: Linux 4.18-rc7
On Wed, 1 Aug 2018 at 22:45, Linus Torvalds
wrote:
>
> I'd like to get this sorted out asap, although at this point I still
> think that I'll have to do an rc8 even though I feel like we may have
> caught everything.
No AOSP regressions in my limited smoke testing so far with
current HEAD: 6b4703768268 ("Merge branch 'fixes' of
git://git.armlinux.org.uk/~rmk/linux-arm"). Thanks.
Regards,
Amit Pundir
Re: Linux 4.18-rc7
On Wed, 1 Aug 2018 at 22:45, Linus Torvalds
wrote:
>
> I'd like to get this sorted out asap, although at this point I still
> think that I'll have to do an rc8 even though I feel like we may have
> caught everything.
No AOSP regressions in my limited smoke testing so far with
current HEAD: 6b4703768268 ("Merge branch 'fixes' of
git://git.armlinux.org.uk/~rmk/linux-arm"). Thanks.
Regards,
Amit Pundir
Re: Linux 4.18-rc7
On Tue, 31 Jul 2018 at 09:55, John Stultz wrote: > > On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote: > > On Mon, 30 Jul 2018, Linus Torvalds wrote: > >> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > >> > > >> > I have no problem with reverting -rc7's vma_is_anonymous() series. > >> > >> I don't think we need to revert the whole series: I think the rest are > >> all fairly obvious cleanups, and shouldn't really have any semantic > >> changes. > > > > Okay. > > > >> > >> It's literally only that last patch in the series that then changes > >> that meaning of "vm_ops". And I don't really _mind_ that last step > >> either, but since we don't know exactly what it was that it broke, and > >> we're past rc7, I don't think we really have any option but the revert > >> it. > > > > It took me a long time to grasp what was happening, that that last > > patch bfd40eaff5ab was fixing. Not quite explained in the commit. > > > > I think it was that by mistakenly passing the vma_is_anonymous() test, > > create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of > > COWing pages from kcov); which the truncate then had to split, and in > > going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > > > >> > >> And if we revert it, I think we need to just remove the > >> VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > >> it is quite likely that the real bug is that overzealous BUG_ON(), > >> since I can't see any reason why anonymous mappings should be special > >> there. > > > > Yes, that probably has to go: but it's not clear what state it leaves > > us in, with an anon THP being split by a truncate, without the expected > > locking; I don't remember offhand, probably a subtler bug than that BUG, > > which you may or may not consider an improvement. > > > > I fear that Kirill has not missed inserting a vma_set_anonymous() from > > somewhere that it should be, but rather that zygote is working with some > > special mapping which used to satisfy vma_is_anonymous(), faults supplying > > backing pages, but now comes out as !vma_is_anonymous(), so do_fault() > > finds !dummy_vm_ops.fault hence SIGBUS. > > I've been only casually following this thread (mostly just glad Amit > caught it and I could avoid having to bisect the issue in my own > Android testing), but this bit starting to shake a few old cobwebs > loose in my brain. > > I'm wondering if Zygote is utilizing ashmem here, and we're somehow > traversing ashmem purged memory, or due to some setup issue the > initial traverse isn't being zero-filled as expected? > > ashmem ranges are created using: shmem_file_setup() and shmem_zero_setup() > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n377 > > > If we purge pages, it punches it out with: > vfs_fallocate(range->asma->file, > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > start, end - start); > here: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n447 > > But in ashmem_pin(), we don't do anything other then returning if we > purged any page in the range. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n577 > > And I believe the future assumption is the if we traverse those pages > they will be zero filled (if purged or even during the initial > traversal after mmap) > > Its been a long time, and I've not looked at the code in question but > it sounds from Hugh's comments above that we might instead get a > SIGBUS here. > > Looking more at the problematic patch.. > Amit: Does adding something like (whitespace damaged, apologies): > > index a1a0025..1af6915 100644 > --- a/drivers/staging/android/ashmem.c > +++ b/drivers/staging/android/ashmem.c > @@ -402,7 +402,8 @@ static int ashmem_mmap(struct file *file, struct > vm_area_struct *vma) > fput(asma->file); > goto out; > } > - } > + } else > + vma_set_anonymous(vma); > > if (vma->vm_file) > fput(vma->vm_file); > This ashmem change ^^ worked too. Regards, Amit Pundir > > Seem to resolve it? (Sorry, I'd test it myself, but I'm away from my > desk for the night). > thanks > -john
Re: Linux 4.18-rc7
On Tue, 31 Jul 2018 at 09:55, John Stultz wrote: > > On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote: > > On Mon, 30 Jul 2018, Linus Torvalds wrote: > >> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > >> > > >> > I have no problem with reverting -rc7's vma_is_anonymous() series. > >> > >> I don't think we need to revert the whole series: I think the rest are > >> all fairly obvious cleanups, and shouldn't really have any semantic > >> changes. > > > > Okay. > > > >> > >> It's literally only that last patch in the series that then changes > >> that meaning of "vm_ops". And I don't really _mind_ that last step > >> either, but since we don't know exactly what it was that it broke, and > >> we're past rc7, I don't think we really have any option but the revert > >> it. > > > > It took me a long time to grasp what was happening, that that last > > patch bfd40eaff5ab was fixing. Not quite explained in the commit. > > > > I think it was that by mistakenly passing the vma_is_anonymous() test, > > create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of > > COWing pages from kcov); which the truncate then had to split, and in > > going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > > > >> > >> And if we revert it, I think we need to just remove the > >> VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > >> it is quite likely that the real bug is that overzealous BUG_ON(), > >> since I can't see any reason why anonymous mappings should be special > >> there. > > > > Yes, that probably has to go: but it's not clear what state it leaves > > us in, with an anon THP being split by a truncate, without the expected > > locking; I don't remember offhand, probably a subtler bug than that BUG, > > which you may or may not consider an improvement. > > > > I fear that Kirill has not missed inserting a vma_set_anonymous() from > > somewhere that it should be, but rather that zygote is working with some > > special mapping which used to satisfy vma_is_anonymous(), faults supplying > > backing pages, but now comes out as !vma_is_anonymous(), so do_fault() > > finds !dummy_vm_ops.fault hence SIGBUS. > > I've been only casually following this thread (mostly just glad Amit > caught it and I could avoid having to bisect the issue in my own > Android testing), but this bit starting to shake a few old cobwebs > loose in my brain. > > I'm wondering if Zygote is utilizing ashmem here, and we're somehow > traversing ashmem purged memory, or due to some setup issue the > initial traverse isn't being zero-filled as expected? > > ashmem ranges are created using: shmem_file_setup() and shmem_zero_setup() > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n377 > > > If we purge pages, it punches it out with: > vfs_fallocate(range->asma->file, > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > start, end - start); > here: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n447 > > But in ashmem_pin(), we don't do anything other then returning if we > purged any page in the range. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n577 > > And I believe the future assumption is the if we traverse those pages > they will be zero filled (if purged or even during the initial > traversal after mmap) > > Its been a long time, and I've not looked at the code in question but > it sounds from Hugh's comments above that we might instead get a > SIGBUS here. > > Looking more at the problematic patch.. > Amit: Does adding something like (whitespace damaged, apologies): > > index a1a0025..1af6915 100644 > --- a/drivers/staging/android/ashmem.c > +++ b/drivers/staging/android/ashmem.c > @@ -402,7 +402,8 @@ static int ashmem_mmap(struct file *file, struct > vm_area_struct *vma) > fput(asma->file); > goto out; > } > - } > + } else > + vma_set_anonymous(vma); > > if (vma->vm_file) > fput(vma->vm_file); > This ashmem change ^^ worked too. Regards, Amit Pundir > > Seem to resolve it? (Sorry, I'd test it myself, but I'm away from my > desk for the night). > thanks > -john
Re: Linux 4.18-rc7
On Mon, 30 Jul 2018 at 18:31, Kirill A. Shutemov wrote:
>
> On Mon, Jul 30, 2018 at 12:17:46PM +0530, Amit Pundir wrote:
> > On Mon, 30 Jul 2018 at 03:39, Linus Torvalds
> > wrote:
> > >
> > > So unless something odd happens, this should be the last rc for 4.18.
> > >
> > > Nothing particularly odd happened this last week - we got the usual
> > > random set of various minor fixes all over. About two thirds of it is
> > > drivers - networking, staging and usb stands out, but there's a little
> > > bit of stuff all over (clk, block, gpu, nvme..).
> > >
> > > Outside of drivers, the bulk is some core networking stuff, with
> > > random changes elsewhere (minor arch updates, filesystems, core
> > > kernel, test scripts).
> > >
> > > The appended shortlog gives a flavor of the details.
> > >
> > > Linus
> > >
> > > ---
> > > Kirill A. Shutemov (3):
> > > mm: introduce vma_init()
> > > mm: use vma_init() to initialize VMAs on stack and data segments
> > > mm: fix vma_is_anonymous() false-positives
> >
> > Hi, I have run into AOSP userspace crash with v4.18-rc7, leading to
> > above mm patches. bfd40eaff5ab ("mm: fix vma_is_anonymous()
> > false-positives") to be specific. The same userspace is working fine
> > with v4.18-rc6.
> >
> > I didn't yet look into what is going wrong from userspace point of
> > view, but I just wanted to give you a heads up on this. I'll be happy
> > to assist in further debugging/diagnosis if required.
>
> Youling reported basically the same bug with zygote crashing, but on
> x86-64.
>
> I think I missed vma_set_anonymous() somewhere, but I fail to see where.
>
> Could you check if removing 'vma->vm_ops = _vm_ops;" from vma_init
> makes the problem go away?
Yes removing 'vma->vm_ops = _vm_ops;" from vma_init() works.
Crash is gone with that change.
>
> Any chance the code that crashes can be run under strace?
Running strace on zygote is going to be a pain. I can check logcat
again and see if any other relatively less complex process is crashing
with similar backtrace and try to run that with strace if that is
still required.
Regards,
Amit Pundir
>
> > Here is the crash log from logcat, if it helps:
> > F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
> > F DEBUG : Build fingerprint:
> > 'Android/db410c32_only/db410c32_only:Q/OC-MR1/102:userdebug/test-key
> > F DEBUG : Revision: '0'
> > F DEBUG : ABI: 'arm'
> > F DEBUG : pid: 2261, tid: 2261, name: zygote >>> zygote <<<
> > F DEBUG : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0xec8
> > .. ..
> > F DEBUG : backtrace:
> > F DEBUG : #00 pc 1c04 /system/lib/libc.so (memset+48)
> > F DEBUG : #01 pc 0010c513 /system/lib/libart.so
> > (create_mspace_with_base+82)
> > F DEBUG : #02 pc 0015c601 /system/lib/libart.so
> > (art::gc::space::DlMallocSpace::CreateMspace(void*, unsigned int,
> > unsigned int)+40)
> > F DEBUG : #03 pc 0015c3ed /system/lib/libart.so
> > (art::gc::space::DlMallocSpace::CreateFromMemMap(art::MemMap*,
> > std::__1::basic_string > 1::char_traits, std::__1::allocator> const&, unsigned int,
> > unsigned int, unsigned int, unsigned int, bool)+36)
> > F DEBUG : #04 pc 0013c9ab /system/lib/libart.so
> > (art::gc::Heap::Heap(unsigned int, unsigned int, unsigned int,
> > unsigned int, double, double, unsigned int, unsigned int,
> > std::__1::basic_string,
> > std::__1::allocator> const&, art::InstructionSet,
> > art::gc::CollectorType, art::gc::CollectorType,
> > art::gc::space::LargeObjectSpaceType, unsigned int, unsigned int,
> > unsigned int, bool, unsigned int, unsigned int, bool, bool, bool,
> > bool, bool, bool, bool, bool, bool, bool, bool, unsigned long
> > long)+1674)
> > DEBUG : #05 pc 00318201 /system/lib/libart.so
> > (art::Runtime::Init(art::RuntimeArgumentMap&&)+7036)
> > DEBUG : #06 pc 0031af19 /system/lib/libart.so
> > (art::Runtime::Create(std::__1::vector > std::__1::char_traits, std::__1::allocator>, void const*>,
> > std::__1::allocator > std::__1::char_traits, std::__1::allocator>, void
> > const*>>> const&, bool)+68)
> > F DEBUG : #07 pc 0023c353 /system/lib/libart.so
> > (JNI_CreateJavaVM+658)
> > F DEBUG : #08 pc 205f /system/lib/libandroid_runtime.so
> > (android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool)+5038)
> > F DEBUG : #09 pc 2381 /system/lib/libandroid_runtime.so
> > (android::AndroidRuntime::start(char const*,
> > android::Vector const&, bool)+196)
> > F DEBUG : #10 pc 046b /system/bin/app_process32 (main+702)
> >
> > Regards,
> > Amit Pundir
> >
>
> --
> Kirill A. Shutemov
Re: Linux 4.18-rc7
On Mon, 30 Jul 2018 at 18:31, Kirill A. Shutemov wrote:
>
> On Mon, Jul 30, 2018 at 12:17:46PM +0530, Amit Pundir wrote:
> > On Mon, 30 Jul 2018 at 03:39, Linus Torvalds
> > wrote:
> > >
> > > So unless something odd happens, this should be the last rc for 4.18.
> > >
> > > Nothing particularly odd happened this last week - we got the usual
> > > random set of various minor fixes all over. About two thirds of it is
> > > drivers - networking, staging and usb stands out, but there's a little
> > > bit of stuff all over (clk, block, gpu, nvme..).
> > >
> > > Outside of drivers, the bulk is some core networking stuff, with
> > > random changes elsewhere (minor arch updates, filesystems, core
> > > kernel, test scripts).
> > >
> > > The appended shortlog gives a flavor of the details.
> > >
> > > Linus
> > >
> > > ---
> > > Kirill A. Shutemov (3):
> > > mm: introduce vma_init()
> > > mm: use vma_init() to initialize VMAs on stack and data segments
> > > mm: fix vma_is_anonymous() false-positives
> >
> > Hi, I have run into AOSP userspace crash with v4.18-rc7, leading to
> > above mm patches. bfd40eaff5ab ("mm: fix vma_is_anonymous()
> > false-positives") to be specific. The same userspace is working fine
> > with v4.18-rc6.
> >
> > I didn't yet look into what is going wrong from userspace point of
> > view, but I just wanted to give you a heads up on this. I'll be happy
> > to assist in further debugging/diagnosis if required.
>
> Youling reported basically the same bug with zygote crashing, but on
> x86-64.
>
> I think I missed vma_set_anonymous() somewhere, but I fail to see where.
>
> Could you check if removing 'vma->vm_ops = _vm_ops;" from vma_init
> makes the problem go away?
Yes removing 'vma->vm_ops = _vm_ops;" from vma_init() works.
Crash is gone with that change.
>
> Any chance the code that crashes can be run under strace?
Running strace on zygote is going to be a pain. I can check logcat
again and see if any other relatively less complex process is crashing
with similar backtrace and try to run that with strace if that is
still required.
Regards,
Amit Pundir
>
> > Here is the crash log from logcat, if it helps:
> > F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
> > F DEBUG : Build fingerprint:
> > 'Android/db410c32_only/db410c32_only:Q/OC-MR1/102:userdebug/test-key
> > F DEBUG : Revision: '0'
> > F DEBUG : ABI: 'arm'
> > F DEBUG : pid: 2261, tid: 2261, name: zygote >>> zygote <<<
> > F DEBUG : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0xec8
> > .. ..
> > F DEBUG : backtrace:
> > F DEBUG : #00 pc 1c04 /system/lib/libc.so (memset+48)
> > F DEBUG : #01 pc 0010c513 /system/lib/libart.so
> > (create_mspace_with_base+82)
> > F DEBUG : #02 pc 0015c601 /system/lib/libart.so
> > (art::gc::space::DlMallocSpace::CreateMspace(void*, unsigned int,
> > unsigned int)+40)
> > F DEBUG : #03 pc 0015c3ed /system/lib/libart.so
> > (art::gc::space::DlMallocSpace::CreateFromMemMap(art::MemMap*,
> > std::__1::basic_string > 1::char_traits, std::__1::allocator> const&, unsigned int,
> > unsigned int, unsigned int, unsigned int, bool)+36)
> > F DEBUG : #04 pc 0013c9ab /system/lib/libart.so
> > (art::gc::Heap::Heap(unsigned int, unsigned int, unsigned int,
> > unsigned int, double, double, unsigned int, unsigned int,
> > std::__1::basic_string,
> > std::__1::allocator> const&, art::InstructionSet,
> > art::gc::CollectorType, art::gc::CollectorType,
> > art::gc::space::LargeObjectSpaceType, unsigned int, unsigned int,
> > unsigned int, bool, unsigned int, unsigned int, bool, bool, bool,
> > bool, bool, bool, bool, bool, bool, bool, bool, unsigned long
> > long)+1674)
> > DEBUG : #05 pc 00318201 /system/lib/libart.so
> > (art::Runtime::Init(art::RuntimeArgumentMap&&)+7036)
> > DEBUG : #06 pc 0031af19 /system/lib/libart.so
> > (art::Runtime::Create(std::__1::vector > std::__1::char_traits, std::__1::allocator>, void const*>,
> > std::__1::allocator > std::__1::char_traits, std::__1::allocator>, void
> > const*>>> const&, bool)+68)
> > F DEBUG : #07 pc 0023c353 /system/lib/libart.so
> > (JNI_CreateJavaVM+658)
> > F DEBUG : #08 pc 205f /system/lib/libandroid_runtime.so
> > (android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool)+5038)
> > F DEBUG : #09 pc 2381 /system/lib/libandroid_runtime.so
> > (android::AndroidRuntime::start(char const*,
> > android::Vector const&, bool)+196)
> > F DEBUG : #10 pc 046b /system/bin/app_process32 (main+702)
> >
> > Regards,
> > Amit Pundir
> >
>
> --
> Kirill A. Shutemov
Re: Linux 4.18-rc7
On Mon, 30 Jul 2018 at 03:39, Linus Torvalds
wrote:
>
> So unless something odd happens, this should be the last rc for 4.18.
>
> Nothing particularly odd happened this last week - we got the usual
> random set of various minor fixes all over. About two thirds of it is
> drivers - networking, staging and usb stands out, but there's a little
> bit of stuff all over (clk, block, gpu, nvme..).
>
> Outside of drivers, the bulk is some core networking stuff, with
> random changes elsewhere (minor arch updates, filesystems, core
> kernel, test scripts).
>
> The appended shortlog gives a flavor of the details.
>
> Linus
>
> ---
> Kirill A. Shutemov (3):
> mm: introduce vma_init()
> mm: use vma_init() to initialize VMAs on stack and data segments
> mm: fix vma_is_anonymous() false-positives
Hi, I have run into AOSP userspace crash with v4.18-rc7, leading to
above mm patches. bfd40eaff5ab ("mm: fix vma_is_anonymous()
false-positives") to be specific. The same userspace is working fine
with v4.18-rc6.
I didn't yet look into what is going wrong from userspace point of
view, but I just wanted to give you a heads up on this. I'll be happy
to assist in further debugging/diagnosis if required.
Here is the crash log from logcat, if it helps:
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint:
'Android/db410c32_only/db410c32_only:Q/OC-MR1/102:userdebug/test-key
F DEBUG : Revision: '0'
F DEBUG : ABI: 'arm'
F DEBUG : pid: 2261, tid: 2261, name: zygote >>> zygote <<<
F DEBUG : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0xec8
.. ..
F DEBUG : backtrace:
F DEBUG : #00 pc 1c04 /system/lib/libc.so (memset+48)
F DEBUG : #01 pc 0010c513 /system/lib/libart.so
(create_mspace_with_base+82)
F DEBUG : #02 pc 0015c601 /system/lib/libart.so
(art::gc::space::DlMallocSpace::CreateMspace(void*, unsigned int,
unsigned int)+40)
F DEBUG : #03 pc 0015c3ed /system/lib/libart.so
(art::gc::space::DlMallocSpace::CreateFromMemMap(art::MemMap*,
std::__1::basic_string, std::__1::allocator> const&, unsigned int,
unsigned int, unsigned int, unsigned int, bool)+36)
F DEBUG : #04 pc 0013c9ab /system/lib/libart.so
(art::gc::Heap::Heap(unsigned int, unsigned int, unsigned int,
unsigned int, double, double, unsigned int, unsigned int,
std::__1::basic_string,
std::__1::allocator> const&, art::InstructionSet,
art::gc::CollectorType, art::gc::CollectorType,
art::gc::space::LargeObjectSpaceType, unsigned int, unsigned int,
unsigned int, bool, unsigned int, unsigned int, bool, bool, bool,
bool, bool, bool, bool, bool, bool, bool, bool, unsigned long
long)+1674)
DEBUG : #05 pc 00318201 /system/lib/libart.so
(art::Runtime::Init(art::RuntimeArgumentMap&&)+7036)
DEBUG : #06 pc 0031af19 /system/lib/libart.so
(art::Runtime::Create(std::__1::vector, std::__1::allocator>, void const*>,
std::__1::allocator, std::__1::allocator>, void
const*>>> const&, bool)+68)
F DEBUG : #07 pc 0023c353 /system/lib/libart.so (JNI_CreateJavaVM+658)
F DEBUG : #08 pc 205f /system/lib/libandroid_runtime.so
(android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool)+5038)
F DEBUG : #09 pc 2381 /system/lib/libandroid_runtime.so
(android::AndroidRuntime::start(char const*,
android::Vector const&, bool)+196)
F DEBUG : #10 pc 046b /system/bin/app_process32 (main+702)
Regards,
Amit Pundir
Re: Linux 4.18-rc7
On Mon, 30 Jul 2018 at 03:39, Linus Torvalds
wrote:
>
> So unless something odd happens, this should be the last rc for 4.18.
>
> Nothing particularly odd happened this last week - we got the usual
> random set of various minor fixes all over. About two thirds of it is
> drivers - networking, staging and usb stands out, but there's a little
> bit of stuff all over (clk, block, gpu, nvme..).
>
> Outside of drivers, the bulk is some core networking stuff, with
> random changes elsewhere (minor arch updates, filesystems, core
> kernel, test scripts).
>
> The appended shortlog gives a flavor of the details.
>
> Linus
>
> ---
> Kirill A. Shutemov (3):
> mm: introduce vma_init()
> mm: use vma_init() to initialize VMAs on stack and data segments
> mm: fix vma_is_anonymous() false-positives
Hi, I have run into AOSP userspace crash with v4.18-rc7, leading to
above mm patches. bfd40eaff5ab ("mm: fix vma_is_anonymous()
false-positives") to be specific. The same userspace is working fine
with v4.18-rc6.
I didn't yet look into what is going wrong from userspace point of
view, but I just wanted to give you a heads up on this. I'll be happy
to assist in further debugging/diagnosis if required.
Here is the crash log from logcat, if it helps:
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint:
'Android/db410c32_only/db410c32_only:Q/OC-MR1/102:userdebug/test-key
F DEBUG : Revision: '0'
F DEBUG : ABI: 'arm'
F DEBUG : pid: 2261, tid: 2261, name: zygote >>> zygote <<<
F DEBUG : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0xec8
.. ..
F DEBUG : backtrace:
F DEBUG : #00 pc 1c04 /system/lib/libc.so (memset+48)
F DEBUG : #01 pc 0010c513 /system/lib/libart.so
(create_mspace_with_base+82)
F DEBUG : #02 pc 0015c601 /system/lib/libart.so
(art::gc::space::DlMallocSpace::CreateMspace(void*, unsigned int,
unsigned int)+40)
F DEBUG : #03 pc 0015c3ed /system/lib/libart.so
(art::gc::space::DlMallocSpace::CreateFromMemMap(art::MemMap*,
std::__1::basic_string, std::__1::allocator> const&, unsigned int,
unsigned int, unsigned int, unsigned int, bool)+36)
F DEBUG : #04 pc 0013c9ab /system/lib/libart.so
(art::gc::Heap::Heap(unsigned int, unsigned int, unsigned int,
unsigned int, double, double, unsigned int, unsigned int,
std::__1::basic_string,
std::__1::allocator> const&, art::InstructionSet,
art::gc::CollectorType, art::gc::CollectorType,
art::gc::space::LargeObjectSpaceType, unsigned int, unsigned int,
unsigned int, bool, unsigned int, unsigned int, bool, bool, bool,
bool, bool, bool, bool, bool, bool, bool, bool, unsigned long
long)+1674)
DEBUG : #05 pc 00318201 /system/lib/libart.so
(art::Runtime::Init(art::RuntimeArgumentMap&&)+7036)
DEBUG : #06 pc 0031af19 /system/lib/libart.so
(art::Runtime::Create(std::__1::vector, std::__1::allocator>, void const*>,
std::__1::allocator, std::__1::allocator>, void
const*>>> const&, bool)+68)
F DEBUG : #07 pc 0023c353 /system/lib/libart.so (JNI_CreateJavaVM+658)
F DEBUG : #08 pc 205f /system/lib/libandroid_runtime.so
(android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool)+5038)
F DEBUG : #09 pc 2381 /system/lib/libandroid_runtime.so
(android::AndroidRuntime::start(char const*,
android::Vector const&, bool)+196)
F DEBUG : #10 pc 046b /system/bin/app_process32 (main+702)
Regards,
Amit Pundir
[PATCH v3 4/4] NFC: fdp: Remove __func__ from dev_dbg()
Remove redundant __func__ parameter from dev_dgb() calls and
delete empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3:
Updated commit message.
v2:
Deleted empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
drivers/nfc/fdp/fdp.c | 18 +++---
drivers/nfc/fdp/i2c.c | 17 -
2 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a47fc13..f64a6fd65c41 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,8 +249,6 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
r = info->phy_ops->enable(info->phy);
return r;
@@ -261,7 +259,6 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return 0;
}
@@ -270,8 +267,6 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
if (atomic_dec_and_test(>data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +278,6 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,8 +492,6 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
-
r = nci_core_init(ndev);
if (r)
goto error;
@@ -609,7 +601,6 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_reset_ntf = 1;
wake_up(>setup_wq);
@@ -622,7 +613,6 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(>setup_wq);
@@ -637,7 +627,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +640,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +685,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,8 +788,6 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
nci_unregister_device(ndev);
nci_free_device(ndev);
}
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index 2c5ed2224c5e..bb14d30c568c 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,6 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +66,6 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev
[PATCH v3 4/4] NFC: fdp: Remove __func__ from dev_dbg()
Remove redundant __func__ parameter from dev_dgb() calls and
delete empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3:
Updated commit message.
v2:
Deleted empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
drivers/nfc/fdp/fdp.c | 18 +++---
drivers/nfc/fdp/i2c.c | 17 -
2 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a47fc13..f64a6fd65c41 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,8 +249,6 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
r = info->phy_ops->enable(info->phy);
return r;
@@ -261,7 +259,6 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return 0;
}
@@ -270,8 +267,6 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
if (atomic_dec_and_test(>data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +278,6 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,8 +492,6 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
-
r = nci_core_init(ndev);
if (r)
goto error;
@@ -609,7 +601,6 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_reset_ntf = 1;
wake_up(>setup_wq);
@@ -622,7 +613,6 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(>setup_wq);
@@ -637,7 +627,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +640,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +685,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,8 +788,6 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
nci_unregister_device(ndev);
nci_free_device(ndev);
}
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index 2c5ed2224c5e..bb14d30c568c 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,6 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +66,6 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(p
[PATCH v3 2/4] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan <sur...@google.com>
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
cc: Stable <sta...@vger.kernel.org>
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3..v1:
Resend. No changes.
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4bcf8..19cb2e473ea6 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[PATCH v3 2/4] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
cc: Stable
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3..v1:
Resend. No changes.
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4bcf8..19cb2e473ea6 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[PATCH v3 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan <sur...@google.com>
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
cc: Stable <sta...@vger.kernel.org>
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3..v1:
Resend. No changes.
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2917e6..3420c5104c94 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH v3 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
cc: Stable
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3..v1:
Resend. No changes.
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2917e6..3420c5104c94 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH v3 3/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan <sur...@google.com>
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
cc: Stable <sta...@vger.kernel.org>
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3:
Reset next_read_size to a more readable macro FDP_NCI_I2C_MIN_PAYLOAD
instead of 5.
v2:
Remove redundant __func__ from dev_dgb().
drivers/nfc/fdp/i2c.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e07bbc..2c5ed2224c5e 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(>dev, "corrupted packet\n");
+ phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
[PATCH v3 3/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
cc: Stable
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3:
Reset next_read_size to a more readable macro FDP_NCI_I2C_MIN_PAYLOAD
instead of 5.
v2:
Remove redundant __func__ from dev_dgb().
drivers/nfc/fdp/i2c.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e07bbc..2c5ed2224c5e 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(>dev, "corrupted packet\n");
+ phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
Re: [PATCH v2 3/3] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
On 3 May 2018 at 15:50, Andy Shevchenko
<andriy.shevche...@linux.intel.com> wrote:
> On Wed, 2018-05-02 at 23:18 +0530, Amit Pundir wrote:
>> From: Suren Baghdasaryan <sur...@google.com>
>>
>> Possible buffer overflow when reading next_read_size bytes into
>> tmp buffer after next_read_size was extracted from a previous packet.
>>
>> Signed-off-by: Suren Baghdasaryan <sur...@google.com>
>> Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
>> ---
>> v2:
>> Remove redundant __func__ from dev_dgb().
>>
>> drivers/nfc/fdp/i2c.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
>> index c4da50e..b80d1ad 100644
>> --- a/drivers/nfc/fdp/i2c.c
>> +++ b/drivers/nfc/fdp/i2c.c
>> @@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy
>> *phy, struct sk_buff **skb)
>> /* Packet that contains a length */
>> if (tmp[0] == 0 && tmp[1] == 0) {
>> phy->next_read_size = (tmp[2] << 8) + tmp[3]
>> + 3;
>> + /*
>> + * Ensure next_read_size does not exceed
>> sizeof(tmp)
>> + * for reading that many bytes during next
>> iteration
>> + */
>> + if (phy->next_read_size >
>> FDP_NCI_I2C_MAX_PAYLOAD) {
>> + dev_dbg(>dev, "corrupted
>> packet\n");
>
>> + phy->next_read_size = 5;
>
> Shouldn't be this magic replaced by
>
> phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
>
> ?
Ack. Fixing it in v3.
Regards,
Amit Pundir
>
>> + goto flush;
>> + }
>> } else {
>> phy->next_read_size =
>> FDP_NCI_I2C_MIN_PAYLOAD;
>>
>
> --
> Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Intel Finland Oy
Re: [PATCH v2 3/3] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
On 3 May 2018 at 15:50, Andy Shevchenko
wrote:
> On Wed, 2018-05-02 at 23:18 +0530, Amit Pundir wrote:
>> From: Suren Baghdasaryan
>>
>> Possible buffer overflow when reading next_read_size bytes into
>> tmp buffer after next_read_size was extracted from a previous packet.
>>
>> Signed-off-by: Suren Baghdasaryan
>> Signed-off-by: Amit Pundir
>> ---
>> v2:
>> Remove redundant __func__ from dev_dgb().
>>
>> drivers/nfc/fdp/i2c.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
>> index c4da50e..b80d1ad 100644
>> --- a/drivers/nfc/fdp/i2c.c
>> +++ b/drivers/nfc/fdp/i2c.c
>> @@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy
>> *phy, struct sk_buff **skb)
>> /* Packet that contains a length */
>> if (tmp[0] == 0 && tmp[1] == 0) {
>> phy->next_read_size = (tmp[2] << 8) + tmp[3]
>> + 3;
>> + /*
>> + * Ensure next_read_size does not exceed
>> sizeof(tmp)
>> + * for reading that many bytes during next
>> iteration
>> + */
>> + if (phy->next_read_size >
>> FDP_NCI_I2C_MAX_PAYLOAD) {
>> + dev_dbg(>dev, "corrupted
>> packet\n");
>
>> + phy->next_read_size = 5;
>
> Shouldn't be this magic replaced by
>
> phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
>
> ?
Ack. Fixing it in v3.
Regards,
Amit Pundir
>
>> + goto flush;
>> + }
>> } else {
>> phy->next_read_size =
>> FDP_NCI_I2C_MIN_PAYLOAD;
>>
>
> --
> Andy Shevchenko
> Intel Finland Oy
[PATCH v2] NFC: fdp: Remove __func__ from dev_dbg()
Remove redundant __func__ parameter from dev_dgb() calls.
v2:
Deleted empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
drivers/nfc/fdp/fdp.c | 18 +++---
drivers/nfc/fdp/i2c.c | 17 -
2 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a4..f64a6fd 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,8 +249,6 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
r = info->phy_ops->enable(info->phy);
return r;
@@ -261,7 +259,6 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return 0;
}
@@ -270,8 +267,6 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
if (atomic_dec_and_test(>data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +278,6 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,8 +492,6 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
-
r = nci_core_init(ndev);
if (r)
goto error;
@@ -609,7 +601,6 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_reset_ntf = 1;
wake_up(>setup_wq);
@@ -622,7 +613,6 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(>setup_wq);
@@ -637,7 +627,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +640,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +685,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,8 +788,6 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
nci_unregister_device(ndev);
nci_free_device(ndev);
}
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e..f355ab2 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,6 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +66,6 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
}
@@ -113,8 +111,8 @@ static int fdp_nci_i2c_write(void *phy_id, struct sk_buff
*skb)
}
if (r < 0 || r != skb->le
[PATCH v2] NFC: fdp: Remove __func__ from dev_dbg()
Remove redundant __func__ parameter from dev_dgb() calls.
v2:
Deleted empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
Signed-off-by: Amit Pundir
---
drivers/nfc/fdp/fdp.c | 18 +++---
drivers/nfc/fdp/i2c.c | 17 -
2 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a4..f64a6fd 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,8 +249,6 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
r = info->phy_ops->enable(info->phy);
return r;
@@ -261,7 +259,6 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return 0;
}
@@ -270,8 +267,6 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
if (atomic_dec_and_test(>data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +278,6 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,8 +492,6 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
-
r = nci_core_init(ndev);
if (r)
goto error;
@@ -609,7 +601,6 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_reset_ntf = 1;
wake_up(>setup_wq);
@@ -622,7 +613,6 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(>setup_wq);
@@ -637,7 +627,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +640,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +685,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,8 +788,6 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
nci_unregister_device(ndev);
nci_free_device(ndev);
}
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e..f355ab2 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,6 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +66,6 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
}
@@ -113,8 +111,8 @@ static int fdp_nci_i2c_write(void *phy_id, struct sk_buff
*skb)
}
if (r < 0 || r != skb->len)
-
[PATCH] NFC: fdp: Remove __func__ parameter from dev_dbg() call
Remove redundant __func__ parameter from dev_dgb() calls.
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
drivers/nfc/fdp/fdp.c | 22 +++---
drivers/nfc/fdp/i2c.c | 20 +---
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a4..3251346 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,7 +249,7 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
r = info->phy_ops->enable(info->phy);
@@ -261,7 +261,7 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
return 0;
}
@@ -270,7 +270,7 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
if (atomic_dec_and_test(>data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +283,7 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,7 +498,7 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
r = nci_core_init(ndev);
if (r)
@@ -609,7 +609,7 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
info->setup_reset_ntf = 1;
wake_up(>setup_wq);
@@ -622,7 +622,7 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(>setup_wq);
@@ -637,7 +637,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +650,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +695,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,7 +798,7 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
nci_unregister_device(ndev);
nci_free_device(ndev);
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index b80d1ad..3138730 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,7 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
+ dev_dbg(>i2c_dev->dev, "\n");
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +67,7 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = p
[PATCH] NFC: fdp: Remove __func__ parameter from dev_dbg() call
Remove redundant __func__ parameter from dev_dgb() calls.
Signed-off-by: Amit Pundir
---
drivers/nfc/fdp/fdp.c | 22 +++---
drivers/nfc/fdp/i2c.c | 20 +---
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a4..3251346 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,7 +249,7 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
r = info->phy_ops->enable(info->phy);
@@ -261,7 +261,7 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
return 0;
}
@@ -270,7 +270,7 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
if (atomic_dec_and_test(>data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +283,7 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,7 +498,7 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
r = nci_core_init(ndev);
if (r)
@@ -609,7 +609,7 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
info->setup_reset_ntf = 1;
wake_up(>setup_wq);
@@ -622,7 +622,7 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(>setup_wq);
@@ -637,7 +637,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +650,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = >phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +695,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,7 +798,7 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = >phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
nci_unregister_device(ndev);
nci_free_device(ndev);
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index b80d1ad..3138730 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,7 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev, "%s\n", __func__);
+ dev_dbg(>i2c_dev->dev, "\n");
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +67,7 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(>i2c_dev->dev
[PATCH v2 1/3] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan <sur...@google.com>
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
v2:
Resend. No changes.
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2..3420c51 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH v2 1/3] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
v2:
Resend. No changes.
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2..3420c51 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH v2 2/3] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan <sur...@google.com>
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
v2:
Resend. No changes.
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4..19cb2e4 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[PATCH v2 2/3] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
v2:
Resend. No changes.
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4..19cb2e4 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[PATCH v2 3/3] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan <sur...@google.com>
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
v2:
Remove redundant __func__ from dev_dgb().
drivers/nfc/fdp/i2c.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e..b80d1ad 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(>dev, "corrupted packet\n");
+ phy->next_read_size = 5;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
[PATCH v2 3/3] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
v2:
Remove redundant __func__ from dev_dgb().
drivers/nfc/fdp/i2c.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e..b80d1ad 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(>dev, "corrupted packet\n");
+ phy->next_read_size = 5;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
[PATCH v2 0/3] Few NFC fixes from android-4.14 tree
Hi, Submitting v2 of NFC fixes I picked up from android-4.14 tree[1] for review and comments. Again like to point out that I have not feature tested these patches at all. Only made small cosmetic changes to the original patches (removed Android-only tag and internal bug ID) and build tested for arm, before posting them here for review. Really appreciate any comments or feedback on how to take it forward. Changes since v1: * Dropped "NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler" patch for now. I'm yet to verify if the additional aid_len and params_len checks for buffer size are really required, and I didn't want to hold up this patch series for one patch alone. * Dropped redundant __func__ use dev_dbg() in "NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver" patch. Also drivers/nfc/fdp/ is full of __func__ parameter usage in dev_dbg(), so submitting a new patch separately to clean that up. Regards, Amit Pundir [1] https://android.googlesource.com/kernel/common/+log/android-4.14 Suren Baghdasaryan (3): NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ NFC: Fix possible memory corruption when handling SHDLC I-Frame commands NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver drivers/nfc/fdp/fdp.c | 22 +++--- drivers/nfc/fdp/i2c.c | 29 ++--- drivers/nfc/st21nfca/dep.c | 3 ++- net/nfc/hci/core.c | 10 ++ 4 files changed, 41 insertions(+), 23 deletions(-) -- 2.7.4
[PATCH v2 0/3] Few NFC fixes from android-4.14 tree
Hi, Submitting v2 of NFC fixes I picked up from android-4.14 tree[1] for review and comments. Again like to point out that I have not feature tested these patches at all. Only made small cosmetic changes to the original patches (removed Android-only tag and internal bug ID) and build tested for arm, before posting them here for review. Really appreciate any comments or feedback on how to take it forward. Changes since v1: * Dropped "NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler" patch for now. I'm yet to verify if the additional aid_len and params_len checks for buffer size are really required, and I didn't want to hold up this patch series for one patch alone. * Dropped redundant __func__ use dev_dbg() in "NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver" patch. Also drivers/nfc/fdp/ is full of __func__ parameter usage in dev_dbg(), so submitting a new patch separately to clean that up. Regards, Amit Pundir [1] https://android.googlesource.com/kernel/common/+log/android-4.14 Suren Baghdasaryan (3): NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ NFC: Fix possible memory corruption when handling SHDLC I-Frame commands NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver drivers/nfc/fdp/fdp.c | 22 +++--- drivers/nfc/fdp/i2c.c | 29 ++--- drivers/nfc/st21nfca/dep.c | 3 ++- net/nfc/hci/core.c | 10 ++ 4 files changed, 41 insertions(+), 23 deletions(-) -- 2.7.4
Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
On 20 April 2018 at 22:15, Mark Greer <mgr...@animalcreek.com> wrote:
> On Fri, Apr 20, 2018 at 03:39:46PM +0300, Andy Shevchenko wrote:
>> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>>
>> > if (skb->data[transaction->aid_len + 2] !=
>> > - NFC_EVT_TRANSACTION_PARAMS_TAG)
>> > + NFC_EVT_TRANSACTION_PARAMS_TAG ||
>> > + skb->len < transaction->aid_len + transaction-
>> > >params_len + 4) {
>>
>> > + devm_kfree(dev, transaction);
>>
>> Oh, no.
>>
>> This is not memory leak per se, this is bad choice of devm_ API where it
>> should use plain kmalloc() / kfree().
>
> Also, there is no check to see if the allocation worked at all.
Ack. I'll add that in v2.
Thanks.
Regards,
Amit Pundir
>
> Mark
> --
Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
On 20 April 2018 at 22:15, Mark Greer wrote:
> On Fri, Apr 20, 2018 at 03:39:46PM +0300, Andy Shevchenko wrote:
>> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>>
>> > if (skb->data[transaction->aid_len + 2] !=
>> > - NFC_EVT_TRANSACTION_PARAMS_TAG)
>> > + NFC_EVT_TRANSACTION_PARAMS_TAG ||
>> > + skb->len < transaction->aid_len + transaction-
>> > >params_len + 4) {
>>
>> > + devm_kfree(dev, transaction);
>>
>> Oh, no.
>>
>> This is not memory leak per se, this is bad choice of devm_ API where it
>> should use plain kmalloc() / kfree().
>
> Also, there is no check to see if the allocation worked at all.
Ack. I'll add that in v2.
Thanks.
Regards,
Amit Pundir
>
> Mark
> --
Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
On 20 April 2018 at 18:09, Andy Shevchenko
<andriy.shevche...@linux.intel.com> wrote:
> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>
>> if (skb->data[transaction->aid_len + 2] !=
>> - NFC_EVT_TRANSACTION_PARAMS_TAG)
>> + NFC_EVT_TRANSACTION_PARAMS_TAG ||
>> + skb->len < transaction->aid_len + transaction-
>> >params_len + 4) {
>
>> + devm_kfree(dev, transaction);
>
> Oh, no.
>
> This is not memory leak per se, this is bad choice of devm_ API where it
> should use plain kmalloc() / kfree().
>
Hi, If I switch to kmalloc()/kfree() with allocation and may be
pre-usage checks along the way up to nfc_genl_se_transaction() would
that suffice? I believe, I still be needing the additional aid_len and
params_len checks regardless, right?
Regards,
Amit Pundir
>> return -EPROTO;
>> + }
>
> --
> Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Intel Finland Oy
Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
On 20 April 2018 at 18:09, Andy Shevchenko
wrote:
> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>
>> if (skb->data[transaction->aid_len + 2] !=
>> - NFC_EVT_TRANSACTION_PARAMS_TAG)
>> + NFC_EVT_TRANSACTION_PARAMS_TAG ||
>> + skb->len < transaction->aid_len + transaction-
>> >params_len + 4) {
>
>> + devm_kfree(dev, transaction);
>
> Oh, no.
>
> This is not memory leak per se, this is bad choice of devm_ API where it
> should use plain kmalloc() / kfree().
>
Hi, If I switch to kmalloc()/kfree() with allocation and may be
pre-usage checks along the way up to nfc_genl_se_transaction() would
that suffice? I believe, I still be needing the additional aid_len and
params_len checks regardless, right?
Regards,
Amit Pundir
>> return -EPROTO;
>> + }
>
> --
> Andy Shevchenko
> Intel Finland Oy
Re: [RESEND][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
On 23 April 2018 at 14:46, Greg KH <gre...@linuxfoundation.org> wrote:
> On Wed, Apr 18, 2018 at 03:35:04PM +0530, Amit Pundir wrote:
>> From: Suren Baghdasaryan <sur...@google.com>
>>
>> Possible buffer overflow when reading next_read_size bytes into
>> tmp buffer after next_read_size was extracted from a previous packet.
>>
>> Signed-off-by: Suren Baghdasaryan <sur...@google.com>
>> Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
>> ---
>> drivers/nfc/fdp/i2c.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
>> index c4da50e07bbc..08a4f82a2965 100644
>> --- a/drivers/nfc/fdp/i2c.c
>> +++ b/drivers/nfc/fdp/i2c.c
>> @@ -176,6 +176,16 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
>> struct sk_buff **skb)
>> /* Packet that contains a length */
>> if (tmp[0] == 0 && tmp[1] == 0) {
>> phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
>> + /*
>> + * Ensure next_read_size does not exceed sizeof(tmp)
>> + * for reading that many bytes during next iteration
>> + */
>> + if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
>> + dev_dbg(>dev, "%s: corrupted packet\n",
>> + __func__);
>
> As Andy points out, no need for __func__ in any dev_dbg() call.
Hi, Yes i'm working on v2 of this patch and on the comments I got on
another patch in this series.
Thanks,
Amit Pundir
>
> thanks,
>
> greg k-h
Re: [RESEND][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
On 23 April 2018 at 14:46, Greg KH wrote:
> On Wed, Apr 18, 2018 at 03:35:04PM +0530, Amit Pundir wrote:
>> From: Suren Baghdasaryan
>>
>> Possible buffer overflow when reading next_read_size bytes into
>> tmp buffer after next_read_size was extracted from a previous packet.
>>
>> Signed-off-by: Suren Baghdasaryan
>> Signed-off-by: Amit Pundir
>> ---
>> drivers/nfc/fdp/i2c.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
>> index c4da50e07bbc..08a4f82a2965 100644
>> --- a/drivers/nfc/fdp/i2c.c
>> +++ b/drivers/nfc/fdp/i2c.c
>> @@ -176,6 +176,16 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
>> struct sk_buff **skb)
>> /* Packet that contains a length */
>> if (tmp[0] == 0 && tmp[1] == 0) {
>> phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
>> + /*
>> + * Ensure next_read_size does not exceed sizeof(tmp)
>> + * for reading that many bytes during next iteration
>> + */
>> + if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
>> + dev_dbg(>dev, "%s: corrupted packet\n",
>> + __func__);
>
> As Andy points out, no need for __func__ in any dev_dbg() call.
Hi, Yes i'm working on v2 of this patch and on the comments I got on
another patch in this series.
Thanks,
Amit Pundir
>
> thanks,
>
> greg k-h
[RESEND][PATCH 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan <sur...@google.com>
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2917e6..3420c5104c94 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[RESEND][PATCH 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2917e6..3420c5104c94 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
From: Suren Baghdasaryan <sur...@google.com>
Overflow on memcpy is possible in kernel driver for st21nfca's
NFC HCI layer when handling connectivity events if aid_len or
params_len are bigger than the buffer size.
Memory leak is possible when parameter tag is invalid.
Signed-off-by: Suren Baghdasaryan <sur...@google.com>
Signed-off-by: Amit Pundir <amit.pun...@linaro.org>
---
drivers/nfc/st21nfca/se.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 4bed9e842db3..acdce231e227 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -322,23 +322,33 @@ int st21nfca_connectivity_event_received(struct
nfc_hci_dev *hdev, u8 host,
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 &&
+ if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
+ /*
+* Buffer should have enough space for at least
+* two tag fields + two length fields + aid_len (skb->data[1])
+*/
+ if (skb->len < skb->data[1] + 4)
+ return -EPROTO;
+
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
skb->len - 2, GFP_KERNEL);
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, >data[2],
transaction->aid_len);
+ transaction->params_len = skb->data[transaction->aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
+ /* Check next byte is PARAMETERS tag (82) and the length field
*/
if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG)
+ NFC_EVT_TRANSACTION_PARAMS_TAG ||
+ skb->len < transaction->aid_len + transaction->params_len +
4) {
+ devm_kfree(dev, transaction);
return -EPROTO;
+ }
- transaction->params_len = skb->data[transaction->aid_len + 3];
memcpy(transaction->params, skb->data +
transaction->aid_len + 4, transaction->params_len);
--
2.7.4
[RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
From: Suren Baghdasaryan
Overflow on memcpy is possible in kernel driver for st21nfca's
NFC HCI layer when handling connectivity events if aid_len or
params_len are bigger than the buffer size.
Memory leak is possible when parameter tag is invalid.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
drivers/nfc/st21nfca/se.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 4bed9e842db3..acdce231e227 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -322,23 +322,33 @@ int st21nfca_connectivity_event_received(struct
nfc_hci_dev *hdev, u8 host,
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 &&
+ if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
+ /*
+* Buffer should have enough space for at least
+* two tag fields + two length fields + aid_len (skb->data[1])
+*/
+ if (skb->len < skb->data[1] + 4)
+ return -EPROTO;
+
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
skb->len - 2, GFP_KERNEL);
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, >data[2],
transaction->aid_len);
+ transaction->params_len = skb->data[transaction->aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
+ /* Check next byte is PARAMETERS tag (82) and the length field
*/
if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG)
+ NFC_EVT_TRANSACTION_PARAMS_TAG ||
+ skb->len < transaction->aid_len + transaction->params_len +
4) {
+ devm_kfree(dev, transaction);
return -EPROTO;
+ }
- transaction->params_len = skb->data[transaction->aid_len + 3];
memcpy(transaction->params, skb->data +
transaction->aid_len + 4, transaction->params_len);
--
2.7.4
