Describe device tree entry for x1e80100 ufs device
Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 91 ++++++++++++++++++++++++++
1 file changed, 91 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index a9a7bb676c6f..effa776e3dd0 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -2819,6 +2819,97 @@ tsens3: thermal-sensor@c274000 {
#thermal-sensor-cells = <1>;
};
+
+ ufs_mem_hc: ufs@1d84000 {
+ compatible = "qcom,x1e80100-ufshc",
+ "qcom,ufshc", "jedec,ufs-2.0";
+ reg = <0 0x01d84000 0 0x3000>;
+
+
+ interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
+
+ phys = <&ufs_mem_phy>;
+ phy-names = "ufsphy";
+
+ lanes-per-direction = <2>;
+
+ #reset-cells = <1>;
+ resets = <&gcc GCC_UFS_PHY_BCR>;
+
+ reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
+ reset-names = "rst";
+
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
+
+ iommus = <&apps_smmu 0x1a0 0x0>;
+
+ clock-names = "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "rx_lane1_sync_clk";
+
+ clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>,
+ <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+
+ freq-table-hz = <100000000 403000000>,
+ <0 0>,
+ <0 0>,
+ <100000000 403000000>,
+ <100000000 403000000>,
+ <0 0>,
+ <0 0>,
+ <0 0>;
+
+ interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
+ &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ufs-ddr", "cpu-ufs";
+
+ qcom,ice = <&ice>;
+
+ status = "disabled";
+ };
+
+ ufs_mem_phy: phy@1d80000 {
+ compatible = "qcom,x1e80100-qmp-ufs-phy";
+ reg = <0 0x01d80000 0 0x2000>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
+
+ clock-names = "ref",
+ "ref_aux",
+ "qref";
+
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
+
+ resets = <&ufs_mem_hc 0>;
+ reset-names = "ufsphy";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ ice: crypto@1d90000 {
+ compatible = "qcom,x1e80100-inline-crypto-engine",
+ "qcom,inline-crypto-engine";
+ reg = <0 0x1d88000 0 0x8000>;
+
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ };
+
usb_1_ss0_hsphy: phy@fd3000 {
compatible = "qcom,x1e80100-snps-eusb2-phy",
"qcom,sm8550-snps-eusb2-phy";
--
2.48.1
On 8/14/2025 6:29 AM, Harrison Vanderbyl wrote:
> Describe device tree entry for x1e80100 ufs device
> Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 91 ++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> index a9a7bb676c6f..effa776e3dd0 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> @@ -2819,6 +2819,97 @@ tsens3: thermal-sensor@c274000 {
> #thermal-sensor-cells = <1>;
> };
>
> +
> + ufs_mem_hc: ufs@1d84000 {
> + compatible = "qcom,x1e80100-ufshc",
> + "qcom,ufshc", "jedec,ufs-2.0";
> + reg = <0 0x01d84000 0 0x3000>;
> +
> +
> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> +
> + phys = <&ufs_mem_phy>;
> + phy-names = "ufsphy";
> +
> + lanes-per-direction = <2>;
> +
> + #reset-cells = <1>;
> + resets = <&gcc GCC_UFS_PHY_BCR>;
> +
> + reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
> + reset-names = "rst";
> +
> + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> +
> + iommus = <&apps_smmu 0x1a0 0x0>;
> +
> + clock-names = "core_clk",
> + "bus_aggr_clk",
> + "iface_clk",
> + "core_clk_unipro",
> + "ref_clk",
> + "tx_lane0_sync_clk",
> + "rx_lane0_sync_clk",
> + "rx_lane1_sync_clk";
> +
> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_UFS_PHY_AHB_CLK>,
> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> + <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> +
> + freq-table-hz = <100000000 403000000>,
> + <0 0>,
> + <0 0>,
> + <100000000 403000000>,
> + <100000000 403000000>,
> + <0 0>,
> + <0 0>,
> + <0 0>;
> +
Please use OPP table instead of freq-table-hz.
> + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
> + &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ALWAYS>;
For Config Path, use QCOM_ICC_TAG_ACTIVE_ONLY.
YOu can refer to ICC discussion link for SM8750 -
https://lore.kernel.org/linux-devicetree/354f8710-a5ec-47b5-bcfa-bff75ac3ca71@oss.qualcomm.com/
> + interconnect-names = "ufs-ddr", "cpu-ufs";
> +
> + qcom,ice = <&ice>;
> +
> + status = "disabled";
> + };
> +
> + ufs_mem_phy: phy@1d80000 {
> + compatible = "qcom,x1e80100-qmp-ufs-phy";
> + reg = <0 0x01d80000 0 0x2000>;
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
> +
> + clock-names = "ref",
> + "ref_aux",
> + "qref";
> +
> + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> +
> + resets = <&ufs_mem_hc 0>;
> + reset-names = "ufsphy";
> +
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> + ice: crypto@1d90000 {
> + compatible = "qcom,x1e80100-inline-crypto-engine",
> + "qcom,inline-crypto-engine";
> + reg = <0 0x1d88000 0 0x8000>;
> +
> + clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
> + };
> +
> usb_1_ss0_hsphy: phy@fd3000 {
> compatible = "qcom,x1e80100-snps-eusb2-phy",
> "qcom,sm8550-snps-eusb2-phy";
On Thu, Aug 14, 2025 at 12:50:17PM GMT, Nitin Rawat wrote:
>
>
> On 8/14/2025 6:29 AM, Harrison Vanderbyl wrote:
> > Describe device tree entry for x1e80100 ufs device
> > Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
> > ---
> > arch/arm64/boot/dts/qcom/x1e80100.dtsi | 91 ++++++++++++++++++++++++++
> > 1 file changed, 91 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> > index a9a7bb676c6f..effa776e3dd0 100644
> > --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> > @@ -2819,6 +2819,97 @@ tsens3: thermal-sensor@c274000 {
> > #thermal-sensor-cells = <1>;
> > };
> > +
> > + ufs_mem_hc: ufs@1d84000 {
> > + compatible = "qcom,x1e80100-ufshc",
> > + "qcom,ufshc", "jedec,ufs-2.0";
This controller is UFS 3.0 based. Also, JEDEC has two specs for UFS:
1. UFSHCI (Host controllers found in SoCs)
2. UFS (UFS devices)
And this compatible 'jedec,ufs-2.0' is mostly for UFS devices, not Host
controllers. So using we should be using 'jedec,ufshc-3.0' here and in other
bindings.
krzk: Is it OK to change the compatible for all bindings and dts? Atleast linux
is not making use of this compatible, but I'm not sure about other DT users.
> > + reg = <0 0x01d84000 0 0x3000>;
> > +
> > +
> > + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + phys = <&ufs_mem_phy>;
> > + phy-names = "ufsphy";
> > +
> > + lanes-per-direction = <2>;
> > +
> > + #reset-cells = <1>;
> > + resets = <&gcc GCC_UFS_PHY_BCR>;
> > +
> > + reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
> > + reset-names = "rst";
> > +
> > + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> > +
> > + iommus = <&apps_smmu 0x1a0 0x0>;
> > +
> > + clock-names = "core_clk",
> > + "bus_aggr_clk",
> > + "iface_clk",
> > + "core_clk_unipro",
> > + "ref_clk",
> > + "tx_lane0_sync_clk",
> > + "rx_lane0_sync_clk",
> > + "rx_lane1_sync_clk";
> > +
> > + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> > + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> > + <&gcc GCC_UFS_PHY_AHB_CLK>,
> > + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> > + <&rpmhcc RPMH_CXO_CLK>,
> > + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> > + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> > + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> > +
> > + freq-table-hz = <100000000 403000000>,
> > + <0 0>,
> > + <0 0>,
> > + <100000000 403000000>,
> > + <100000000 403000000>,
> > + <0 0>,
> > + <0 0>,
> > + <0 0>;
> > +
> Please use OPP table instead of freq-table-hz.
>
>
> > + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
> > + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> > + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
> > + &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ALWAYS>;
>
> For Config Path, use QCOM_ICC_TAG_ACTIVE_ONLY.
>
> YOu can refer to ICC discussion link for SM8750 - https://lore.kernel.org/linux-devicetree/354f8710-a5ec-47b5-bcfa-bff75ac3ca71@oss.qualcomm.com/
>
Nitin, question for you: Is this controller cache coherent as like its ancerstor
sm8550?
- Mani
--
மணிவண்ணன் சதாசிவம்
On Thu, Aug 14, 2025 at 10:59:04AM +1000, Harrison Vanderbyl wrote:
Welcome to LKML, Harrison. Some small things to improve.
Please extend the subject prefix to match other changes in the files of
each patch, e.g. this one would be "arm64: dts: qcom: x1e80100: ".
"git log --oneline -- file" is your friend here.
> Describe device tree entry for x1e80100 ufs device
A blank line here please.
> Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 91 ++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> index a9a7bb676c6f..effa776e3dd0 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> @@ -2819,6 +2819,97 @@ tsens3: thermal-sensor@c274000 {
> #thermal-sensor-cells = <1>;
> };
>
> +
Watch out for unnecessary white spaces, we want to keep things neat and
tidy.
> + ufs_mem_hc: ufs@1d84000 {
Please place nodes sorted based on address, then name, then label (i.e.
in this case, only address).
> + compatible = "qcom,x1e80100-ufshc",
> + "qcom,ufshc", "jedec,ufs-2.0";
This line break is a bit weird, please indent it.
Regards,
Bjorn
> + reg = <0 0x01d84000 0 0x3000>;
> +
> +
> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> +
> + phys = <&ufs_mem_phy>;
> + phy-names = "ufsphy";
> +
> + lanes-per-direction = <2>;
> +
> + #reset-cells = <1>;
> + resets = <&gcc GCC_UFS_PHY_BCR>;
> +
> + reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
> + reset-names = "rst";
> +
> + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> +
> + iommus = <&apps_smmu 0x1a0 0x0>;
> +
> + clock-names = "core_clk",
> + "bus_aggr_clk",
> + "iface_clk",
> + "core_clk_unipro",
> + "ref_clk",
> + "tx_lane0_sync_clk",
> + "rx_lane0_sync_clk",
> + "rx_lane1_sync_clk";
> +
> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_UFS_PHY_AHB_CLK>,
> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> + <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> +
> + freq-table-hz = <100000000 403000000>,
> + <0 0>,
> + <0 0>,
> + <100000000 403000000>,
> + <100000000 403000000>,
> + <0 0>,
> + <0 0>,
> + <0 0>;
> +
> + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
> + &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ALWAYS>;
> + interconnect-names = "ufs-ddr", "cpu-ufs";
> +
> + qcom,ice = <&ice>;
> +
> + status = "disabled";
> + };
> +
> + ufs_mem_phy: phy@1d80000 {
> + compatible = "qcom,x1e80100-qmp-ufs-phy";
> + reg = <0 0x01d80000 0 0x2000>;
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
> +
> + clock-names = "ref",
> + "ref_aux",
> + "qref";
> +
> + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> +
> + resets = <&ufs_mem_hc 0>;
> + reset-names = "ufsphy";
> +
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> + ice: crypto@1d90000 {
> + compatible = "qcom,x1e80100-inline-crypto-engine",
> + "qcom,inline-crypto-engine";
> + reg = <0 0x1d88000 0 0x8000>;
> +
> + clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
> + };
> +
> usb_1_ss0_hsphy: phy@fd3000 {
> compatible = "qcom,x1e80100-snps-eusb2-phy",
> "qcom,sm8550-snps-eusb2-phy";
> --
> 2.48.1
>
On 14/08/2025 04:42, Bjorn Andersson wrote: > On Thu, Aug 14, 2025 at 10:59:04AM +1000, Harrison Vanderbyl wrote: > > Welcome to LKML, Harrison. Some small things to improve. > > Please extend the subject prefix to match other changes in the files of > each patch, e.g. this one would be "arm64: dts: qcom: x1e80100: ". > > "git log --oneline -- file" is your friend here. > >> Describe device tree entry for x1e80100 ufs device This is duplicating earlier patches: https://lore.kernel.org/all/szudb2teaacchrp4kn4swkqkoplgi5lbw7vbqtu5vhds4qat62@2tciswvelbmu/ Best regards, Krzysztof
On 8/14/25 8:59 AM, Krzysztof Kozlowski wrote: > On 14/08/2025 04:42, Bjorn Andersson wrote: >> On Thu, Aug 14, 2025 at 10:59:04AM +1000, Harrison Vanderbyl wrote: >> >> Welcome to LKML, Harrison. Some small things to improve. >> >> Please extend the subject prefix to match other changes in the files of >> each patch, e.g. this one would be "arm64: dts: qcom: x1e80100: ". >> >> "git log --oneline -- file" is your friend here. >> >>> Describe device tree entry for x1e80100 ufs device > > This is duplicating earlier patches: > https://lore.kernel.org/all/szudb2teaacchrp4kn4swkqkoplgi5lbw7vbqtu5vhds4qat62@2tciswvelbmu/ (that submitter clearly expressed lack of interest in proceeding) Konrad
On 14/08/2025 11:46, Konrad Dybcio wrote: > On 8/14/25 8:59 AM, Krzysztof Kozlowski wrote: >> On 14/08/2025 04:42, Bjorn Andersson wrote: >>> On Thu, Aug 14, 2025 at 10:59:04AM +1000, Harrison Vanderbyl wrote: >>> >>> Welcome to LKML, Harrison. Some small things to improve. >>> >>> Please extend the subject prefix to match other changes in the files of >>> each patch, e.g. this one would be "arm64: dts: qcom: x1e80100: ". >>> >>> "git log --oneline -- file" is your friend here. >>> >>>> Describe device tree entry for x1e80100 ufs device >> >> This is duplicating earlier patches: >> https://lore.kernel.org/all/szudb2teaacchrp4kn4swkqkoplgi5lbw7vbqtu5vhds4qat62@2tciswvelbmu/ > > (that submitter clearly expressed lack of interest in proceeding) > Sure, would be good though to reflect that - provide summary of previous discussions, changelogs or at least give links. Best regards, Krzysztof
On Thu, Aug 14, 2025 at 01:18:46PM +0200, Krzysztof Kozlowski wrote: > On 14/08/2025 11:46, Konrad Dybcio wrote: > > On 8/14/25 8:59 AM, Krzysztof Kozlowski wrote: > >> On 14/08/2025 04:42, Bjorn Andersson wrote: > >>> On Thu, Aug 14, 2025 at 10:59:04AM +1000, Harrison Vanderbyl wrote: > >>> > >>> Welcome to LKML, Harrison. Some small things to improve. > >>> > >>> Please extend the subject prefix to match other changes in the files of > >>> each patch, e.g. this one would be "arm64: dts: qcom: x1e80100: ". > >>> > >>> "git log --oneline -- file" is your friend here. > >>> > >>>> Describe device tree entry for x1e80100 ufs device > >> > >> This is duplicating earlier patches: > >> https://lore.kernel.org/all/szudb2teaacchrp4kn4swkqkoplgi5lbw7vbqtu5vhds4qat62@2tciswvelbmu/ > > > > (that submitter clearly expressed lack of interest in proceeding) > > > > Sure, would be good though to reflect that - provide summary of previous > discussions, changelogs or at least give links. ... Also keep authorship and SoB chain. -- With best wishes Dmitry
On Thu, Aug 14, 2025 at 02:26:07PM +0300, Dmitry Baryshkov wrote: > On Thu, Aug 14, 2025 at 01:18:46PM +0200, Krzysztof Kozlowski wrote: > > On 14/08/2025 11:46, Konrad Dybcio wrote: > > > On 8/14/25 8:59 AM, Krzysztof Kozlowski wrote: > > >> On 14/08/2025 04:42, Bjorn Andersson wrote: > > >>> On Thu, Aug 14, 2025 at 10:59:04AM +1000, Harrison Vanderbyl wrote: > > >>> > > >>> Welcome to LKML, Harrison. Some small things to improve. > > >>> > > >>> Please extend the subject prefix to match other changes in the files of > > >>> each patch, e.g. this one would be "arm64: dts: qcom: x1e80100: ". > > >>> > > >>> "git log --oneline -- file" is your friend here. > > >>> > > >>>> Describe device tree entry for x1e80100 ufs device > > >> > > >> This is duplicating earlier patches: > > >> https://lore.kernel.org/all/szudb2teaacchrp4kn4swkqkoplgi5lbw7vbqtu5vhds4qat62@2tciswvelbmu/ > > > > > > (that submitter clearly expressed lack of interest in proceeding) > > > > > > > Sure, would be good though to reflect that - provide summary of previous > > discussions, changelogs or at least give links. > > ... Also keep authorship and SoB chain. > If it's based on those patches yes, otherwise no. Regards, Bjorn > -- > With best wishes > Dmitry
© 2016 - 2026 Red Hat, Inc.