Compatible vs onnn,model at ap1302 binding

Compatible vs onnn,model at ap1302 binding

[Frank Li]

Hi Rob:

There are long discussion about AP1302 support.

https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
previous thread
https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/

Let me summary the key points.

AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
AR0144. AR0144 can work alone, a RFC upstreaming at
https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/

When AR0144 connect to AP1302, it is not 100% transparents for software,
It needs power supplies for it.

The basically there are two methods now.

Method 1 ( Laurent Pinchart purposed ):

use a vendor's specific property like model

camera@3c {
        compatible = "onnn,ap1302";
        ...
        sensors {
                onnn,model = "onnn,ar0144";
                ^^^^
                sensor@0 {
                        reg = <0>;
                        vdd-supply = <&mt6358_vcamd_reg>;
                        vaa-supply = <&mt6358_vcama1_reg>;
                        vddio-supply = <&reg_1p8v_ext>;
        ....


Method 2 ( suggested by Rob at 2021 ):

use compatible string:

camera@3c {
        compatible = "onnn,ap1302";
        ...
        ports {
                port@0 {
                        compatible = "onnn,ar0144";
                        ^^^^
                        reg = <0>;
                        vaa-supply = <&vaa_regulator>;

        ...


               Method 2                              Mathod 1
The same hardware should use the         There are not driver to match onnn,ar0144.
same binding regardless connect to       AR0144 is not visilable from host point.
which bus/devices

                                         compatible means software comaptible, but
                                         there are not driver for it at this case.

reg in difference spi/i2c also have      reg is i2c's address, but here is port or
difference means.                        sensor index.

Similar case for spi and i2c devices.    There are difference set of mandatory properties
                                         when connect to ISP or SoC.


Rob and Laurent Pinchart:

        Need a direction to move forwards!

Frank

Re: Compatible vs onnn,model at ap1302 binding

[Laurent Pinchart]

Hi Frank,

On Mon, Jun 30, 2025 at 02:04:21PM -0400, Frank Li wrote:
> Hi Rob:
> 
> There are long discussion about AP1302 support.
> 
> https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
> previous thread
> https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/
> 
> Let me summary the key points.

Thanks for the summary.

> AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
> AR0144. AR0144 can work alone, a RFC upstreaming at
> https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/
> 
> When AR0144 connect to AP1302, it is not 100% transparents for software,
> It needs power supplies for it.
> 
> The basically there are two methods now.
> 
> Method 1 ( Laurent Pinchart purposed ):
> 
> use a vendor's specific property like model
> 
> camera@3c {
>         compatible = "onnn,ap1302";
>         ...
>         sensors {
>                 onnn,model = "onnn,ar0144";
>                 ^^^^
>                 sensor@0 {
>                         reg = <0>;
>                         vdd-supply = <&mt6358_vcamd_reg>;
>                         vaa-supply = <&mt6358_vcama1_reg>;
>                         vddio-supply = <&reg_1p8v_ext>;
>         ....
> 
> 
> Method 2 ( suggested by Rob at 2021 ):
> 
> use compatible string:
> 
> camera@3c {
>         compatible = "onnn,ap1302";
>         ...
>         ports {
>                 port@0 {
>                         compatible = "onnn,ar0144";
>                         ^^^^
>                         reg = <0>;
>                         vaa-supply = <&vaa_regulator>;
> 
>         ...
> 
> 
>                Method 2                              Mathod 1
> The same hardware should use the         There are not driver to match onnn,ar0144.
> same binding regardless connect to       AR0144 is not visilable from host point.
> which bus/devices
> 
>                                          compatible means software comaptible, but
>                                          there are not driver for it at this case.
> 
> reg in difference spi/i2c also have      reg is i2c's address, but here is port or
> difference means.                        sensor index.
> 
> Similar case for spi and i2c devices.    There are difference set of mandatory properties
>                                          when connect to ISP or SoC.
> 
> 
> Rob and Laurent Pinchart:
> 
>         Need a direction to move forwards!

There are two things to consider here. One is the DT property we want to
use to identify the sensor model. It can be argued that the "compatible"
property is widely used for this purpose. This is true, but the
"compatible" property is meant to indicate compatibility from an
operating system software point of view (regardless of which operating
system is used). As a result, it serves as the central piece around
which drivers are bound to devices, and therefore is also used to match
DT schemas for the device.

What we need here is to identify the sensor model, first and foremost to
load the corresponding AP1302 firmware, and to know which power supplies
the AP1302 driver needs to control for the sensor. Note that it would be
entirely feasible for the sensor power supplies to be connected to GPIOs
of the AP1302 and entirely controlled by the AP1302 firmware, but on
some designs those power supplies are connected to GPIOs of the main
SoC, and therefore need to be controlled by the AP1302 driver.

While I think a custom property is better, I could live with
"compatible" *iif* it does not imply at the corresponding DT schema for
the sensor is pulled in. The DT binding for the sensor when controlled
from the main SoC describe the properties of the sensor that are
required for that use case, and those only overlap slightly with the
properties of the sensor needed by the AP1302. Using "compatible" in
such a case would in my opinion be misleading as it would imply
compatibility with the sensor DT binding.

-- 
Regards,

Laurent Pinchart

Re: Compatible vs onnn,model at ap1302 binding

[Laurent Pinchart]

Hi Frank,

On Mon, Jun 30, 2025 at 02:04:21PM -0400, Frank Li wrote:
> Hi Rob:
> 
> There are long discussion about AP1302 support.
> 
> https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
> previous thread
> https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/
> 
> Let me summary the key points.

Thanks for the summary.

> AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
> AR0144. AR0144 can work alone, a RFC upstreaming at
> https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/
> 
> When AR0144 connect to AP1302, it is not 100% transparents for software,
> It needs power supplies for it.
> 
> The basically there are two methods now.
> 
> Method 1 ( Laurent Pinchart purposed ):
> 
> use a vendor's specific property like model
> 
> camera@3c {
>         compatible = "onnn,ap1302";
>         ...
>         sensors {
>                 onnn,model = "onnn,ar0144";
>                 ^^^^
>                 sensor@0 {
>                         reg = <0>;
>                         vdd-supply = <&mt6358_vcamd_reg>;
>                         vaa-supply = <&mt6358_vcama1_reg>;
>                         vddio-supply = <&reg_1p8v_ext>;
>         ....
> 
> 
> Method 2 ( suggested by Rob at 2021 ):
> 
> use compatible string:
> 
> camera@3c {
>         compatible = "onnn,ap1302";
>         ...
>         ports {
>                 port@0 {
>                         compatible = "onnn,ar0144";
>                         ^^^^
>                         reg = <0>;
>                         vaa-supply = <&vaa_regulator>;
> 
>         ...
> 
> 
>                Method 2                              Mathod 1
> The same hardware should use the         There are not driver to match onnn,ar0144.
> same binding regardless connect to       AR0144 is not visilable from host point.
> which bus/devices
> 
>                                          compatible means software comaptible, but
>                                          there are not driver for it at this case.
> 
> reg in difference spi/i2c also have      reg is i2c's address, but here is port or
> difference means.                        sensor index.
> 
> Similar case for spi and i2c devices.    There are difference set of mandatory properties
>                                          when connect to ISP or SoC.
> 
> 
> Rob and Laurent Pinchart:
> 
>         Need a direction to move forwards!

There are two things to consider here. One is the DT property we want to
use to identify the sensor model. It can be argued that the "compatible"
property is widely used for this purpose. This is true, but the
"compatible" property is meant to indicate compatibility from an
operating system software point of view (regardless of which operating
system is used). As a result, it serves as the central piece around
which drivers are bound to devices, and therefore is also used to match
DT schemas for the device.

What we need here is to identify the sensor model, first and foremost to
load the corresponding AP1302 firmware, and to know which power supplies
the AP1302 driver needs to control for the sensor. Note that it would be
entirely feasible for the sensor power supplies to be connected to GPIOs
of the AP1302 and entirely controlled by the AP1302 firmware, but on
some designs those power supplies are connected to GPIOs of the main
SoC, and therefore need to be controlled by the AP1302 driver.

While I think a custom property is better, I could live with
"compatible" *iif* it does not imply at the corresponding DT schema for
the sensor is pulled in. The DT binding for the sensor when controlled
from the main SoC describe the properties of the sensor that are
required for that use case, and those only overlap slightly with the
properties of the sensor needed by the AP1302. Using "compatible" in
such a case would in my opinion be misleading as it would imply
compatibility with the sensor DT binding.

-- 
Regards,

Laurent Pinchart

Re: Compatible vs onnn,model at ap1302 binding

[Rob Herring]

On Mon, Jun 30, 2025 at 09:30:41PM +0300, Laurent Pinchart wrote:
> Hi Frank,
> 
> On Mon, Jun 30, 2025 at 02:04:21PM -0400, Frank Li wrote:
> > Hi Rob:
> > 
> > There are long discussion about AP1302 support.
> > 
> > https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
> > previous thread
> > https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/
> > 
> > Let me summary the key points.
> 
> Thanks for the summary.
> 
> > AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
> > AR0144. AR0144 can work alone, a RFC upstreaming at
> > https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/
> > 
> > When AR0144 connect to AP1302, it is not 100% transparents for software,
> > It needs power supplies for it.
> > 
> > The basically there are two methods now.
> > 
> > Method 1 ( Laurent Pinchart purposed ):
> > 
> > use a vendor's specific property like model
> > 
> > camera@3c {
> >         compatible = "onnn,ap1302";
> >         ...
> >         sensors {
> >                 onnn,model = "onnn,ar0144";
> >                 ^^^^

Why is this outside the sensor node?

> >                 sensor@0 {
> >                         reg = <0>;
> >                         vdd-supply = <&mt6358_vcamd_reg>;
> >                         vaa-supply = <&mt6358_vcama1_reg>;
> >                         vddio-supply = <&reg_1p8v_ext>;
> >         ....
> > 
> > 
> > Method 2 ( suggested by Rob at 2021 ):
> > 
> > use compatible string:
> > 
> > camera@3c {
> >         compatible = "onnn,ap1302";
> >         ...
> >         ports {
> >                 port@0 {
> >                         compatible = "onnn,ar0144";
> >                         ^^^^
> >                         reg = <0>;
> >                         vaa-supply = <&vaa_regulator>;

Please don't hijack the graph binding (ports and port nodes). 

> > 
> >         ...
> > 
> > 
> >                Method 2                              Mathod 1
> > The same hardware should use the         There are not driver to match onnn,ar0144.
> > same binding regardless connect to       AR0144 is not visilable from host point.
> > which bus/devices
> > 
> >                                          compatible means software comaptible, but
> >                                          there are not driver for it at this case.
> > 
> > reg in difference spi/i2c also have      reg is i2c's address, but here is port or
> > difference means.                        sensor index.
> > 
> > Similar case for spi and i2c devices.    There are difference set of mandatory properties
> >                                          when connect to ISP or SoC.
> > 
> > 
> > Rob and Laurent Pinchart:
> > 
> >         Need a direction to move forwards!
> 
> There are two things to consider here. One is the DT property we want to
> use to identify the sensor model. It can be argued that the "compatible"
> property is widely used for this purpose. This is true, but the
> "compatible" property is meant to indicate compatibility from an
> operating system software point of view (regardless of which operating
> system is used). As a result, it serves as the central piece around
> which drivers are bound to devices, and therefore is also used to match
> DT schemas for the device.
> 
> What we need here is to identify the sensor model, first and foremost to
> load the corresponding AP1302 firmware, and to know which power supplies
> the AP1302 driver needs to control for the sensor. Note that it would be
> entirely feasible for the sensor power supplies to be connected to GPIOs
> of the AP1302 and entirely controlled by the AP1302 firmware, but on
> some designs those power supplies are connected to GPIOs of the main
> SoC, and therefore need to be controlled by the AP1302 driver.
> 
> While I think a custom property is better, I could live with
> "compatible" *iif* it does not imply at the corresponding DT schema for
> the sensor is pulled in. The DT binding for the sensor when controlled
> from the main SoC describe the properties of the sensor that are
> required for that use case, and those only overlap slightly with the
> properties of the sensor needed by the AP1302. Using "compatible" in
> such a case would in my opinion be misleading as it would imply
> compatibility with the sensor DT binding.

Why not a new compatible (e.g. onnn,ar0144-isp)? Seems to me there would 
be at least some overlap. If there are supplies, then the names should 
be the same, right?

If you really want onnn,model, then that's fine. Probably there's not 
enough different sensors for me to really care...

Rob

Re: Compatible vs onnn,model at ap1302 binding

[Laurent Pinchart]

Hi Rob,

On Tue, Jul 15, 2025 at 02:54:04PM -0500, Rob Herring wrote:
> On Mon, Jun 30, 2025 at 09:30:41PM +0300, Laurent Pinchart wrote:
> > On Mon, Jun 30, 2025 at 02:04:21PM -0400, Frank Li wrote:
> > > Hi Rob:
> > > 
> > > There are long discussion about AP1302 support.
> > > 
> > > https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
> > > previous thread
> > > https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/
> > > 
> > > Let me summary the key points.
> > 
> > Thanks for the summary.
> > 
> > > AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
> > > AR0144. AR0144 can work alone, a RFC upstreaming at
> > > https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/
> > > 
> > > When AR0144 connect to AP1302, it is not 100% transparents for software,
> > > It needs power supplies for it.
> > > 
> > > The basically there are two methods now.
> > > 
> > > Method 1 ( Laurent Pinchart purposed ):
> > > 
> > > use a vendor's specific property like model
> > > 
> > > camera@3c {
> > >         compatible = "onnn,ap1302";
> > >         ...
> > >         sensors {
> > >                 onnn,model = "onnn,ar0144";
> > >                 ^^^^
> 
> Why is this outside the sensor node?

Because when the AP1302 is used with two sensors, it requires both of
them to be identical. The property could go to the sensor nodes, but it
would then be redundant, and would make it possible to write incorrect
DT. When designing APIs, one of my goals is to make them difficult to
use incorrectly, so I think the property is better placed here.

This being said, it won't cause lots of issues if we moved the property
to the sensor nodes. I think it's suboptimal with no benefit, but if
that's the only contention point, I can compromise :-)

> > >                 sensor@0 {
> > >                         reg = <0>;
> > >                         vdd-supply = <&mt6358_vcamd_reg>;
> > >                         vaa-supply = <&mt6358_vcama1_reg>;
> > >                         vddio-supply = <&reg_1p8v_ext>;
> > >         ....
> > > 
> > > 
> > > Method 2 ( suggested by Rob at 2021 ):
> > > 
> > > use compatible string:
> > > 
> > > camera@3c {
> > >         compatible = "onnn,ap1302";
> > >         ...
> > >         ports {
> > >                 port@0 {
> > >                         compatible = "onnn,ar0144";
> > >                         ^^^^
> > >                         reg = <0>;
> > >                         vaa-supply = <&vaa_regulator>;
> 
> Please don't hijack the graph binding (ports and port nodes). 
> 
> > > 
> > >         ...
> > > 
> > > 
> > >                Method 2                              Mathod 1
> > > The same hardware should use the         There are not driver to match onnn,ar0144.
> > > same binding regardless connect to       AR0144 is not visilable from host point.
> > > which bus/devices
> > > 
> > >                                          compatible means software comaptible, but
> > >                                          there are not driver for it at this case.
> > > 
> > > reg in difference spi/i2c also have      reg is i2c's address, but here is port or
> > > difference means.                        sensor index.
> > > 
> > > Similar case for spi and i2c devices.    There are difference set of mandatory properties
> > >                                          when connect to ISP or SoC.
> > > 
> > > 
> > > Rob and Laurent Pinchart:
> > > 
> > >         Need a direction to move forwards!
> > 
> > There are two things to consider here. One is the DT property we want to
> > use to identify the sensor model. It can be argued that the "compatible"
> > property is widely used for this purpose. This is true, but the
> > "compatible" property is meant to indicate compatibility from an
> > operating system software point of view (regardless of which operating
> > system is used). As a result, it serves as the central piece around
> > which drivers are bound to devices, and therefore is also used to match
> > DT schemas for the device.
> > 
> > What we need here is to identify the sensor model, first and foremost to
> > load the corresponding AP1302 firmware, and to know which power supplies
> > the AP1302 driver needs to control for the sensor. Note that it would be
> > entirely feasible for the sensor power supplies to be connected to GPIOs
> > of the AP1302 and entirely controlled by the AP1302 firmware, but on
> > some designs those power supplies are connected to GPIOs of the main
> > SoC, and therefore need to be controlled by the AP1302 driver.
> > 
> > While I think a custom property is better, I could live with
> > "compatible" *iif* it does not imply at the corresponding DT schema for
> > the sensor is pulled in. The DT binding for the sensor when controlled
> > from the main SoC describe the properties of the sensor that are
> > required for that use case, and those only overlap slightly with the
> > properties of the sensor needed by the AP1302. Using "compatible" in
> > such a case would in my opinion be misleading as it would imply
> > compatibility with the sensor DT binding.
> 
> Why not a new compatible (e.g. onnn,ar0144-isp)? Seems to me there would 
> be at least some overlap. If there are supplies, then the names should 
> be the same, right?

Would that be a top-level compatible for the AP1302, or am I
misunderstanding something ? Or maybe a compatible = "onnn,ar0144-isp"
for the sensor node, not the AP1302 ? The AR0144 could be used with
other ISPs (I recently upstreamed support for the THP7312 external ISP
from THine for instance, which could work with the AR0144 from onsemi),
so the "compatible" property in the sensor node needs to be evaluated in
the context of its parent, not in isolation. I think that departs enough
from the compatible model to be better served by a different property,
instead of introducing usage of "compatible" with a semantics (both from
the point of view of the OS, and from the point of view of the DT
binding validator).

> If you really want onnn,model, then that's fine. Probably there's not 
> enough different sensors for me to really care...

The AP1302 is typically used with a subset of the onsemi sensors in my
experience, so I indeed don't think we'll have scaling issues.

-- 
Regards,

Laurent Pinchart

Re: Compatible vs onnn,model at ap1302 binding

[Rob Herring]

On Tue, Jul 15, 2025 at 4:36 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Rob,
>
> On Tue, Jul 15, 2025 at 02:54:04PM -0500, Rob Herring wrote:
> > On Mon, Jun 30, 2025 at 09:30:41PM +0300, Laurent Pinchart wrote:
> > > On Mon, Jun 30, 2025 at 02:04:21PM -0400, Frank Li wrote:
> > > > Hi Rob:
> > > >
> > > > There are long discussion about AP1302 support.
> > > >
> > > > https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
> > > > previous thread
> > > > https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/
> > > >
> > > > Let me summary the key points.
> > >
> > > Thanks for the summary.
> > >
> > > > AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
> > > > AR0144. AR0144 can work alone, a RFC upstreaming at
> > > > https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/
> > > >
> > > > When AR0144 connect to AP1302, it is not 100% transparents for software,
> > > > It needs power supplies for it.
> > > >
> > > > The basically there are two methods now.
> > > >
> > > > Method 1 ( Laurent Pinchart purposed ):
> > > >
> > > > use a vendor's specific property like model
> > > >
> > > > camera@3c {
> > > >         compatible = "onnn,ap1302";
> > > >         ...
> > > >         sensors {
> > > >                 onnn,model = "onnn,ar0144";
> > > >                 ^^^^
> >
> > Why is this outside the sensor node?
>
> Because when the AP1302 is used with two sensors, it requires both of
> them to be identical. The property could go to the sensor nodes, but it
> would then be redundant, and would make it possible to write incorrect
> DT. When designing APIs, one of my goals is to make them difficult to
> use incorrectly, so I think the property is better placed here.

Okay, makes sense.

> This being said, it won't cause lots of issues if we moved the property
> to the sensor nodes. I think it's suboptimal with no benefit, but if
> that's the only contention point, I can compromise :-)
>
> > > >                 sensor@0 {
> > > >                         reg = <0>;
> > > >                         vdd-supply = <&mt6358_vcamd_reg>;
> > > >                         vaa-supply = <&mt6358_vcama1_reg>;
> > > >                         vddio-supply = <&reg_1p8v_ext>;
> > > >         ....
> > > >
> > > >
> > > > Method 2 ( suggested by Rob at 2021 ):
> > > >
> > > > use compatible string:
> > > >
> > > > camera@3c {
> > > >         compatible = "onnn,ap1302";
> > > >         ...
> > > >         ports {
> > > >                 port@0 {
> > > >                         compatible = "onnn,ar0144";
> > > >                         ^^^^
> > > >                         reg = <0>;
> > > >                         vaa-supply = <&vaa_regulator>;
> >
> > Please don't hijack the graph binding (ports and port nodes).
> >
> > > >
> > > >         ...
> > > >
> > > >
> > > >                Method 2                              Mathod 1
> > > > The same hardware should use the         There are not driver to match onnn,ar0144.
> > > > same binding regardless connect to       AR0144 is not visilable from host point.
> > > > which bus/devices
> > > >
> > > >                                          compatible means software comaptible, but
> > > >                                          there are not driver for it at this case.
> > > >
> > > > reg in difference spi/i2c also have      reg is i2c's address, but here is port or
> > > > difference means.                        sensor index.
> > > >
> > > > Similar case for spi and i2c devices.    There are difference set of mandatory properties
> > > >                                          when connect to ISP or SoC.
> > > >
> > > >
> > > > Rob and Laurent Pinchart:
> > > >
> > > >         Need a direction to move forwards!
> > >
> > > There are two things to consider here. One is the DT property we want to
> > > use to identify the sensor model. It can be argued that the "compatible"
> > > property is widely used for this purpose. This is true, but the
> > > "compatible" property is meant to indicate compatibility from an
> > > operating system software point of view (regardless of which operating
> > > system is used). As a result, it serves as the central piece around
> > > which drivers are bound to devices, and therefore is also used to match
> > > DT schemas for the device.
> > >
> > > What we need here is to identify the sensor model, first and foremost to
> > > load the corresponding AP1302 firmware, and to know which power supplies
> > > the AP1302 driver needs to control for the sensor. Note that it would be
> > > entirely feasible for the sensor power supplies to be connected to GPIOs
> > > of the AP1302 and entirely controlled by the AP1302 firmware, but on
> > > some designs those power supplies are connected to GPIOs of the main
> > > SoC, and therefore need to be controlled by the AP1302 driver.
> > >
> > > While I think a custom property is better, I could live with
> > > "compatible" *iif* it does not imply at the corresponding DT schema for
> > > the sensor is pulled in. The DT binding for the sensor when controlled
> > > from the main SoC describe the properties of the sensor that are
> > > required for that use case, and those only overlap slightly with the
> > > properties of the sensor needed by the AP1302. Using "compatible" in
> > > such a case would in my opinion be misleading as it would imply
> > > compatibility with the sensor DT binding.
> >
> > Why not a new compatible (e.g. onnn,ar0144-isp)? Seems to me there would
> > be at least some overlap. If there are supplies, then the names should
> > be the same, right?
>
> Would that be a top-level compatible for the AP1302, or am I
> misunderstanding something ? Or maybe a compatible = "onnn,ar0144-isp"
> for the sensor node, not the AP1302 ? The AR0144 could be used with
> other ISPs (I recently upstreamed support for the THP7312 external ISP
> from THine for instance, which could work with the AR0144 from onsemi),
> so the "compatible" property in the sensor node needs to be evaluated in
> the context of its parent, not in isolation. I think that departs enough
> from the compatible model to be better served by a different property,
> instead of introducing usage of "compatible" with a semantics (both from
> the point of view of the OS, and from the point of view of the DT
> binding validator).
>
> > If you really want onnn,model, then that's fine. Probably there's not
> > enough different sensors for me to really care...
>
> The AP1302 is typically used with a subset of the onsemi sensors in my
> experience, so I indeed don't think we'll have scaling issues.

Okay, then stick with onnn,model.

Rob