User:Knuxify/Draft:Qualcomm/Adding a new SoC to mainline Linux - Revision history

Knuxify at 19:41, 6 June 2026

2026-06-06T19:41:36Z

← Older revision		Revision as of 19:41, 6 June 2026
Line 81:		Line 81:
	Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>; also copy the dt-bindings from <code>include/dt-bindings/clock/qcom,gcc-CODENAME.h</code> to <code>include/dt-bindings/clock/qcom,CODENAME-gcc.h</code> in mainline.		Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>; also copy the dt-bindings from <code>include/dt-bindings/clock/qcom,gcc-CODENAME.h</code> to <code>include/dt-bindings/clock/qcom,CODENAME-gcc.h</code> in mainline.

	==== Simple changes ====		=== Simple changes ===

	* <code><linux/platform_device.h></code> needs to be added to includes		* <code><linux/platform_device.h></code> needs to be added to includes
Line 87:		Line 87:
	* <code>CLK_DONT_HOLD_STATE</code> in clock flags is downstream-specific, it has no equivalent in mainline.		* <code>CLK_DONT_HOLD_STATE</code> in clock flags is downstream-specific, it has no equivalent in mainline.

	==== Clock VDDs/regulators ====		=== Clock VDDs/regulators ===

	Remove anything related to "clock VDDs/regulators":		Remove anything related to "clock VDDs/regulators":
Line 98:		Line 98:
	These have no mainline equivalent.		These have no mainline equivalent.

	==== Clock parent data ====		=== Clock parent data ===

	Downstream and mainline differ in two significant ways when it comes to how clock parents are defined:		Downstream and mainline differ in two significant ways when it comes to how clock parents are defined:
Line 105:		Line 105:
	* Downstream puts the parent data directly in the clock struct; mainline puts it in separate structs.		* Downstream puts the parent data directly in the clock struct; mainline puts it in separate structs.

	==== Probe ====		=== Probe ===

	The way probing is done is different in mainline.		The way probing is done is different in mainline.
Line 132:		Line 132:
	For the rest of the probe steps, see how other drivers do it.		For the rest of the probe steps, see how other drivers do it.

	=== Interconnect driver ===		== Interconnect driver ==

	~~TODO~~ figure out what the interconnect actually does.		{{todo\|figure out what the interconnect actually does.}}

	Similar to clocks, interconnects are nearly the same as in downstream, but need some changes.		Similar to clocks, interconnects are nearly the same as in downstream, but need some changes.
Line 148:		Line 148:
	''See https://lore.kernel.org/all/20251031-rework-icc-v3-3-0575304c9624@oss.qualcomm.com/ for an example. Ignore the part where they add <code>alloc_dyn_id</code>, that was removed in another commit as dynamic IDs are now the only option.''		''See https://lore.kernel.org/all/20251031-rework-icc-v3-3-0575304c9624@oss.qualcomm.com/ for an example. Ignore the part where they add <code>alloc_dyn_id</code>, that was removed in another commit as dynamic IDs are now the only option.''

	=== TLMM/pinctrl ===		== TLMM/pinctrl ==

	Driver is in drivers/pinctrl/qcom.		Driver is in drivers/pinctrl/qcom.

Knuxify at 19:40, 6 June 2026

2026-06-06T19:40:45Z

← Older revision		Revision as of 19:40, 6 June 2026
Line 2:		Line 2:
	{{Work-in-progress page\|note=Currently in the middle of finding this out in real time :)}}		{{Work-in-progress page\|note=Currently in the middle of finding this out in real time :)}}

	This guide will cover the process of adding support for a recent (~2020 or newer~~, todo?~~) Qualcomm SoC into mainline Linux~~. Most of the information contained within is also applicable to older chips, though more manual effort may be needed to get these to run~~. <!--For the U-Boot guide, see TODO.-->		This guide will cover the process of adding support for a recent (~2020 or newer) Qualcomm SoC into mainline Linux. <!--For the U-Boot guide, see TODO.-->

	This guide was tested with the SM7435. Some details might be different for other SoCs. If you have any hints, please contribute!		This guide was tested with the SM7435. Some details might be different for other SoCs. If you have any hints, please contribute!
Line 48:		Line 48:
	todo		todo

	== ~~Porting individual parts~~ ==		== Clock controllers ==

	'''A note about licences and copying code:''' a good chunk of drivers can be copied from downstream with minimal modifications. In those cases, keep the original copyright at the top of the file (Copyright (c) 20xx, Qualcomm Innovation Center, Inc. etc), and add yourself below. (This seems to be how it was done for milos as well.)		{{note\|'''A note about licences and copying code:''' a good chunk of drivers can be copied from downstream with minimal modifications. In those cases, keep the original copyright at the top of the file ''(Copyright (c) 20xx, Qualcomm Innovation Center, Inc. etc)'', and add yourself below. (This seems to be how it was done for milos as well.)}}

	~~=== Clock controllers ===~~

	On recent Qualcomm SoCs, the downstream kernel uses the mainline Qualcomm clock driver with ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, though quite a few modifications are needed.		On recent Qualcomm SoCs, the downstream kernel uses the mainline Qualcomm clock driver with ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, though quite a few modifications are needed.

Knuxify: /* Clock controllers */

2026-06-06T19:31:43Z

Clock controllers

← Older revision		Revision as of 19:31, 6 June 2026
Line 54:		Line 54:
	=== Clock controllers ===		=== Clock controllers ===

	On recent Qualcomm SoCs, the downstream kernel uses the mainline Qualcomm clock driver with ~~only~~ ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, ~~with some slight~~ modifications.		On recent Qualcomm SoCs, the downstream kernel uses the mainline Qualcomm clock driver with ''some'' vendor-specific quirks. This means that the clock drivers and their relevant headers can pretty much be copied verbatim from downstream, though quite a few modifications are needed.

	~~First~~, ~~create~~ the '''GCC''' driver. Open <code>driver/clk/qcom/Kconfig</code> and add the relevant Kconfig option for your SoC (remember to keep it ordered alphabetically):		All clock controllers (gcc, dispcc, gpucc, videocc, camcc) use the same clock framework, so the following steps will work for all of them.

			{{hint\|Start with '''GCC''', as it's needed for most components. You may also need '''DISPCC''' for the display/framebuffer. Then do the remaining ones (GPUCC, VIDEOCC, CAMCC).}}

			==== Creating the driver ====

			First, create the driver. Open <code>driver/clk/qcom/Kconfig</code> and add the relevant Kconfig option for your SoC (remember to keep it ordered alphabetically):

	<syntaxhighlight lang="kconfig">		<syntaxhighlight lang="kconfig">
	config SM_GCC_xxxx		config SM_GCC_xxxx
	tristate "~~SMxxxx~~ Global Clock Controller"		tristate "xxxx Global Clock Controller"
	depends on ARM64 \|\| COMPILE_TEST		depends on ARM64 \|\| COMPILE_TEST
	select QCOM_GDSC		select QCOM_GDSC
	help		help
	Support for the global clock controller on ~~SMxxxx~~ devices.		Support for the global clock controller on xxxx devices.
	Say Y if you want to use peripheral devices such as UART,		Say Y if you want to use peripheral devices such as UART,
	SPI, I2C, USB, SD/UFS, PCIe etc.		SPI, I2C, USB, SD/UFS, PCIe etc.
Line 77:		Line 83:
	Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>; also copy the dt-bindings from <code>include/dt-bindings/clock/qcom,gcc-CODENAME.h</code> to <code>include/dt-bindings/clock/qcom,CODENAME-gcc.h</code> in mainline.		Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>; also copy the dt-bindings from <code>include/dt-bindings/clock/qcom,gcc-CODENAME.h</code> to <code>include/dt-bindings/clock/qcom,CODENAME-gcc.h</code> in mainline.

	~~(TODO these mention dispcc, I think gcc used the same steps as well)~~		==== Simple changes ====

	* <code>linux/platform_device.h</code> needs to be added to includes		* <code><linux/platform_device.h></code> needs to be added to includes
	* Anywhere <code>enable_safe_config</code> is set, change ops to <code>clk_rcg2_shared_ops</code><ref>https://lore.kernel.org/all/YbJMnvg%2FIDwHNeWS@ripper/</ref>.		* Anywhere <code>enable_safe_config</code> is set to <code>true</code>, remove it and change ops to <code>clk_rcg2_shared_ops</code><ref>https://lore.kernel.org/all/YbJMnvg%2FIDwHNeWS@ripper/</ref>.
	* Remove anything related to "clock VDDs/regulators" - notably the <code>"vdd-level.h"</code> include, <code>.clkr.vdd_data</code> members in clk data struct, regulator_data in final desc struct, and the declarations at the start. AFAICT these have no mainline equivalent.
	* <code>CLK_DONT_HOLD_STATE</code> in clock flags is downstream-specific, it has no equivalent in mainline.		* <code>CLK_DONT_HOLD_STATE</code> in clock flags is downstream-specific, it has no equivalent in mainline.
	* Look at the probe function.
	** Calls to <code>clk_lucid_evo_pll_configure</code>: note down the "&disp_cc_pllX" pointers, and place them in a struct: <syntaxhighlight lang="c">static struct clk_alpha_pll *disp_cc_CODENAME_plls[] = {		==== Clock VDDs/regulators ====

			Remove anything related to "clock VDDs/regulators":

			* The <code>"vdd-level.h"</code> include,
			* The regulator defines at the top,
			* <code>.clkr.vdd_data</code> members in clk data structs,
			* regulator_data in final desc struct.

			These have no mainline equivalent.

			==== Clock parent data ====

			Downstream and mainline differ in two significant ways when it comes to how clock parents are defined:

			* Downstream uses clock names; mainline uses '''clock IDs''' according to an enum at the start of the driver that is meant to be in the same order as the DT IDs.
			* Downstream puts the parent data directly in the clock struct; mainline puts it in separate structs.

			==== Probe ====

			The way probing is done is different in mainline.

			Look at the probe function, and find the following components:

			* Calls to <code>clk_lucid_evo_pll_configure</code>: note down the "&disp_cc_pllX" pointers, and place them in a struct: <syntaxhighlight lang="c">static struct clk_alpha_pll *disp_cc_CODENAME_plls[] = {
	&disp_cc_pll0,		&disp_cc_pll0,
	};</syntaxhighlight>		};</syntaxhighlight>
	** <code>regmap_update_bits</code> calls prefaced by a comment saying "Keep clocks always enabled": note down the 0x... addresses and place them in a struct like so: <syntaxhighlight lang="c">static u32 disp_cc_CODENAME_critical_cbcrs[] = {		* <code>regmap_update_bits</code> calls prefaced by a comment saying "Keep clocks always enabled": note down the 0x... addresses and place them in a struct like so: <syntaxhighlight lang="c">static u32 disp_cc_CODENAME_critical_cbcrs[] = {
	0xe054, /* DISP_CC_XO_CLK */		0xe054, /* DISP_CC_XO_CLK */
	};</syntaxhighlight>		};</syntaxhighlight>
	** Remaining <code>regmap_update_bits</code> calls: keep them, with the comments intact, and move them into a new function: <syntaxhighlight lang="c">static void disp_cc_CODENAME_clk_regs_configure(struct device dev, struct regmap regmap)		* Remaining <code>regmap_update_bits</code> calls: keep them, with the comments intact, and move them into a new function: <syntaxhighlight lang="c">static void disp_cc_CODENAME_clk_regs_configure(struct device dev, struct regmap regmap)
	{		{
	/* Enable clock gating for MDP clocks */		/* Enable clock gating for MDP clocks */
	regmap_update_bits(regmap, DISP_CC_MISC_CMD, 0x10, 0x10);		regmap_update_bits(regmap, DISP_CC_MISC_CMD, 0x10, 0x10);
	}</syntaxhighlight>		}</syntaxhighlight>
	** Then, add the driver_data struct:<syntaxhighlight lang="c">static struct qcom_cc_driver_data disp_cc_CODENAME_driver_data = {		* Then, add the driver_data struct: <syntaxhighlight lang="c">static struct qcom_cc_driver_data disp_cc_CODENAME_driver_data = {
	.alpha_plls = disp_cc_CODENAME_plls,		.alpha_plls = disp_cc_CODENAME_plls,
	.num_alpha_plls = ARRAY_SIZE(disp_cc_CODENAME_plls),		.num_alpha_plls = ARRAY_SIZE(disp_cc_CODENAME_plls),
Line 102:		Line 131:
	.clk_regs_configure = disp_cc_CODENAME_clk_regs_configure,		.clk_regs_configure = disp_cc_CODENAME_clk_regs_configure,
	};</syntaxhighlight>		};</syntaxhighlight>
	** For the rest of the probe steps, see how other drivers do it.
			For the rest of the probe steps, see how other drivers do it.

	=== Interconnect driver ===		=== Interconnect driver ===

Knuxify at 11:28, 6 June 2026

2026-06-06T11:28:25Z

@@ Line 49: / Line 49: @@
 == Porting individual parts ==
 === Clock controllers ===
@@ Line 73: / Line 75: @@
 </syntaxhighlight>
-Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>.
+Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>; also copy the dt-bindings from <code>include/dt-bindings/clock/qcom,gcc-CODENAME.h</code> to <code>include/dt-bindings/clock/qcom,CODENAME-gcc.h</code> in mainline.
-Paste the initialization code from another GCC driver (<syntaxhighlight inline lang="c">static struct platform_driver gcc_smXXXX_driver</syntaxhighlight> and onwards.)
+(TODO these mention dispcc, I think gcc used the same steps as well)
-{{todo|There are some missing struct members, these can be ommited. IIRC one has a counterpart in mainline but I don't remember which one... revisit this, maybe?}}
+* <code>linux/platform_device.h</code> needs to be added to includes
 === Interconnect driver ===

Knuxify: /* TLMM/pinctrl */

2026-06-06T09:47:33Z

TLMM/pinctrl

← Older revision		Revision as of 09:47, 6 June 2026
Line 99:		Line 99:
	Driver is in drivers/pinctrl/qcom.		Driver is in drivers/pinctrl/qcom.

	Downstream driver is split into a .c file and a .h file; mainline has them both in the .c file~~. TODO I don't remember exactly how I arrived at the mainline driver..~~.		Downstream driver is split into a .c file and a .h file; mainline has them both in the .c file.

	* Replace <code>~~MSM_GPIO_PIN_FUNCTION~~(gpio)</code> with <code>~~MSM_PIN_FUNCTION~~(gpio)</code>		* You'll likely have a REG_BASE added to all registers; mainline drivers don't have it. Remove it and offset the DT node instead.
			* Replace <code>MSM_PIN_FUNCTION(gpio)</code> with <code>MSM_GPIO_PIN_FUNCTION(gpio)</code>
	* Replace the probe and platform_device stuff with the same stuff copied from another driver in mainline		* Replace the probe and platform_device stuff with the same stuff copied from another driver in mainline

Knuxify at 18:36, 28 May 2026

2026-05-28T18:36:51Z

@@ Line 70: / Line 70: @@
 <syntaxhighlight lang="makefile">
-obj-$(CONFIG_SM_GCC_xxxx) += gcc-smXXXX.o
+obj-$(CONFIG_SM_GCC_CODENAME) += CODENAME-gcc.o
 </syntaxhighlight>
-Open <code>driver/clk/qcom/gcc-smXXXX.c</code>.
+Copy your downstream driver to <code>driver/clk/qcom/CODENAME-gcc.c</code>.
 Paste the initialization code from another GCC driver (<syntaxhighlight inline lang="c">static struct platform_driver gcc_smXXXX_driver</syntaxhighlight> and onwards.)
 == Porting the PMIC(s) ==

Knuxify: /* Finding information about your SoC */

2026-02-02T19:14:19Z

Finding information about your SoC

← Older revision		Revision as of 19:14, 2 February 2026
Line 38:		Line 38:
	** '''Board codename''' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.		** '''Board codename''' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.
	** '''Platform codename''' - presumably shared between multiple SoCs from the same family.		** '''Platform codename''' - presumably shared between multiple SoCs from the same family.
	** Since SM7635 ("Volcano"/"Milos"), Qualcomm ~~has~~ changed their policy around driver/compatible naming in mainline and now expects developers to use the platform codename instead<ref>https://lore.kernel.org/lkml/888a7598-38d9-4640-9823-2b073da006f4@kernel.org/</ref>. If you're unsure of the platform codename for your device, you can send the Qualcomm folks an email and ask them directly<ref>I ended up getting [https://lore.kernel.org/lkml/c379aad4-96f6-4134-8b90-0f1eec8001a3@oss.qualcomm.com/ a public reply to my query for SM7435].</ref>, or just use the model name for now and let them correct you (as was done in the Milos case).		** Since SM7635 ("Volcano"/"Milos") getting upstreamed, Qualcomm appears to have changed their policy around driver/compatible naming in mainline and now expects developers to use the platform codename instead of the model number<ref>https://lore.kernel.org/lkml/888a7598-38d9-4640-9823-2b073da006f4@kernel.org/</ref>. If you're unsure of the platform codename for your device, you can send the Qualcomm folks an email and ask them directly<ref>I ended up getting [https://lore.kernel.org/lkml/c379aad4-96f6-4134-8b90-0f1eec8001a3@oss.qualcomm.com/ a public reply to my query for SM7435].</ref>, or just use the model name for now and let them correct you (as was done in the Milos case).
	* A copy of the '''downstream kernel'''; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by downstream codename).		* A copy of the '''downstream kernel'''; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by downstream codename).
	* A copy of the '''<code>qcom_proprietary_devicetree</code>''' or similar repo with the DTSI source files (because they're not in the kernel repo for whatever reason...). Search for <code>(downstream codename).dtsi</code> on GitHub and you'll find the right repository eventually.		* A copy of the '''<code>qcom_proprietary_devicetree</code>''' or similar repo with the DTSI source files (because they're not in the kernel repo for whatever reason...). Search for <code>(downstream codename).dtsi</code> on GitHub and you'll find the right repository eventually.

Knuxify: /* Finding information about your SoC */

2026-02-02T19:12:36Z

Finding information about your SoC

← Older revision		Revision as of 19:12, 2 February 2026
Line 35:		Line 35:
	In order to begin mainlining your SoC, you need to have the following bits of information:		In order to begin mainlining your SoC, you need to have the following bits of information:

	* The '''codenames''' of the SoC. Qualcomm SoCs appear to have two codenames<ref>The names of these codenames have been sourced from [https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_8_Gen_1/8%2B_Gen_1/7%2B_Gen_2_(SM8450/SM8475/SM7475) the postmarketOS wiki page for the Snapdragon 8 Gen 1, not sure where that is sourced from.</ref>:		* The '''codenames''' of the SoC. Qualcomm SoCs appear to have two codenames<ref>The names of these codenames have been sourced from [https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_8_Gen_1/8%2B_Gen_1/7%2B_Gen_2_(SM8450/SM8475/SM7475) the postmarketOS wiki page for the Snapdragon 8 Gen 1], not sure where that is sourced from.</ref>:
	** '''Board codename''' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.		** '''Board codename''' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.
	** '''Platform codename''' - presumably shared between multiple SoCs from the same family.		** '''Platform codename''' - presumably shared between multiple SoCs from the same family.

Knuxify: /* Finding information about your SoC */

2026-02-02T19:11:54Z

Finding information about your SoC

← Older revision		Revision as of 19:11, 2 February 2026
Line 36:		Line 36:

	* The '''codenames''' of the SoC. Qualcomm SoCs appear to have two codenames<ref>The names of these codenames have been sourced from [https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_8_Gen_1/8%2B_Gen_1/7%2B_Gen_2_(SM8450/SM8475/SM7475) the postmarketOS wiki page for the Snapdragon 8 Gen 1, not sure where that is sourced from.</ref>:		* The '''codenames''' of the SoC. Qualcomm SoCs appear to have two codenames<ref>The names of these codenames have been sourced from [https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_8_Gen_1/8%2B_Gen_1/7%2B_Gen_2_(SM8450/SM8475/SM7475) the postmarketOS wiki page for the Snapdragon 8 Gen 1, not sure where that is sourced from.</ref>:
	** ''Board codename'' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.		** '''Board codename''' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.
	** ''Platform codename''~~. Presumably~~ shared between multiple SoCs from the same family.		** '''Platform codename''' - presumably shared between multiple SoCs from the same family.
	** Since SM7635 ("Volcano"/"Milos"), Qualcomm has changed their policy around driver/compatible naming in mainline and now expects developers to use the platform codename instead<ref>https://lore.kernel.org/lkml/888a7598-38d9-4640-9823-2b073da006f4@kernel.org/</ref>. If you're unsure of the platform codename for your device, you can send the Qualcomm folks an email and ask them directly<ref>I ended up getting [https://lore.kernel.org/lkml/c379aad4-96f6-4134-8b90-0f1eec8001a3@oss.qualcomm.com/ a public reply to my query for SM7435].</ref>, or just use the model name for now and let them correct you (as was done in the Milos case).		** Since SM7635 ("Volcano"/"Milos"), Qualcomm has changed their policy around driver/compatible naming in mainline and now expects developers to use the platform codename instead<ref>https://lore.kernel.org/lkml/888a7598-38d9-4640-9823-2b073da006f4@kernel.org/</ref>. If you're unsure of the platform codename for your device, you can send the Qualcomm folks an email and ask them directly<ref>I ended up getting [https://lore.kernel.org/lkml/c379aad4-96f6-4134-8b90-0f1eec8001a3@oss.qualcomm.com/ a public reply to my query for SM7435].</ref>, or just use the model name for now and let them correct you (as was done in the Milos case).
	* A copy of the '''downstream kernel'''; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by downstream codename).		* A copy of the '''downstream kernel'''; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by downstream codename).

Knuxify: /* Finding information about your SoC */

2026-02-02T19:11:22Z

Finding information about your SoC

← Older revision		Revision as of 19:11, 2 February 2026
Line 35:		Line 35:
	In order to begin mainlining your SoC, you need to have the following bits of information:		In order to begin mainlining your SoC, you need to have the following bits of information:

	* The '''codenames''' of the SoC. Qualcomm SoCs appear to have two codenames:		* The '''codenames''' of the SoC. Qualcomm SoCs appear to have two codenames<ref>The names of these codenames have been sourced from [https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_8_Gen_1/8%2B_Gen_1/7%2B_Gen_2_(SM8450/SM8475/SM7475) the postmarketOS wiki page for the Snapdragon 8 Gen 1, not sure where that is sourced from.</ref>:
	** ''"DTS nickname"~~'' (board name~~?)~~. You~~'ll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.		** ''Board codename'' ("DTS nickname"?) - you'll find it in the driver names on the device, as well as in the main compatible string of the devicetree. This is what's used across most of the downstream kernel.
	** ''Platform codename~~(?)~~''. Presumably shared between multiple SoCs from the same family.		** ''Platform codename''. Presumably shared between multiple SoCs from the same family.
	** Since SM7635 ("Volcano"/"Milos"), Qualcomm has changed their policy around driver/compatible naming in mainline and now expects developers to use the platform codename instead<ref>https://lore.kernel.org/lkml/888a7598-38d9-4640-9823-2b073da006f4@kernel.org/</ref>. If you're unsure of the platform codename for your device, you can send the Qualcomm folks an email and ask them directly<ref>I ended up getting [https://lore.kernel.org/lkml/c379aad4-96f6-4134-8b90-0f1eec8001a3@oss.qualcomm.com/ a public reply to my query for SM7435].</ref>, or just use the model name for now and let them correct you (as was done in the Milos case).		** Since SM7635 ("Volcano"/"Milos"), Qualcomm has changed their policy around driver/compatible naming in mainline and now expects developers to use the platform codename instead<ref>https://lore.kernel.org/lkml/888a7598-38d9-4640-9823-2b073da006f4@kernel.org/</ref>. If you're unsure of the platform codename for your device, you can send the Qualcomm folks an email and ask them directly<ref>I ended up getting [https://lore.kernel.org/lkml/c379aad4-96f6-4134-8b90-0f1eec8001a3@oss.qualcomm.com/ a public reply to my query for SM7435].</ref>, or just use the model name for now and let them correct you (as was done in the Milos case).
	* A copy of the '''downstream kernel'''; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by downstream codename).		* A copy of the '''downstream kernel'''; preferably the one for your device, but you can also use the kernel from another device with the same SoC, or - as a last resort - any kernel with the relevant SoC drivers (hint: search by downstream codename).