Add "simple-mfd" as a second compatible string to allow child nodes
within the CAMSS block to probe as individual platform devices.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
index 2d1662ef522b7..b5654ef71bd89 100644
--- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
@@ -14,7 +14,11 @@ description:
properties:
compatible:
- const: qcom,x1e80100-camss
+ oneOf:
+ - const: qcom,x1e80100-camss
+ - items:
+ - const: qcom,x1e80100-camss
+ - const: simple-mfd
reg:
maxItems: 17
@@ -191,7 +195,7 @@ examples:
#size-cells = <2>;
camss: isp@acb7000 {
- compatible = "qcom,x1e80100-camss";
+ compatible = "qcom,x1e80100-camss", "simple-mfd";
reg = <0 0x0acb7000 0 0x2000>,
<0 0x0acb9000 0 0x2000>,
--
2.52.0On Mon, Mar 16, 2026 at 01:02:01AM +0000, Bryan O'Donoghue wrote:
> Add "simple-mfd" as a second compatible string to allow child nodes
> within the CAMSS block to probe as individual platform devices.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> index 2d1662ef522b7..b5654ef71bd89 100644
> --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> @@ -14,7 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,x1e80100-camss
> + oneOf:
> + - const: qcom,x1e80100-camss
> + - items:
> + - const: qcom,x1e80100-camss
> + - const: simple-mfd
>
> reg:
> maxItems: 17
> @@ -191,7 +195,7 @@ examples:
> #size-cells = <2>;
>
> camss: isp@acb7000 {
> - compatible = "qcom,x1e80100-camss";
> + compatible = "qcom,x1e80100-camss", "simple-mfd";
You do not have any children here. And if you checked the DTS, you
would see this does not work.
Please post complete example and bindings.
I suspect that after posting complete picture we will see this is not a
simple-mfd device (child depends on parent).
Best regards,
Krzysztof
On 16/03/2026 07:29, Krzysztof Kozlowski wrote:
> On Mon, Mar 16, 2026 at 01:02:01AM +0000, Bryan O'Donoghue wrote:
>> Add "simple-mfd" as a second compatible string to allow child nodes
>> within the CAMSS block to probe as individual platform devices.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> ---
>> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>> index 2d1662ef522b7..b5654ef71bd89 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>> @@ -14,7 +14,11 @@ description:
>>
>> properties:
>> compatible:
>> - const: qcom,x1e80100-camss
>> + oneOf:
>> + - const: qcom,x1e80100-camss
>> + - items:
>> + - const: qcom,x1e80100-camss
>> + - const: simple-mfd
>>
>> reg:
>> maxItems: 17
>> @@ -191,7 +195,7 @@ examples:
>> #size-cells = <2>;
>>
>> camss: isp@acb7000 {
>> - compatible = "qcom,x1e80100-camss";
>> + compatible = "qcom,x1e80100-camss", "simple-mfd";
>
> You do not have any children here. And if you checked the DTS, you
> would see this does not work.
>
> Please post complete example and bindings.
>
> I suspect that after posting complete picture we will see this is not a
> simple-mfd device (child depends on parent).
>
> Best regards,
> Krzysztof
>
This is it:
https://lore.kernel.org/r/20260316-x1e-camss-csi2-phy-dtsi-v2-3-859f3fa55790@linaro.org
Just broke up the series so that drivers/bindings could go through
linux-media and the dtsi stuff through Bjorn.
I actually got the idea from:
commit fe6a952b567f6a771d087d2e969914f31574d6ab
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date: Fri Jan 27 20:40:50 2023 +0100
dt-bindings: soc: samsung: exynos-pmu: allow phys as child
The MIPI and DisplayPort phys are actually part of the Power Management
Unit system controller, thus allow them as its children, instead of
specifying as separate device nodes with syscon phandle.
Seems like a similar thing to me - its not a discoverable bus so not
"simple-bus" but we do have a bunch of devices which exist inside of the
CAMSS block.
I'm not very emotionally invested in sub-nodes - what do you think
yourself ?
---
bod
On 16/03/2026 13:01, Bryan O'Donoghue wrote:
> On 16/03/2026 07:29, Krzysztof Kozlowski wrote:
>> On Mon, Mar 16, 2026 at 01:02:01AM +0000, Bryan O'Donoghue wrote:
>>> Add "simple-mfd" as a second compatible string to allow child nodes
>>> within the CAMSS block to probe as individual platform devices.
>>>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> ---
>>> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>>> index 2d1662ef522b7..b5654ef71bd89 100644
>>> --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>>> +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>>> @@ -14,7 +14,11 @@ description:
>>>
>>> properties:
>>> compatible:
>>> - const: qcom,x1e80100-camss
>>> + oneOf:
>>> + - const: qcom,x1e80100-camss
>>> + - items:
>>> + - const: qcom,x1e80100-camss
>>> + - const: simple-mfd
>>>
>>> reg:
>>> maxItems: 17
>>> @@ -191,7 +195,7 @@ examples:
>>> #size-cells = <2>;
>>>
>>> camss: isp@acb7000 {
>>> - compatible = "qcom,x1e80100-camss";
>>> + compatible = "qcom,x1e80100-camss", "simple-mfd";
>>
>> You do not have any children here. And if you checked the DTS, you
>> would see this does not work.
>>
>> Please post complete example and bindings.
>>
>> I suspect that after posting complete picture we will see this is not a
>> simple-mfd device (child depends on parent).
>>
>> Best regards,
>> Krzysztof
>>
>
> This is it:
>
> https://lore.kernel.org/r/20260316-x1e-camss-csi2-phy-dtsi-v2-3-859f3fa55790@linaro.org
That's a DTS branch.
This commit is simply incomplete and noop. Adding simple-mfd without
child makes no sense and no benefits.
It's like adding a local variable in C code without any read/assignment.
>
> Just broke up the series so that drivers/bindings could go through
> linux-media and the dtsi stuff through Bjorn.
>
> I actually got the idea from:
>
> commit fe6a952b567f6a771d087d2e969914f31574d6ab
> Author: Krzysztof Kozlowski <krzk@kernel.org>
> Date: Fri Jan 27 20:40:50 2023 +0100
If you refer to my commits, at least read them. Do you see children
there? Yes. You have none.
Plus trying to get 13 year old legacy device without dtbs_check warnings
is different thing than correcting a recently introduced bindings.
Terrible example to take... And if you find example from 20 years ago,
it will be even worse.
Best regards,
Krzysztof
On 17/03/2026 16:51, Krzysztof Kozlowski wrote:
> On 16/03/2026 13:01, Bryan O'Donoghue wrote:
>> On 16/03/2026 07:29, Krzysztof Kozlowski wrote:
>>> On Mon, Mar 16, 2026 at 01:02:01AM +0000, Bryan O'Donoghue wrote:
>>>> Add "simple-mfd" as a second compatible string to allow child nodes
>>>> within the CAMSS block to probe as individual platform devices.
>>>>
>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>> ---
>>>> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++--
>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>>>> index 2d1662ef522b7..b5654ef71bd89 100644
>>>> --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
>>>> @@ -14,7 +14,11 @@ description:
>>>>
>>>> properties:
>>>> compatible:
>>>> - const: qcom,x1e80100-camss
>>>> + oneOf:
>>>> + - const: qcom,x1e80100-camss
>>>> + - items:
>>>> + - const: qcom,x1e80100-camss
>>>> + - const: simple-mfd
>>>>
>>>> reg:
>>>> maxItems: 17
>>>> @@ -191,7 +195,7 @@ examples:
>>>> #size-cells = <2>;
>>>>
>>>> camss: isp@acb7000 {
>>>> - compatible = "qcom,x1e80100-camss";
>>>> + compatible = "qcom,x1e80100-camss", "simple-mfd";
>>>
>>> You do not have any children here. And if you checked the DTS, you
>>> would see this does not work.
>>>
>>> Please post complete example and bindings.
>>>
>>> I suspect that after posting complete picture we will see this is not a
>>> simple-mfd device (child depends on parent).
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> This is it:
>>
>> https://lore.kernel.org/r/20260316-x1e-camss-csi2-phy-dtsi-v2-3-859f3fa55790@linaro.org
>
> That's a DTS branch.
>
> This commit is simply incomplete and noop. Adding simple-mfd without
> child makes no sense and no benefits.
>
> It's like adding a local variable in C code without any read/assignment.
>
>>
>> Just broke up the series so that drivers/bindings could go through
>> linux-media and the dtsi stuff through Bjorn.
>>
>> I actually got the idea from:
>>
>> commit fe6a952b567f6a771d087d2e969914f31574d6ab
>> Author: Krzysztof Kozlowski <krzk@kernel.org>
>> Date: Fri Jan 27 20:40:50 2023 +0100
>
> If you refer to my commits, at least read them. Do you see children
> there? Yes. You have none.
>
> Plus trying to get 13 year old legacy device without dtbs_check warnings
> is different thing than correcting a recently introduced bindings.
> Terrible example to take... And if you find example from 20 years ago,
> it will be even worse.
>
One more thing, that commit was still correct because it fulfilled the
simple-mfd requirement of lack of dependency on the parent. I do not
believe your code fulfills it. I am pretty sure it does not.
See 2023 and 2022 talks, how to get your schema accepted in less than 10
iterations.
Or please read writing bindings which *describes exactly that case*.
We have it documented, I was speaking about this more than once.
I also mentioned so many times - do not make random changes, just
because you found commit doing something similar. You were cc-ed even on
such remarks from my side, like discussion with Jorge were irrelevant
work was used as arguments, instead of providing actual technical arguments.
https://lore.kernel.org/all/0d381ad0-85d4-43de-a050-3b9ed03bf5d8@kernel.org/
Don't ever reference some irrelevant commits in the past just because
something looks similar. It makes no sense. Devices are completely
different.
Best regards,
Krzysztof
On 17/03/2026 16:00, Krzysztof Kozlowski wrote: >>> I actually got the idea from: >>> >>> commit fe6a952b567f6a771d087d2e969914f31574d6ab >>> Author: Krzysztof Kozlowski<krzk@kernel.org> >>> Date: Fri Jan 27 20:40:50 2023 +0100 >> If you refer to my commits, at least read them. Do you see children >> there? Yes. You have none. >> >> Plus trying to get 13 year old legacy device without dtbs_check warnings >> is different thing than correcting a recently introduced bindings. >> Terrible example to take... And if you find example from 20 years ago, >> it will be even worse. >> > One more thing, that commit was still correct because it fulfilled the > simple-mfd requirement of lack of dependency on the parent. I do not > believe your code fulfills it. I am pretty sure it does not. Yeah I take the logic of that point: CSIPHY here depends on the GDSC, power-domains and clocks we've listed, its not being supplied by any of the other blocks that live inside of the rest. They don't require any resources from the parent and the parent consumes the child phys via phandles. To my mind that fits the criteria you've set of !depends on parent. --- bod
On 3/17/26 5:21 PM, Bryan O'Donoghue wrote: > On 17/03/2026 16:00, Krzysztof Kozlowski wrote: >>>> I actually got the idea from: >>>> >>>> commit fe6a952b567f6a771d087d2e969914f31574d6ab >>>> Author: Krzysztof Kozlowski<krzk@kernel.org> >>>> Date: Fri Jan 27 20:40:50 2023 +0100 >>> If you refer to my commits, at least read them. Do you see children >>> there? Yes. You have none. >>> >>> Plus trying to get 13 year old legacy device without dtbs_check warnings >>> is different thing than correcting a recently introduced bindings. >>> Terrible example to take... And if you find example from 20 years ago, >>> it will be even worse. >>> >> One more thing, that commit was still correct because it fulfilled the >> simple-mfd requirement of lack of dependency on the parent. I do not >> believe your code fulfills it. I am pretty sure it does not. > > Yeah I take the logic of that point: > > CSIPHY here depends on the GDSC, power-domains and clocks we've listed, its not being supplied by any of the other blocks that live inside of the rest. > > They don't require any resources from the parent and the parent consumes the child phys via phandles. > > To my mind that fits the criteria you've set of !depends on parent. FWIW the problem here seems to be the assumption that: "needs to probe child devices" == "must have simple-mfd compatible" You can just add a devm_of_platform_populate() somewhere in CAMSS probe (or do component_device like in drm/msm) Konrad
On 17/03/2026 17:21, Bryan O'Donoghue wrote: > On 17/03/2026 16:00, Krzysztof Kozlowski wrote: >>>> I actually got the idea from: >>>> >>>> commit fe6a952b567f6a771d087d2e969914f31574d6ab >>>> Author: Krzysztof Kozlowski<krzk@kernel.org> >>>> Date: Fri Jan 27 20:40:50 2023 +0100 >>> If you refer to my commits, at least read them. Do you see children >>> there? Yes. You have none. >>> >>> Plus trying to get 13 year old legacy device without dtbs_check warnings >>> is different thing than correcting a recently introduced bindings. >>> Terrible example to take... And if you find example from 20 years ago, >>> it will be even worse. >>> >> One more thing, that commit was still correct because it fulfilled the >> simple-mfd requirement of lack of dependency on the parent. I do not >> believe your code fulfills it. I am pretty sure it does not. > > Yeah I take the logic of that point: > > CSIPHY here depends on the GDSC, power-domains and clocks we've listed, > its not being supplied by any of the other blocks that live inside of > the rest. > > They don't require any resources from the parent and the parent consumes > the child phys via phandles. > > To my mind that fits the criteria you've set of !depends on parent. OK, understood, although I have doubts though, because you have also interconnects and iommus only in the parent. Regardless of that, even if this fits simple-mfd there is simply no benefits of doing that way and your driver should just populate children. Best regards, Krzysztof
On 17/03/2026 16:29, Krzysztof Kozlowski wrote: >> To my mind that fits the criteria you've set of !depends on parent. > OK, understood, although I have doubts though, because you have also > interconnects and iommus only in the parent. > > Regardless of that, even if this fits simple-mfd there is simply no > benefits of doing that way and your driver should just populate children. Right so this is a precursor to what I'd like to do with ICP/BPS and IPE which will define iommus within themselves. Not quite ready for RFC yet but: https://github.com/0xB0D/linux/blob/qcom-laptops-v6.18-rc4-camss-icp-bps-ipe-icp-boots%2Bstats/arch/arm64/boot/dts/qcom/hamoa.dtsi#L5676 Then again if I'm understanding you here, you aren't opposed to sub-nodes its the simple-mfd you're skeptical about. There's nothing stopping us doing platform_register_device() from inside of camss to launch these devices .. --- bod
On 17/03/2026 18:29, Bryan O'Donoghue wrote: > On 17/03/2026 16:29, Krzysztof Kozlowski wrote: > Then again if I'm understanding you here, you aren't opposed to > sub-nodes its the simple-mfd you're skeptical about. Yes. We discussed it more than once, I think, and all arguments you and others presented were in favor of CSI PHY nodes. Thanks for working on this. > > There's nothing stopping us doing platform_register_device() from inside > of camss to launch these devices .. That's a preferred choice, if feasible. Best regards, Krzysztof
On 3/16/26 03:02, Bryan O'Donoghue wrote:
> Add "simple-mfd" as a second compatible string to allow child nodes
> within the CAMSS block to probe as individual platform devices.
Why are there any child nodes representing platform devices?
There is no necessity of it, please use a layout similar to CAMSS CCI
modelling.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> index 2d1662ef522b7..b5654ef71bd89 100644
> --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
> @@ -14,7 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,x1e80100-camss
> + oneOf:
> + - const: qcom,x1e80100-camss
> + - items:
> + - const: qcom,x1e80100-camss
> + - const: simple-mfd
>
> reg:
> maxItems: 17
> @@ -191,7 +195,7 @@ examples:
> #size-cells = <2>;
>
> camss: isp@acb7000 {
> - compatible = "qcom,x1e80100-camss";
> + compatible = "qcom,x1e80100-camss", "simple-mfd";
>
> reg = <0 0x0acb7000 0 0x2000>,
> <0 0x0acb9000 0 0x2000>,
>
--
Best wishes,
Vladimir
On Mon, Mar 16, 2026 at 04:12:35AM +0200, Vladimir Zapolskiy wrote: > On 3/16/26 03:02, Bryan O'Donoghue wrote: > > Add "simple-mfd" as a second compatible string to allow child nodes > > within the CAMSS block to probe as individual platform devices. > > Why are there any child nodes representing platform devices? > > There is no necessity of it, please use a layout similar to CAMSS CCI > modelling. > I'd say it differently. I think, putting CCI device outside of the CAMSS node is a mistake. In the hardware all those devices are a part of the separate block, they share the same NoC fabric, etc. > > > > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > > --- > > Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > -- With best wishes Dmitry
On 3/16/26 04:39, Dmitry Baryshkov wrote: > On Mon, Mar 16, 2026 at 04:12:35AM +0200, Vladimir Zapolskiy wrote: >> On 3/16/26 03:02, Bryan O'Donoghue wrote: >>> Add "simple-mfd" as a second compatible string to allow child nodes >>> within the CAMSS block to probe as individual platform devices. >> >> Why are there any child nodes representing platform devices? >> >> There is no necessity of it, please use a layout similar to CAMSS CCI >> modelling. >> > > I'd say it differently. I think, putting CCI device outside of the CAMSS > node is a mistake. In the hardware all those devices are a part of the > separate block, they share the same NoC fabric, etc. > A simple-mfd model could be considered and pretty often it's usage makes great sense, but likely it's not the case here, when phys are childen of a factual CSI decoder. So far an umbrella/container device has not been considered to the best of my knowledge. OTOH I see no issue in placing phandles to the same exploited resources under multiple device tree nodes, the ultimate goal is to provide a proper hardware description. >>> >>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> >>> --- >>> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> -- Best wishes, Vladimir
© 2016 - 2026 Red Hat, Inc.