On 24/04/2024 00:33, Aren Moynihan wrote:
> stk3310 and stk3311 are typically connected to power supplies for the
> chip (vdd) and the infrared LED (leda). Add properties so we can power
> these up / down appropriately.
>
> Signed-off-by: Aren Moynihan
> ---
>
Reviewed-by
On 19/04/2024 10:42, Olivia Wen wrote:
> From: "olivia.wen"
>
> Under different applications, the MT8188 SCP can be used as single-core
> or dual-core.
>
> Signed-off-by: olivia.wen
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 14/04/2024 19:57, Aren Moynihan wrote:
> Signed-off-by: Aren Moynihan
> ---
Why? Please provide proper commit msg which will explain why you are
doing it (e.g. say about hardware).
Anyway empty commit msgs cannot be accepted.
Best regards,
Krzysztof
On 12/04/2024 16:22, Luca Weiss wrote:
> Add the PBS (Programmable Boot Sequencer) to the list of devices.
>
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Luca Weiss
> ---
> Changes in v2:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 10/04/2024 04:20, Ondřej Jirman wrote:
> On Mon, Apr 08, 2024 at 10:12:30PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 17:17, Ondřej Jirman wrote:
>>>
>>> Now for things to not fail during suspend/resume based on PM callbacks
>>> invocation o
On 31/03/2024 12:46, Karel Balej wrote:
> Marvell 88PM886 is a PMIC with several subdevices such as onkey,
> regulators or battery and charger. It comes in at least two revisions,
> A0 and A1 -- only A1 is described here at the moment.
>
> Reviewed-by: Krzysztof Kozlowski
> Si
On 11/04/2024 05:37, olivia.wen wrote:
> +};
> +
> static const struct of_device_id mtk_scp_of_match[] = {
> { .compatible = "mediatek,mt8183-scp", .data = _of_data },
> { .compatible = "mediatek,mt8186-scp", .data = _of_data },
> @@ -1323,6 +1362,7 @@ static const struct of_device_id
On 11/04/2024 05:37, olivia.wen wrote:
> Under different applications, the MT8188 SCP can be used as single-core
> or dual-core.
>
> Signed-off-by: olivia.wen
Are you sure you use full name, not email login as name?
> ---
> Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 3 ++-
>
Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
based on the alias from of_device_id table.
Signed-off-by: Krzysztof Kozlowski
---
drivers/rpmsg/qcom_glink_ssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rpmsg/qcom_glink_ssr.c b/drivers/rpmsg
On 09/04/2024 20:36, Luca Weiss wrote:
> Follow the gpio-hog bindings and use otg-hog as node name.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: K
e changed, 12 insertions(+)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 08/04/2024 21:32, Luca Weiss wrote:
> Use the apcs-kpss-global compatible for the APCS global mailbox block
> found on this SoC.
>
> This also resolves a dt-binding checker warning:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
reg/reg-names works and stable ABI is maintained.
>
> It also extends the examples for TCM split and lockstep modes.
>
> Signed-off-by: Radhey Shyam Pandey
> Signed-off-by: Tanmay Shah
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 08/04/2024 20:36, Luca Weiss wrote:
> On Montag, 8. April 2024 19:26:49 CEST Konrad Dybcio wrote:
>>
>> On 4/8/24 18:39, Luca Weiss wrote:
>>> Allow specifying a GPIO hog, as already used on
>>> qcom-msm8974-lge-nexus5-hammerhead.dts.
>>>
>>> Signed-off-by: Luca Weiss
>>> ---
>>>
On 08/04/2024 21:32, Luca Weiss wrote:
> Add compatible for the Qualcomm MSM8974 APCS block.
"... The block is already used in DTS, but without any SoC specific
compatible."
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
where the Linux driver explicitly
> disallows support for the auxiliary bus ("inv_mpu_i2c_aux_bus"). Since
> the driver is also based on "default: return true" this should scale
> better into the future.
>
> Signed-off-by: Luca Weiss
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 08/04/2024 17:17, Ondřej Jirman wrote:
> On Mon, Apr 08, 2024 at 03:27:00PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 14:48, Ondřej Jirman wrote:
>>> Yeah, I understand where the confusion is. The driver is not for anx7688
>>> chip
>>> really. The
On 08/04/2024 14:48, Ondřej Jirman wrote:
> On Mon, Apr 08, 2024 at 01:59:12PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 13:52, Ondřej Jirman wrote:
>>> On Mon, Apr 08, 2024 at 01:24:03PM GMT, Krzysztof Kozlowski wrote:
>>>> On 08/04/2024 13:21
On 08/04/2024 13:51, Ondřej Jirman wrote:
> Hi Krzysztof,
>
> On Mon, Apr 08, 2024 at 01:17:32PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 12:51, Pavel Machek wrote:
>>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
>>> but I did
On 08/04/2024 13:52, Ondřej Jirman wrote:
> On Mon, Apr 08, 2024 at 01:24:03PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 13:21, Pavel Machek wrote:
>>> Hi!
>>>
>>>>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
>>&g
On 08/04/2024 13:21, Pavel Machek wrote:
> Hi!
>
>>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
>>> but I did best I could.
>>>
>>> Signed-off-by: Pavel Machek
>>
>> ...
>>
>>> + cabledet-gpios:
>>> +maxItems: 1
>>> +description: GPIO controlling CABLE_DET (C3)
On 08/04/2024 12:51, Pavel Machek wrote:
> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> but I did best I could.
>
> Signed-off-by: Pavel Machek
...
> + cabledet-gpios:
> +maxItems: 1
> +description: GPIO controlling CABLE_DET (C3) pin.
> +
> + avdd10-supply:
++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 07/04/2024 11:58, Luca Weiss wrote:
> Set the 'items' correctly for the qcom,halt-regs property and update the
> description to match what it should be.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 24/03/2024 15:03, Stanislav Jakubek wrote:
> Document the Motorola Moto G (2013), which is a smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Signed-off-by: Stanislav Jakubek
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
Acked-by: Krzysztof Kozlow
On 21/03/2024 16:13, Tanmay Shah wrote:
>
>
> On 3/21/24 2:39 AM, Krzysztof Kozlowski wrote:
>> On 20/03/2024 16:14, Tanmay Shah wrote:
>>>
>>>
>>> On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
>>>> On 19/03/2024 15:42, Tanmay Shah w
On 20/03/2024 16:14, Tanmay Shah wrote:
>
>
> On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
>> On 19/03/2024 15:42, Tanmay Shah wrote:
>>>
>>>
>>> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>>>> On 19/03/2024 01:51, Tanmay Shah wrote:
On 19/03/2024 15:42, Tanmay Shah wrote:
>
>
> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>> Hello Krzysztof,
>>>
>>> Thanks for reviews. Please find my comments below.
>>>
>>> On 3/17/24
On 19/03/2024 01:37, Tanmay Shah wrote:
> Hello,
>
> Thanks for reviews, please find my comments below.
>
> On 3/17/24 9:50 AM, Conor Dooley wrote:
>> On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote:
>>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>>>
On 19/03/2024 01:51, Tanmay Shah wrote:
> Hello Krzysztof,
>
> Thanks for reviews. Please find my comments below.
>
> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal-NET platform is successor of Ve
On 11/03/2024 18:59, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
On 12/03/2024 13:13, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey
>>
>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>> UltraScale+ platform. It will help in defining TCM in device-tree
>&
On 19/03/2024 02:06, Tanmay Shah wrote:
>
>
> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>>> remoteproc driver is mostly compati
On 15/03/2024 22:15, Tanmay Shah wrote:
> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
> remoteproc driver is mostly compatible with new platforms except few
> platform specific differences.
>
> Versal has same IP of cortex-R5 cores hence maintained compatible string
On 15/03/2024 22:15, Tanmay Shah wrote:
> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
> contains multiple clusters of cortex-R52 real-time processing units.
> Each cluster contains two cores of cortex-R52 processors. Each cluster
> can be configured in lockstep mode or split
On 15/03/2024 22:15, Tanmay Shah wrote:
> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
> Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
> Only difference is power-domains ID needed by power management firmware.
> Hence, keeping the compatible
On 14/03/2024 14:49, Abdellatif El Khlifi wrote:
>> Frankly at the moment I'd be inclined to say it isn't even a remoteproc
>> binding (or driver) at all, it's a reset controller. Bindings are a contract
>> for describing the hardware, not the current state of Linux driver support -
>> if this
On 12/03/2024 18:42, Tanmay Shah wrote:
>
>
> On 3/12/24 7:13 AM, Krzysztof Kozlowski wrote:
>> On 11/03/2024 18:59, Tanmay Shah wrote:
>>> From: Radhey Shyam Pandey
>>>
>>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>>>
tead of
> keeping it flexible.
> - Add "items:" list in power-domains property
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 11/03/2024 19:39, Tanmay Shah wrote:
>>> +
>>> +else:
>>> + patternProperties:
>>> +"^r5f@[0-9a-f]+$":
>>> + type: object
>>> +
>>> + properties:
>>> +reg:
>>> + minItems: 1
>>> + items:
>>> +- description:
On 11/03/2024 17:27, Tanmay Shah wrote:
>>> +then:
>>> + patternProperties:
>>> +"^r5f@[0-9a-f]+$":
>>> + type: object
>>> +
>>> + properties:
>>> +reg:
>>> + minItems: 1
>>> + items:
>>> +- description: ATCM
On 11/03/2024 22:22, Pavel Machek wrote:
> Hi!
>
>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
>> but I did best I could.
>>
>> Signed-off-by: Pavel Machek
>
> Any more comments here? Automatic system told me I need to replace one
> character...
Well, I often do not
On 11/03/2024 11:26, Karel Balej wrote:
> Krzysztof Kozlowski, 2024-03-10T21:35:36+01:00:
>> On 10/03/2024 12:35, Karel Balej wrote:
>>> Dmitry Torokhov, 2024-03-04T17:10:59-08:00:
>>>> On Mon, Mar 04, 2024 at 09:28:45PM +0100, Karel Balej wrote:
>>>>>
On 10/03/2024 12:35, Karel Balej wrote:
> Dmitry Torokhov, 2024-03-04T17:10:59-08:00:
>> On Mon, Mar 04, 2024 at 09:28:45PM +0100, Karel Balej wrote:
>>> Dmitry,
>>>
>>> Dmitry Torokhov, 2024-03-03T12:39:46-08:00:
On Sun, Mar 03, 2024 at 11:04:25AM +0100, Karel Balej wrote:
> From: Karel
On 10/03/2024 12:41, Luca Weiss wrote:
> Add the compatible for this Sony smartphone.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 10/03/2024 15:13, Luca Weiss wrote:
> Add the compatible for this Samsung smartphone ("phablet" as it was
> named in that era).
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 01/03/2024 19:16, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
On 06/03/2024 15:40, Duje Mihanović wrote:
> IST3032C (and possibly some other models) has touch keys. Document this.
>
> Signed-off-by: Duje Mihanović
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
regulator-max-microvolt = <3300000>;
> +};
Messed indentation here and in following lines..
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> introduce the bindings for Arm remoteproc support.
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> .../bindings/remoteproc/arm,rproc.yaml| 69 +++
> MAINTAINERS
On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> add device tree node for the external system core in Corstone-1000
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> arch/arm64/boot/dts/arm/corstone1000.dtsi | 10 +-
> 1 file changed, 9
On 19/02/2024 18:44, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
dtschema defines label as string, so $ref in other bindings is
redundant.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm
TI Davinci remoteproc bindings were marked as work-in-progress /
unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add
bindings for Davinci DSP processors"). Almost seven years is enough, so
drop the "unstable" remark and expect usual ABI rules.
Signed-off-by:
Several TI SoC clock bindings were marked as work-in-progress / unstable
between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add
support for gate clock"). It was enough of time to consider them stable
and expect usual ABI rules.
Signed-off-by: Krzysztof Kozlowski
---
Doc
he
"unstable" remark and expect usual ABI rules.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/clock/keystone-gate.txt | 2 --
Documentation/devicetree/bindings/clock/keystone-pll.txt | 2 --
2 files changed, 4 deletions(-)
diff --git a/Documentation/devicetree/bi
On 21/02/2024 23:45, Pavel Machek wrote:
>>> +properties:
>>> + compatible:
>>> +const: usb-c-connector
>>> +
>>> + power-role: true
>>> +
>>> + data-role: true
>>> +
>>> + try-power-role: true
>>
>> I don't understand why do you have here properties. Do you see any
On 18/02/2024 16:10, Karel Balej wrote:
> Rob Herring, 2024-02-15T08:20:52-06:00:
>>> .../bindings/mfd/marvell,88pm88x.yaml | 74 +++
>>
>> Filename should match the compatible.
>>
>> In general, drop the 'x' wildcard.
>
> By "in general", do you mean for the drivers code
On 18/02/2024 21:57, Luca Weiss wrote:
> Follow the updated bindings and use a QCS404-specific compatible for the
> HFPLL on this SoC.
>
> Signed-off-by: Luca Weiss
> ---
> Please note that this patch should only land after the patch for the
> clock driver.
> ---
This patch should go in the
Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
iommu_ops_from_fwnode() stores _spec->np->fwnode in local
variable, so use it to simplify the code (iommu_spec is not changed
between these dereferences).
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/of_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
Make pointer to fwnode_handle a pointer to const for code safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/iommu.c | 2 +-
include/linux/iommu.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 26a31ba4f72d
The xlate callbacks are supposed to translate of_phandle_args to proper
provider without modifying the of_phandle_args. Make the argument
pointer to const for code safety and readability.
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/apple-dart.c | 3 ++-
drivers/iommu
Make pointer to bus_type a pointer to const for code safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/iommu-priv.h | 5 +++--
drivers/iommu/iommu.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu-priv.h b/drivers/iommu/iommu-priv.h
On 13/02/2024 21:37, Tanmay Shah wrote:
> Hello,
>
> Thanks for reviews please find my comments below.
>
> On 2/13/24 1:20 PM, Rob Herring wrote:
>> On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote:
>>> From: Radhey Shyam Pandey
>>>
>>> Introduce bindings for TCM memory address space on
On 12/02/2024 12:02, Pavel Machek wrote:
> Hi!
>>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
>>> but I did best I could.
>>>
>>> Signed-off-by: Pavel Machek
>>>
>>
>> You miss proper diffstat which makes reviewing difficult.
>
>> Actually entire patch is corrupted and
On 09/02/2024 20:51, Pavel Machek wrote:
> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> but I did best I could.
>
> Signed-off-by: Pavel Machek
>
You miss proper diffstat which makes reviewing difficult.
Actually entire patch is corrupted and impossible to apply.
On 10/02/2024 17:28, Luca Weiss wrote:
> Add the compatible for the SAW2 for L2 cache found on MSM8226.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml | 1 +
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 10/02/2024 17:38, Luca Weiss wrote:
> Add the compatibles and indexes for the rpmpd in MSM8974, both with the
> standard PM8841+PM8941 PMICs but also devices found with PMA8084.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 29/01/2024 08:48, Luca Weiss wrote:
> Some SC7280-based boards crash when providing the "secure_non_pixel"
> context bank, so allow only one iommu in the bindings also.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
tions(+)
>
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In
On 25/01/2024 17:42, Alexandru Elisei wrote:
> Allow the kernel to get the base address, size, block size and associated
> memory node for tag storage from the device tree blob.
>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that
On 23/01/2024 22:03, Luca Weiss wrote:
> From: Vladimir Lypak
>
> Add a new define for the GCC_MDSS_BCR found on MSM8953.
>
> Signed-off-by: Vladimir Lypak
> [luca: expand commit message]
> Signed-off-by: Luca Weiss
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 20/01/2024 22:16, Duje Mihanović wrote:
> IST3032C (and possibly some other models) has touch keys. Document this.
>
> Signed-off-by: Duje Mihanović
> ---
Please provide changelog describing what changed against v1. Cover
letter has something but it is not accurate. It says nothing about
dtschema package defines firmware-name as string-array, so individual
bindings should not make it a string but instead just narrow the number
of expected firmware file names.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 4
On 28/12/2023 10:39, Karel Balej wrote:
> diff --git a/drivers/mfd/88pm88x.c b/drivers/mfd/88pm88x.c
> index 69a8e39d43b3..999d0539b720 100644
> --- a/drivers/mfd/88pm88x.c
> +++ b/drivers/mfd/88pm88x.c
> @@ -68,6 +68,21 @@ static struct mfd_cell pm886_devs[] = {
> .num_resources =
On 07/01/2024 10:49, Karel Balej wrote:
> Mark,
>
> On Fri Jan 5, 2024 at 4:18 PM CET, Mark Brown wrote:
>> On Thu, Dec 28, 2023 at 10:39:13AM +0100, Karel Balej wrote:
>>
>>> @@ -68,6 +68,21 @@ static struct mfd_cell pm886_devs[] = {
>>> .num_resources =
On 06/01/2024 11:19, Luca Weiss wrote:
> On Dienstag, 2. Jänner 2024 11:41:26 CET Krzysztof Kozlowski wrote:
>> On 31/12/2023 15:48, Luca Weiss wrote:
>>> It doesn't appear that the configuration is for the HFPLL is generic, so
>>
>> That's ok...
>>
>>>
On 04/01/2024 10:25, Krzysztof Kozlowski wrote:
> On 28/12/2023 10:39, Karel Balej wrote:
>> From: Karel Balej
>>
>
> A nit, subject: drop second/last, redundant "documentation entry". The
> "dt-bindings" prefix is already stating that these are bindi
On 28/12/2023 10:39, Karel Balej wrote:
> From: Karel Balej
>
A nit, subject: drop second/last, redundant "documentation entry". The
"dt-bindings" prefix is already stating that these are bindings.
> The Marvell 88PM88X PMICs provide regulators among other things.
> Document how to use them.
On 31/12/2023 15:48, Luca Weiss wrote:
> It doesn't appear that the configuration is for the HFPLL is generic, so
That's ok...
> add a qcs404-specific compatible and rename the existing struct to
but why this is the solution? If the qcom,hfpll compatible was
deprecated, but it is not. This
m,hfpll";
> +reg = <0xf9016000 0x30>;
> +clocks = <_board>;
> + clock-names = "xo";
> +clock-output-names = "hfpll_l2";
> +#clock-cells = <0>;
> +};
> + # Example 2 - HFPLL for CPU0
Just keep one example, they are the same. And then drop the comment.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 20/12/2023 11:02, Luca Weiss wrote:
> Document the QCM6490 compatible used to describe the pmic glink on this
> platform.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 13/12/2023 21:33, André Apitzsch wrote:
> This dts adds support for Motorola Moto G 4G released in 2013.
>
> Add a device tree with initial support for:
>
> - GPIO keys
> - Hall sensor
> - SDHCI
> - Vibrator
>
> Signed-off-by: André Apitzsch
> ---
> arch/arm/boot/dts/qcom/Makefile
On 13/12/2023 21:33, André Apitzsch wrote:
> Document the compatible for the MSM8926-based Motorola Moto G 4G smartphone.
>
> Signed-off-by: André Apitzsch
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
ini 2")
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 24/11/2023 14:57, Jianhua Lu wrote:
> ufs node isn't in a right place, 'f' is front of 's', so move it to
> above usb node.
Please not.
If we change the order to match DTSI, then this patch would be wrong.
Best regards,
Krzysztof
Use only one and exactly one space around '=' in DTS example.
Signed-off-by: Krzysztof Kozlowski
---
Merging idea: Rob's DT.
Should apply cleanly on Rob's for-next.
---
.../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +-
.../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
rtions(+), 1 deletion(-)'
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 30/10/2023 09:29, Neil Armstrong wrote:
> Ok, I fixed all that
>
>>
>>> + - if:
>>> + properties:
>>> +compatible:
>>> + enum:
>>> +- qcom,sm8650-mpss-pas
>>> +then:
>>
>> I am not sure if keeping it in the same binding as sm8550 avoids that
>> much
On 29/10/2023 12:08, Karel Balej wrote:
> Document the corresponding compatible string for the use of this driver
> with the Marvell SD8777 wireless chipset.
>
> Signed-off-by: Karel Balej
> ---
Acked-by: Krzysztof Kozlowski
---
This is an automated instruction, just in cas
t; though I cannot be sure there.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 +
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 138
> +
> 2 files changed, 143 insertions(+)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 27/10/2023 16:20, Luca Weiss wrote:
> Add the node for the ADSP found on the SC7280 SoC, using standard
> Qualcomm firmware.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
e changed, 21 insertions(+)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
compatible is used.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi | 2 ++
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +--
> 2 files changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
om,sc7180-pas: split into
> separate file")
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 26/10/2023 15:24, Stefan Hansson wrote:
> This was not enabled in the matisse-wifi tree. Without this, it is not
> possible to use the USB port for serial debugging via a "Carkit debug
> cable".
>
> Signed-off-by: Stefan Hansson
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
-samsung-matisse-wifi.dts (85%)
> copy arch/arm/boot/dts/qcom/{qcom-apq8026-samsung-matisse-wifi.dts =>
> qcom-msm8226-samsung-matisse-common.dtsi} (86%)
Thanks. For me this diff is much more readable - I clearly see what was
removed from final DTSI file thus what I should expect in DT
1 - 100 of 16169 matches
Mail list logo
