Add support for the Xiaomi Mi Note 3#181
Draft
Kernel114514 wants to merge 126 commits into
Draft
Conversation
When encoding QMI messages, the "source buffer" is a C-struct in the
host memory, so while the data that goes into the outgoing buffer should
be converted to little endian, the length should not be.
Commit 'fe099c387e06 ("soc: qcom: preserve CPU endianness for
QMI_DATA_LEN")' fixed this, but did it by copying a whole word from the
source into a local u32 and then operated on that.
If the length in the DATA_LEN refers to either a char or short array,
it's reasonable to expect that the struct is packed such that this word
will contain not only the length-byte (or length-short), but also the
beginning of the payload.
As the encoder loops around to encode the payload it runs into an
unreasonable value of "data_len_value" and bails, with the error message
"qmi_encode: Invalid data length".
Rather then complicating the logic with local variables of different
types we can instead pick the u8 or u16 "data_len_value" directly from
"buf_src". As "buf_src" refers to a typical C-structure in the client
drivers, we expect this field to be naturally aligned.
We can then return to the original expression of qmi_encode_basic_elem()
encoding directly from "src_buf" to "dst_buf", with the endianness
conversion, based on the size of the type.
Reported-by: David Heidelberg <david@ixit.cz>
Closes: https://lore.kernel.org/all/dfb72933-938f-43f2-87f3-2e3ab9697125@ixit.cz/
Fixes: fe099c3 ("soc: qcom: preserve CPU endianness for QMI_DATA_LEN")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
When decoding a variable-length element from a QMI message the length is either a u8 or u16 field in the destination C-struct, but the current implementation prepares the value on the stack and then writes out a whole word. In a little endian system, this results in the following 2 or 3 bytes being zeroed out, and then presumably overwritten by the actual payload. So unless the length field is followed by an unreasonably short array, the splat is contained - but unnecessary. While not verified, in a big endian system, the length should end up beyond the length field, resulting in a 0-length value with "garbage" in the payload. Given the expectation that the QMI message is decoded into the naturally aligned byte or short-sized length, we can simply read the endian-correct length back from the destination buffer and use this for further processing. Fixes: fe099c3 ("soc: qcom: preserve CPU endianness for QMI_DATA_LEN") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Since Android primary bootloader with system-as-root feature [1] enabled adds some arguments to kernel command line from boot.img, that make booting Linux harder: * skip_initramfs * root=/dev/dm-0 * init=/init * dm=... Most importantly, Linux processes root= parameter and at boot time skips initramfs and tries to mount root device that does not exist and fails. Add a quick hack to scramble these parameters from cmdline passed by primary bootloader in FDT /chosen/bootargs property, so that Linux won't accidentally process them. [1] https://source.android.com/docs/core/architecture/partitions/system-as-root Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Generated with: $ make savedefconfig && cp defconfig ../arch/arm64/configs/sdm660_defconfig Use it: $ make defconfig sdm660_defconfig barni2000: Add CONFIG_DRM_PANEL_BOE_TD4320 as a module. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Signed-off-by: Barnabás Czémán <trabarni@gmail.com> Enable neccessary options for RGB-LED Signed-off-by: Nickolay Goppen <killubuntoid@yandex.ru> sdm660_defconfig: enable options needed for BlackBerry KEY2 peripherals Signed-off-by: Paul Sajna <hello@paulsajna.com>
===== Add CI script that runs make CHECK_DTBS on PRs/tags/etc. dt-validate (and therefore, make CHECK_DTBS) always return 0 exit code! Even if there are errors. So, some post-processing analyzer step is needed. * save check_dtbs results to file to be able to analyze it * add python script that tries to count how many errors are there in results file and has ability to ignore some of them! * use continue-on-error: true for now, to still allow it to fail * also run dt_bindings_check in addition to dtbs_check, but only if any Documentation/*.yaml was modified ===== Extend CI so it can use self-hosted runner And produce .apk package for our kernel, and also boot images in the future. * build linux image on aarch64 builder * with pmbootstrap make linux-postmarketos-qcom-sdm660 package * publish first artifact Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
If video mode is used, DSI host needs a reset after encoder shut down to be able to transmit commands again. If it's not done we will time out waiting on VIDEO_DONE IRQ because VIDEO_MODE_ENGINE_BUSY flag gets stuck after encoder is disabled. Subsequent command transfers time out too: [ 89.798035] msm_dsi 1a94000.dsi: [drm:dsi_cmds2buf_tx [msm]] *ERROR* wait for video done timed out [ 90.005916] dsi_cmds2buf_tx: cmd dma tx failed, type=0x15, data0=0x28, len=4, ret=-110 To work around this issue we can reset DSI host if VIDEO_DONE IRQ didn't trigger after at least one refresh period has passed. This fixes command transfers from panel unprepare callback. Also since we legitimizing the time out let's reduce delay in reset. In downstream kernel the reset delay is at most 1 microsecond. Fixes: 007ac02 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Add spi7 interface to SDM630 device tree. Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Similarly to MSM8996 DragonBoard 820c, MSM8998 and SDM630 are equipped with Adreno 5xx series, which doesn't have separate pagetables support at the moment of writing. Skip the TTBR1 quirk for these two SoCs as to get Adreno in a usable state.
Add MSM8998 and SDM660's mss-pil compatibles to switch the default iommu domain type to IDENTITY, as similarly required by SDM845 and others. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> (JAMI: fixup for 6.0-rc2)
Add SDM630/660's MDP5 compatibles to switch the default iommu domain type to IDENTITY, as similarly required by SDM845 and others. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Add bindings for qcom PMIC SPMI haptics driver. Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Add newly added spmi-haptics driver to the list of allowed options for the vibrator subnode of SPMI PMICs. Fixes lots of dt-validate warnings. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Add support for the haptics found in pmi8998 and related PMICs. Based on the ff-memless interface. Currently this driver provides a partial implementation of hardware features. This driver only supports LRAs (Linear Resonant Actuators) in the "buffer" mode with a single wave pattern. Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Add a DT schema for Qualcomm PMIC fuel gauge. Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> Remove pmi8994 fuel gauge and update example for pmi8998-fg. Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Ths driver supports the fuel gauge hardware available on PMICs such as PMI8994, as well as gen 3 fuel gauge hardware available on PMI8998. Co-developed-by: Caleb Connolly <caleb@connolly.tech> Co-developed-by: Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> qcom_fg: expose PROP_STATUS to fix upower not detecting charging status properly fg: adopt battery info API changes power: qcom_fg: silence -EPROBE_DEFER error Sometimes, the devm_power_supply_register function will return ERR_PTR(-EPROBE_DEFER) to make the driver subsystem probe the fuel guage later. This is not an error and do not report it as such. Signed-off-by: Richard Acayan <mailingradian@gmail.com> power/supply: qcom_fg: add present sysfs property Present property is required for battery drivers from UPower>=1.90.0 onwards to work properly. Signed-off-by: Alexander Martinz <amartinz@shiftphones.com> power: supply: qcom_fg: dont put battery info on remove all the battery info data is devm tracked so it will be freed for us on removal. Signed-off-by: Casey Connolly <casey.connolly@linaro.org> power: supply: qcom_fg: invert charging current battery current should be negative for charging batteries, inevrt it so it's correct. Fixes upower charging status reporting. Signed-off-by: Casey Connolly <casey.connolly@linaro.org> power: supply: qcom_fg: remove PMI8994 fuel gauge Remove Pre-Gen3 fuel gauge support the two generation have very little in common. This driver squashing 2 driver together so better to separate them. Additional Changes: - Fix all checkpatch issues in strict mode. - Rename the driver to pmi8998_fg. - Remove unneccessary batt_info. Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Add newly added PMI8998 battery fuel gauge driver to the list of allowed subnodes of qcom SPMI PMICs. This fixes lots of dtbs_check errors. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Hook up USBIN_CMD_IL so that writing "0" to the status register will disable charging, this is useful to let users limit charging automatically. Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Respect the max current limit set on the battery node, one some devices this is set conservatively to avoid overheating since they only have a single charger IC (instead of two in parallel). Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
I set a super conservative current limit since we lack many of the safety features (thermal monitoring, etc) that these drivers really need. However now we have a better understanding of the hardware, it's fine to bump this limit up a bit, devices can additionally set the max current via devicetree instead. Since this is common to smb2 and smb5, move this write out of the init sequence and into probe proper. Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
PM660 has a fuel guage gen 3, which is compatible with the one used in MSM8998. Signed-off-by: Aboothahir U <aboothahirpkd@gmail.com>
In Xiaomi Poco F1, the qcom wled driver warns [ 1.151677] ------------[ cut here ]------------ [ 1.151680] Unbalanced enable for IRQ 176 [ 1.151693] WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 __enable_irq+0x50/0x80 [ 1.151710] Modules linked in: [ 1.151717] CPU: 0 PID: 160 Comm: kworker/0:11 Not tainted 5.17.0-sdm845 sdm660-mainline#4 [ 1.151724] Hardware name: Xiaomi Pocophone F1 (DT) [ 1.151728] Workqueue: events wled_ovp_work [ 1.151740] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.151746] pc : __enable_irq+0x50/0x80 [ 1.151750] lr : __enable_irq+0x50/0x80 [ 1.151755] sp : ffff80000923bd70 [ 1.151757] x29: ffff80000923bd70 x28: 0000000000000000 x27: 0000000000000000 [ 1.151766] x26: ffffc306b1d334f8 x25: ffff47f136774405 x24: ffff47f04014b130 [ 1.151774] x23: ffff47f136774400 x22: ffff47f1367706c0 x21: 0000000000000000 [ 1.151782] x20: 00000000000000b0 x19: ffff47f040ed1a00 x18: ffffffffffffffff [ 1.151789] x17: 000000040044ffff x16: 004000b2b5503510 x15: ffffc306b1d3ecc1 [ 1.151797] x14: 0000000000000000 x13: 3637312051524920 x12: 726f6620656c6261 [ 1.151805] x11: ffffc306b1b608d8 x10: 000000000000000a x9 : 00000000000000b0 [ 1.151812] x8 : 000000000000000a x7 : 6c62616e65206465 x6 : 00000000fffff166 [ 1.151818] x5 : 00000000fffff166 x4 : 0000000000000000 x3 : 00000000ffffffff [ 1.151825] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff47f042211c00 [ 1.151833] Call trace: [ 1.151836] __enable_irq+0x50/0x80 [ 1.151841] enable_irq+0x48/0xa0 [ 1.151846] wled_ovp_work+0x18/0x24 [ 1.151850] process_one_work+0x1d0/0x350 [ 1.151858] worker_thread+0x13c/0x460 [ 1.151862] kthread+0x110/0x114 [ 1.151868] ret_from_fork+0x10/0x20 [ 1.151876] ---[ end trace 0000000000000000 ]--- Fix it by storing and checking the state of ovp irq during enabling and disabling of the irq.
The WCN3990 might split MSDUs among multiple "in-order" indications. The driver needs information from previous indications to handle MPDUs that are not started by the same indications that complete them. Move the list that tracks unprocessed MSDUs to the driver state so the driver can handle MPDUs that are split in this way and be less confused. Fixes: c545070 ("ath10k: implement rx reorder support") Signed-off-by: Richard Acayan <mailingradian@gmail.com>
When sending DELETE_KEY, the driver times out waiting for a response that doesn't come. Only wait for a response when sending SET_KEY. Sample dmesg: [ 117.285854] wlan0: deauthenticating from XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING) [ 120.302934] ath10k_snoc 18800000.wifi: failed to install key for vdev 0 peer XX:XX:XX:XX:XX:XX: -110 [ 120.302996] wlan0: failed to remove key (0, XX:XX:XX:XX:XX:XX) from hardware (-110) Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Add new specific version of RCG2 ops (clk_gfx3d_src_ops) that is designed to support GPU clock controller driver for SDM630/660 SoCs. Already existing clk_gfx3d_ops doesn't support handling frequency tables for gfx3d_src_clk, which is fine for Adreno 530/540 with GMU, but is required for lower-end A508/509/512 without GMU. Co-developed-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Co-developed-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
For platforms without GMU frequency for gfx3d clock needs to be
managed by GPU devfreq withing adreno driver. Currently there is
a problem: there is no frequency table specified for gfx3d_clk_src
and gfx3d clock is running on some "random" 500 MHz frequency, as
can be seen on SDM630/660 devices:
$ grep -i -E '(gpu|gfx)' /sys/kernel/debug/clk/clk_summary
$ cat /sys/kernel/debug/devfreq/devfreq_summary
Will output: (extra columns removed to fit)
gpu_pll1_pll_out_main 740000000
gpu_pll0_pll_out_main 1000000000
gfx3d_clk_src 500000000
gpucc_gfx3d_clk 500000000
dev cur_freq_Hz min_freq_Hz max_freq_Hz
--------------------------------------------------
5000000.gpu 700000000 700000000 700000000
And additionally, the following errors can be seen in dmesg:
devfreq 5000000.gpu: Couldn't update frequency transition information.
As you can see, gf3d_clk is running on some weird 500 Mhz
frequency, which is not even present in GPU opp-tables, with
parent gpu_pll on 1 GHz. And additionally, devfreq thinks it's
running on 700 MHz (output is from SDM630 device).
Lucky SDM660 can function this way, since most speedbins allow
frequencies up to 647 MHz, and on SDM630 700 MHz max is commonly
seen. Can function, but constantly only on 500 MHz. Unlucky SDM636
devices, however, can't probe GPU at all: observing either system
freeze during boot, or GPU hangs. Sometimes it can randomly probe
with gx3d_clk parented to gpucc_cxo running at 19.2 MHz and producing
2-5 FPS in GUI mobile shells like phosh. Which currently puts all
SDM636 devices into the category of "barely functioning bricks".
To solve all this, we need:
* add freq table to gfx3d_clk_src;
* switch to new clk_gfx3d_src_ops to support all this.
With this change, SDM636 phones turn from unusable bricks to
almost functional linux mobile devices (given the other missing
parts of the platform support); and SDM630/660 phones receive
the ability to run sometimes at slightly higher speeds, giving
slightly more FPS in SuperTuxKart and more points in glmark2.
Additionally on all of the SDM630/636/660 gpucc_gfx3d_clk will
be able to run on the lowest speeds (down to "idle" 19.2 MHz)
which I believe should help power savings.
Also, there will be no discrepancy between GPU devfreq and real
clock frequency, and no errors about missing frequencies from
opp tables.
Co-developed-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Co-developed-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
After gpucc-sdm660 rework, make frequencies list in opp-tables
match the ones in GPU clock controller driver for each of SDM630
and SDM660 platforms. They should match to avoid error messages
in dmesg like:
dev_pm_opp_set_rate: failed to find OPP for freq 500000000 (-34)
Previous authors left highest frequencies commented due to some
issues with interconnect framework and missing support for the
GPU regulator; keep them commented, uncomment all others, add
19.2 MHz one, specify correct opp-supported-hw values for each
one of them.
Since list of frequencies supported by GPUCC is different between
SDM630 and SDM660, and there is also difference in frequencies
supported on bin 135:
* SDM660, bin 135: 647000000, 588000000, 465000000, 370000000,
266000000, 160000000, 19200000
* SDM630, bin 135: 647000000, 588000000, 465000000, 370000000,
240000000, 160000000, 19200000
(266 MHz vs 240 MHz), so we have to delete the opp-table inherited
from sdm630.dtsi and write new one for sdm660/636 from scratch.
P.S. Maybe we can uncomment all high OPPs, because they are not
available due to speedbin values?
Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
In order for a5xx code to be able to use the same method of configuring speedbins and opp-supported-hw, move fuse_to_supp_hw() and a6xx_set_supported_hw() (renamed to adreno_set_supported_hw) to common code into adreno_gpu.c. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Specify speedbins for Adreno 508, 509 and 512 GPUs found in SDM630/636/660 SoCs and their respective bits used for bitmasks in opp-supported-hw setting, using ADRENO_SPEEDBINS macro, same way as a6xx_catalog does it. This will allow us to reuse common code for a5xx/a6xx to configure opp tables and its supported-hw values. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
For Adreno 508/509/512 use the newly available common method to configure opp-tables supported hw value, shared with a6xx. Keep the old way (check_speed_bin) around for plaforms that have not yet been ported device trees and definion of speed bins in a5xx_catalog. This way only SDM630/636/660 are affected, to avoid potential regressions on e.g. MSM8996/8998. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Add the ASM-AFE routing for internal MI2S ports. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Add compatibles for sdm660-internal based soundcards. Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
The Snapdragon 670 and Snapdragon 660 both share the same drivers for the sound cards. These different sound cards are tasha, tavil, and internal. Add support for the internal sound card. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
The codec version CAJON_2_0 on the Snapdragon 670 requires touching the HPH test registers. Add the quirk so this driver can also support SDM670. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
The digital and analog codecs communicate with each other, synchronized by an MCLK, which cannot turn off before the codecs power down. The bit clock is better managed by the sound card driver instead of the digital codec, since it (to my knowledge) does not power down the clock. Add the Q6AFE clock controller to connect the MCLK with the codecs, and a fixed clock to model a fake bit clock for consumption by the digital codec. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
The digital codec is responsible for controlling playback volume and sending PCM data to the analog codec. Add it. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
The PM660L analog audio codec (PMIC revision 4) controls the headphone jack, and optionally the earpiece and speaker, at the vendor's decision. Add the analog audio codec. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
…r services qcom,protection-domain property is required for adsp to properly APR functioning, such as: * Working q6afecc clocks * Opening AFE ports Signed-off-by: Nickolay Goppen <setotau@yandex.ru>
…for clover Signed-off-by: Nickolay Goppen <setotau@yandex.ru>
Add the sound card and configure the SoC generic analog and digital codecs to complete the drive-by sound support series. Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Suspicion is that msm_gpu_fault_crashstate_capture() does something that causes hang for the whole device, so you cannot get any crash dumps. Faults still happen sometimes, and they are logged, but device remains usable. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Add compatible string for the Novatek NT36672A e7t touchscreen variant found on the Xiaomi Redmi Note 6 Pro (tulip). This variant uses different chip parameters compared to the standard NT36672A, specifically a different wake_type value. Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Add support for the Novatek NT36672A touchscreen variant found on the Xiaomi Redmi Note 6 Pro (tulip) which uses a different wake_type value (0x02 instead of 0x01). The touchscreen was failing to initialize with error -5 due to the wake_type parameter mismatch during probe. This adds a new chip data structure for the e7t variant with the correct wake_type value. Fixes: sdm660-mainline#155 Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Add the sound card and configure the SoC generic analog and digital codecs. Include MCLK routing to RX_BIAS, INT_LDO_H, RX_I2S_CLK, TX_I2S_CLK and ADC paths required for proper Q6 DSP initialization. Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
The SDM660 ADSP firmware has a maximum buffer size limit of approximately 256KB. When attempting to allocate larger buffers (e.g., 512KB), the DSP returns ADSP_EFAILED (General Failure). Add a hardware constraint in the startup callback to limit playback buffer size to 262144 bytes (256KB). This prevents the error: "DSP returned error[0x1:GENERAL_FAILURE] for CMD opcode=0x10d92" The constraint is SDM660-specific and doesn't affect other Qualcomm SoCs using the q6asm-dai driver. Tested on Xiaomi Redmi Note 6 Pro (tulip) with SDM636. Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
Add support for battery, fuelgauge and charger. Source: downstream [1] [1] LineageOS/android_kernel_sony_sdm660@9b87354 Signed-off-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
As tested in sdm660-bbry-athena-syna, a Blackberry KEY2 smartphone variant with 1620x1080 resolution Generated by mdss-panel-generator Signed-off-by: Paul Sajna <hello@paulsajna.com>
Synaptics TD4310 found in some variants of BlackBerry KEY2 (LE) Signed-off-by: Paul Sajna <hello@paulsajna.com>
Synaptics Panel and Touchscreen variants Signed-off-by: Paul Sajna <hello@paulsajna.com>
…una-syna Synaptics variant of Blackberry KEY2 and Blackberry KEY2 LE Signed-off-by: Paul Sajna <hello@paulsajna.com>
Synaptics Touchscreen isn't added.
Member
|
dtbs-check contains few issues: ignore panel ones for now, but there is something wrong with touchscreen node. Which address is touchscreen on? 20 or 112 (0x70) ?? |
minlexx
requested changes
May 16, 2026
Member
minlexx
left a comment
minlexx
left a comment
There was a problem hiding this comment.
Also commits that are intended to go upstream (dts addition and qcom.yaml ones) should contain Signed-off-by: lines. Use git commit -s ... to add it automatically or for now you can just manually amend each commit's message with git's interactive rebase.
Please read Documentation/process/submitting-patches.rst section about "Developer's Certificate of Origin"
| @@ -0,0 +1,625 @@ | |||
| // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) | |||
| /* | |||
| * Copyright (c) 2026, Kernel114514 <Kernel114514@hotmail.com> | |||
Member
There was a problem hiding this comment.
This should be real person name, not just Kernel114514
The same notice goes for panel driver (but we'll rework panel driver later, so ignore that)
minlexx
force-pushed
the
qcom-sdm660-7.0.y
branch
from
4ea07ac to
76bb7fb
Compare
Kernel114514
force-pushed
the
qcom-sdm660-7.0.y
branch
from
34a8351 to
a1308eb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#180