arch/arm64/boot/dts/qcom/sm8550.dtsi | 40 ++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)
Add the SDC4 SDHCI controller node for the SM8550 SoC.
SMMU stream ID 0x80 was sourced from the UEFI bootloader IORT tables,
as SDCC stream IDs are not documented in the register reference manual.
Unlike SDC2, the data path is routed via aggre1_noc, matching
MASTER_SDCC_4 in drivers/interconnect/qcom/sm8550.c.
The SDHCI capabilities register on this SoC advertises SDR104
and SDR50 but these UHS-I modes are broken on SDHC4.
Mask them via sdhci-caps-mask, this keeps the bus in HS mode,
which initialises reliably.
Tested on the IMDT QCS8550 SBC. This board is not currently
supported in-tree.
Co-developed-by: Tendai Makumire <tendai.makumire@imd-tec.com>
Signed-off-by: Tendai Makumire <tendai.makumire@imd-tec.com>
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
Changes in v2:
- Drop qcom,dll-config and qcom,ddr-config; these properties are not
valid for this SDC instance (Konrad Dybcio)
- Reduce the OPP table to a single 75 MHz / low_svs entry matching the
SDCC4 operating point on this SoC (Konrad Dybcio)
- Forbid SDR104/SDR50 via sdhci-caps-mask, matching the previously
existing sdhc_2 workaround in the same file.
The SDHCI capabilities register on this SoC advertises SDR50/SDR104
modes that are broken on sdhc_4; without masking them the MMC
core selects SDR50 and fails DLL tuning with
-ETIMEDOUT during SDIO card initialisation.
- Rework the commit message to reflect the above understanding and
drop the "root cause not yet determined" note
- Drop self Tested-by tag (Konrad Dybcio)
- Link to v1: https://patch.msgid.link/20260423-sm8550-sdhc4-support-v1-1-93fd81fea5d9@imd-tec.com
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 40 ++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 912525e9bca6..07161a873b2d 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3280,6 +3280,46 @@ opp-202000000 {
};
};
+ sdhc_4: mmc@8844000 {
+ compatible = "qcom,sm8550-sdhci", "qcom,sdhci-msm-v5";
+ reg = <0 0x08844000 0 0x1000>;
+
+ interrupts = <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+
+ clocks = <&gcc GCC_SDCC4_AHB_CLK>,
+ <&gcc GCC_SDCC4_APPS_CLK>,
+ <&bi_tcxo_div2>;
+ clock-names = "iface", "core", "xo";
+ iommus = <&apps_smmu 0x80 0>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+ operating-points-v2 = <&sdhc4_opp_table>;
+
+ interconnects = <&aggre1_noc MASTER_SDCC_4 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_SDCC_4 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "sdhc-ddr", "cpu-sdhc";
+ bus-width = <4>;
+ max-sd-hs-hz = <37500000>;
+ dma-coherent;
+
+ /* Forbid SDR104/SDR50 broken hw! */
+ sdhci-caps-mask = <0x3 0>;
+
+ status = "disabled";
+
+ sdhc4_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-75000000 {
+ opp-hz = /bits/ 64 <75000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+ };
+ };
+
iris: video-codec@aa00000 {
compatible = "qcom,sm8550-iris";
---
base-commit: 4f5b4b748ac75683d61c304ee3ee0db235e8f312
change-id: 20260423-sm8550-sdhc4-support-358bf264c04e
Best regards,
--
William Bright <william.bright@imd-tec.com>On 4/27/26 14:24, William Bright wrote:
> Add the SDC4 SDHCI controller node for the SM8550 SoC.
>
> SMMU stream ID 0x80 was sourced from the UEFI bootloader IORT tables,
> as SDCC stream IDs are not documented in the register reference manual.
> Unlike SDC2, the data path is routed via aggre1_noc, matching
> MASTER_SDCC_4 in drivers/interconnect/qcom/sm8550.c.
>
> The SDHCI capabilities register on this SoC advertises SDR104
> and SDR50 but these UHS-I modes are broken on SDHC4.
How do you know that these modes are broken in hardware and not
caused by something else?
It was stated before, but it was proven to be invalid as the statement.
> Mask them via sdhci-caps-mask, this keeps the bus in HS mode,
> which initialises reliably.
>
> Tested on the IMDT QCS8550 SBC. This board is not currently
> supported in-tree.
>
> Co-developed-by: Tendai Makumire <tendai.makumire@imd-tec.com>
> Signed-off-by: Tendai Makumire <tendai.makumire@imd-tec.com>
> Signed-off-by: William Bright <william.bright@imd-tec.com>
> ---
> Changes in v2:
> - Drop qcom,dll-config and qcom,ddr-config; these properties are not
> valid for this SDC instance (Konrad Dybcio)
> - Reduce the OPP table to a single 75 MHz / low_svs entry matching the
> SDCC4 operating point on this SoC (Konrad Dybcio)
> - Forbid SDR104/SDR50 via sdhci-caps-mask, matching the previously
> existing sdhc_2 workaround in the same file.
> The SDHCI capabilities register on this SoC advertises SDR50/SDR104
> modes that are broken on sdhc_4; without masking them the MMC
> core selects SDR50 and fails DLL tuning with
> -ETIMEDOUT during SDIO card initialisation.
Which one SDIO card do you test?
> - Rework the commit message to reflect the above understanding and
> drop the "root cause not yet determined" note
> - Drop self Tested-by tag (Konrad Dybcio)
> - Link to v1: https://patch.msgid.link/20260423-sm8550-sdhc4-support-v1-1-93fd81fea5d9@imd-tec.com
>
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konradybcio@kernel.org>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 40 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 912525e9bca6..07161a873b2d 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -3280,6 +3280,46 @@ opp-202000000 {
> };
> };
>
> + sdhc_4: mmc@8844000 {
> + compatible = "qcom,sm8550-sdhci", "qcom,sdhci-msm-v5";
> + reg = <0 0x08844000 0 0x1000>;
> +
> + interrupts = <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "hc_irq", "pwr_irq";
> +
> + clocks = <&gcc GCC_SDCC4_AHB_CLK>,
> + <&gcc GCC_SDCC4_APPS_CLK>,
> + <&bi_tcxo_div2>;
> + clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x80 0>;
> + power-domains = <&rpmhpd RPMHPD_CX>;
> + operating-points-v2 = <&sdhc4_opp_table>;
> +
> + interconnects = <&aggre1_noc MASTER_SDCC_4 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc SLAVE_SDCC_4 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "sdhc-ddr", "cpu-sdhc";
> + bus-width = <4>;
> + max-sd-hs-hz = <37500000>;
> + dma-coherent;
> +
> + /* Forbid SDR104/SDR50 broken hw! */
This is copied from somewhere else, while virtually it's unconfirmed,
if this SD host controller is broken or not...
> + sdhci-caps-mask = <0x3 0>;
> +
> + status = "disabled";
> +
> + sdhc4_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-75000000 {
> + opp-hz = /bits/ 64 <75000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> + };
> + };
> +
> iris: video-codec@aa00000 {
> compatible = "qcom,sm8550-iris";
>
--
Best wishes,
Vladimir
On Thu, Jun 04, 2026 at 07:01:22PM +0300, Vladimir Zapolskiy wrote: > > How do you know that these modes are broken in hardware and not > caused by something else? > > It was stated before, but it was proven to be invalid as the statement. > Thanks Vladimir for your feedback. I copied this statement from when these modes were also masked out on sdhc_2. I see that there was progress since then and the caps mask has been dropped so I agree that I shouldn't have this comment that these modes are broken due to hardware. I have tested this patch after rebasing onto the latest tree with the recent changes that allowed for the caps mask to be dropped for sdhc_2 and I still see dll tuning failing. To progress, I need some guidance from qcom as to what dll-config value should be used as I am uncertain about this. I noticed that ftbl_gcc_sdcc4_apps_clk_src only goes up to 75MHz so perhaps this needs modifying for DLL-tuning to pass and maybe there needs to be schematic/routing guidance that needs to be strictly followed as-well besides the usual 50 ohm impedance rules? > > - Forbid SDR104/SDR50 via sdhci-caps-mask, matching the previously > > existing sdhc_2 workaround in the same file. > > The SDHCI capabilities register on this SoC advertises SDR50/SDR104 > > modes that are broken on sdhc_4; without masking them the MMC > > core selects SDR50 and fails DLL tuning with > > -ETIMEDOUT during SDIO card initialisation. > > Which one SDIO card do you test? > My apologies, I made a mistake in the cover letter, I wasn't testing with an SDIO card, I was testing with an NXP IW416 which is hard-wired to sdhc_4. Best regards, Will
On 6/9/26 19:21, William Bright wrote:
> On Thu, Jun 04, 2026 at 07:01:22PM +0300, Vladimir Zapolskiy wrote:
>>
>> How do you know that these modes are broken in hardware and not
>> caused by something else?
>>
>> It was stated before, but it was proven to be invalid as the statement.
>>
> Thanks Vladimir for your feedback.
>
> I copied this statement from when these modes were also masked out on
> sdhc_2. I see that there was progress since then and the caps mask has
> been dropped so I agree that I shouldn't have this comment that these
> modes are broken due to hardware.
Well, it might be broken due to hardware, but not necessarily due to
Qualcomm SoC IP, there is a chance of a PCB design flaw.
>
> I have tested this patch after rebasing onto the latest tree with the
> recent changes that allowed for the caps mask to be dropped for sdhc_2
> and I still see dll tuning failing. To progress, I need some guidance
> from qcom as to what dll-config value should be used as I am uncertain
> about this. I noticed that ftbl_gcc_sdcc4_apps_clk_src only goes up to
> 75MHz so perhaps this needs modifying for DLL-tuning to pass and maybe
> there needs to be schematic/routing guidance that needs to be strictly
> followed as-well besides the usual 50 ohm impedance rules?
>>> - Forbid SDR104/SDR50 via sdhci-caps-mask, matching the previously
>>> existing sdhc_2 workaround in the same file.
>>> The SDHCI capabilities register on this SoC advertises SDR50/SDR104
>>> modes that are broken on sdhc_4; without masking them the MMC
>>> core selects SDR50 and fails DLL tuning with
>>> -ETIMEDOUT during SDIO card initialisation.
>>
>> Which one SDIO card do you test?
>>
> My apologies, I made a mistake in the cover letter, I wasn't testing with
> an SDIO card, I was testing with an NXP IW416 which is hard-wired to
> sdhc_4.
FWIW due to https://www.nxp.com/docs/en/data-sheet/IW416.pdf "10.7.1 VIO_SD
DC characteristics" SDR104 speed mode is not supported by the module, thus
the selection of the SDR50 speed mode on the host side sounds to be correct
in your case.
In SDR50 speed mode gcc_sdcc4_apps_clk clock frequency should be exactly
100MHz, and since it differs, it has an impact during the tuning phase.
Definitely clk/qcom/gcc-sm8550.c says that the maximum supported frequency
is 75MHz, the same is found in the downstream v5.15 kernel:
static const struct freq_tbl ftbl_gcc_sdcc4_apps_clk_src[] = {
F(400000, P_BI_TCXO, 12, 1, 4),
F(25000000, P_GCC_GPLL0_OUT_EVEN, 12, 0, 0),
F(37500000, P_GCC_GPLL0_OUT_EVEN, 8, 0, 0),
F(75000000, P_GCC_GPLL0_OUT_EVEN, 4, 0, 0),
{ }
};
Can you dump CAPS1 register value of SM8550 SDHC4? What does it say about
SDR50 mode support and need for SDR50 mode tuning?
--
Best wishes,
Vladimir
On Wed, Jun 10, 2026 at 11:21:53AM +0300, Vladimir Zapolskiy wrote:
> FWIW due to https://www.nxp.com/docs/en/data-sheet/IW416.pdf "10.7.1 VIO_SD
> DC characteristics" SDR104 speed mode is not supported by the module, thus
> the selection of the SDR50 speed mode on the host side sounds to be correct
> in your case.
>
> In SDR50 speed mode gcc_sdcc4_apps_clk clock frequency should be exactly
> 100MHz, and since it differs, it has an impact during the tuning phase.
>
> Definitely clk/qcom/gcc-sm8550.c says that the maximum supported frequency
> is 75MHz, the same is found in the downstream v5.15 kernel:
>
> static const struct freq_tbl ftbl_gcc_sdcc4_apps_clk_src[] = {
> F(400000, P_BI_TCXO, 12, 1, 4),
> F(25000000, P_GCC_GPLL0_OUT_EVEN, 12, 0, 0),
> F(37500000, P_GCC_GPLL0_OUT_EVEN, 8, 0, 0),
> F(75000000, P_GCC_GPLL0_OUT_EVEN, 4, 0, 0),
> { }
> };
>
> Can you dump CAPS1 register value of SM8550 SDHC4? What does it say about
> SDR50 mode support and need for SDR50 mode tuning?
>
> --
> Best wishes,
> Vladimir
CAPS0 and CAPS1 are below:
sdhci_msm 8844000.mmc: CAPS0: 0x3029c8b2 CAPS1: 0x0000a08b
For CAPS1:
Bit 0 (SDR50 support) = 1
Bit 13 (Use Tuning for SDR50) = 1
It looks to report that SDR50 is supported with tuning required.
Best regards,
Will
On 6/10/26 12:59, William Bright wrote:
> On Wed, Jun 10, 2026 at 11:21:53AM +0300, Vladimir Zapolskiy wrote:
>> FWIW due to https://www.nxp.com/docs/en/data-sheet/IW416.pdf "10.7.1 VIO_SD
>> DC characteristics" SDR104 speed mode is not supported by the module, thus
>> the selection of the SDR50 speed mode on the host side sounds to be correct
>> in your case.
>>
>> In SDR50 speed mode gcc_sdcc4_apps_clk clock frequency should be exactly
>> 100MHz, and since it differs, it has an impact during the tuning phase.
>>
>> Definitely clk/qcom/gcc-sm8550.c says that the maximum supported frequency
>> is 75MHz, the same is found in the downstream v5.15 kernel:
>>
>> static const struct freq_tbl ftbl_gcc_sdcc4_apps_clk_src[] = {
>> F(400000, P_BI_TCXO, 12, 1, 4),
>> F(25000000, P_GCC_GPLL0_OUT_EVEN, 12, 0, 0),
>> F(37500000, P_GCC_GPLL0_OUT_EVEN, 8, 0, 0),
>> F(75000000, P_GCC_GPLL0_OUT_EVEN, 4, 0, 0),
>> { }
>> };
>>
>> Can you dump CAPS1 register value of SM8550 SDHC4? What does it say about
>> SDR50 mode support and need for SDR50 mode tuning?
>>
>> --
>> Best wishes,
>> Vladimir
> CAPS0 and CAPS1 are below:
> sdhci_msm 8844000.mmc: CAPS0: 0x3029c8b2 CAPS1: 0x0000a08b
> For CAPS1:
> Bit 0 (SDR50 support) = 1
> Bit 13 (Use Tuning for SDR50) = 1
> It looks to report that SDR50 is supported with tuning required.
>
Looks like the SDHC driver behaves expectedly then. For me it's hard to say
what may be the rootcause, I believe the lower bus frequency should be fine,
so it sounds like a hardware issue, but could it be PCB/board specific one?
If you find a chance to copy the SDHC driver (and its small dependencies)
from Android and test it on your board, and if it also fails, then it might
be well concluded that something is wrong with hardware, still it won't be
quite convincing that the SoC SDHC is to blame here.
Hope it helps.
--
Best wishes,
Vladimir
On Thu, Jun 11, 2026 at 10:48:34AM +0300, Vladimir Zapolskiy wrote:
> Looks like the SDHC driver behaves expectedly then. For me it's hard to say
> what may be the rootcause, I believe the lower bus frequency should be fine,
> so it sounds like a hardware issue, but could it be PCB/board specific one?
>
> If you find a chance to copy the SDHC driver (and its small dependencies)
> from Android and test it on your board, and if it also fails, then it might
> be well concluded that something is wrong with hardware, still it won't be
> quite convincing that the SoC SDHC is to blame here.
>
> Hope it helps.
>
> --
> Best wishes,
> Vladimir
My colleague Tendai (<tendai.makumire@imd-tec.com>) had the same issue
with dll-tuning failing in SDR50 when working on the downstream 5.15 msm
kernel [1].
It does sound like a potential SI issue so I will try the following:
- Sweeping the drive-strength values for the sdhc_4 lines to see if I
can find a set of values that work
- Scoping the lines to check SI when performing dll-tuning, our board
is very dense so this is challenging.
I am guessing this patch is only acceptable to be upstreamed once we get
to the bottom of why dll-tuning is failing?
[1] https://github.com/imd-tec/meta-imdt-qcom/tree/kirkstone/patches/msm-kernel/files
Many thanks,
Will
On 6/12/26 11:47, William Bright wrote: > On Thu, Jun 11, 2026 at 10:48:34AM +0300, Vladimir Zapolskiy wrote: >> Looks like the SDHC driver behaves expectedly then. For me it's hard to say >> what may be the rootcause, I believe the lower bus frequency should be fine, >> so it sounds like a hardware issue, but could it be PCB/board specific one? >> >> If you find a chance to copy the SDHC driver (and its small dependencies) >> from Android and test it on your board, and if it also fails, then it might >> be well concluded that something is wrong with hardware, still it won't be >> quite convincing that the SoC SDHC is to blame here. >> >> Hope it helps. >> > My colleague Tendai (<tendai.makumire@imd-tec.com>) had the same issue > with dll-tuning failing in SDR50 when working on the downstream 5.15 msm > kernel [1]. If Qualcomm supports their downstream Android kernel running on your board, it should be worth to contact them. > It does sound like a potential SI issue so I will try the following: > - Sweeping the drive-strength values for the sdhc_4 lines to see if I > can find a set of values that work > - Scoping the lines to check SI when performing dll-tuning, our board > is very dense so this is challenging. > I am guessing this patch is only acceptable to be upstreamed once we get > to the bottom of why dll-tuning is failing? Apparently if Qualcomm confirms that SM8550 SDHC4 actually has this discovered and unveiled defect, then this change will be accepted for all SM8550 platform like you propose it to be done. According to my experince SM8550 SDHC2 operates properly in UHS-I SDR50/SDR104 speed modes, this can be verified on the reference boards like HDK or QRD, and for me it sounds oddly that there is such a problem with SDHC4. If the proposed change as is does not enter upstream for SM8550 SoC, you may keep it as a necessary change in your particular board .dts file. > [1] https://github.com/imd-tec/meta-imdt-qcom/tree/kirkstone/patches/msm-kernel/files > -- Best wishes, Vladimir
On Fri, Jun 12, 2026 at 10:11 AM, Vladimir Zapolskiy wrote: > If Qualcomm supports their downstream Android kernel running on your > board, it should be worth to contact them. Hi Vladimir, I had previously opened a case with Qualcomm when I started trying to get SDHC4 working on our board and we didn't get very far with them. I did almost all the work here without their support. What's interesting to me is that we managed to get SDHC2 working at UHS-I SDR104 speeds quite early on. And the traces for SDHC4 on our board are actually shorter than what we have for SDHC2. The only difference between the two controllers on our board is that we don't have a level shifter on SDHC4 and the pins are connected directly to the IW416 without any pullups or pulldowns. The signals looked clean last time I measured them. Tendai On Fri, Jun 12, 2026 at 10:11 AM Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> wrote: > > On 6/12/26 11:47, William Bright wrote: > > On Thu, Jun 11, 2026 at 10:48:34AM +0300, Vladimir Zapolskiy wrote: > >> Looks like the SDHC driver behaves expectedly then. For me it's hard to say > >> what may be the rootcause, I believe the lower bus frequency should be fine, > >> so it sounds like a hardware issue, but could it be PCB/board specific one? > >> > >> If you find a chance to copy the SDHC driver (and its small dependencies) > >> from Android and test it on your board, and if it also fails, then it might > >> be well concluded that something is wrong with hardware, still it won't be > >> quite convincing that the SoC SDHC is to blame here. > >> > >> Hope it helps. > >> > > My colleague Tendai (<tendai.makumire@imd-tec.com>) had the same issue > > with dll-tuning failing in SDR50 when working on the downstream 5.15 msm > > kernel [1]. > > If Qualcomm supports their downstream Android kernel running on your > board, it should be worth to contact them. > > > It does sound like a potential SI issue so I will try the following: > > - Sweeping the drive-strength values for the sdhc_4 lines to see if I > > can find a set of values that work > > - Scoping the lines to check SI when performing dll-tuning, our board > > is very dense so this is challenging. > > I am guessing this patch is only acceptable to be upstreamed once we get > > to the bottom of why dll-tuning is failing? > > Apparently if Qualcomm confirms that SM8550 SDHC4 actually has this > discovered and unveiled defect, then this change will be accepted for > all SM8550 platform like you propose it to be done. > > According to my experince SM8550 SDHC2 operates properly in UHS-I > SDR50/SDR104 speed modes, this can be verified on the reference boards > like HDK or QRD, and for me it sounds oddly that there is such a problem > with SDHC4. > > If the proposed change as is does not enter upstream for SM8550 SoC, you > may keep it as a necessary change in your particular board .dts file. > > > [1] https://github.com/imd-tec/meta-imdt-qcom/tree/kirkstone/patches/msm-kernel/files > > > > -- > Best wishes, > Vladimir
© 2016 - 2026 Red Hat, Inc.