[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Laurent Pinchart]

Hi Tomi,

On Monday 14 Nov 2016 13:16:49 Tomi Valkeinen wrote:
> On 14/11/16 13:10, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> >> On 11/03/16 19:46, Laurent Pinchart wrote:
> >>>> +Required properties:
> >>>>> +	- compatible: "ti,tfp410"
> >>> 
> >>> The device is an I2C slave, it should have a reg property. Given that
> >>> the chip can be used without being controlled through I2C, the reg
> >>> property should be optional. You should document this clearly, and
> >>> explain how the DT node can be instantiated as a child of an I2C
> >>> controller when the I2C interface is used, or in other parts of the
> >>> device tree otherwise.
> >> 
> >> Shouldn't I have two different compatible strings if want to make both
> >> platform driver probe and i2c client probe to work?
> > 
> > I don't think so, it's still the same chip.
> > 
> >> Or can it be done with single compatible string? Would you know of an
> >> example of such a driver?
> > 
> > You will need to register both a i2c_driver and a platform_driver in the
> > tfp410 driver. Both will advertise the same compatible string. As you'll
> > have two probe functions, it should be easy to handle the differences
> > between the
>
> If you have the same compatible string, won't both probes trigger? If
> so, how does, e.g., the platform driver know this is actually i2c case,
> and bail out? And if both probes don't trigger, why not? How does the
> device probing machinery know that this DT node is actually an i2c node,
> not a platform device node?

The driver for the bus on which the device is sitting is responsible for 
instantiating a struct device corresponding to the bus type, and for binding 
the corresponding bus drivers. This will be a struct i2c_client for I2C buses, 
and a struct platform_device for platform buses. Only the corresponding driver 
type will be probed.

-- 
Regards,

Laurent Pinchart