On Fri, 13 Jan 2017, Javier Martinez Canillas wrote:
> If a driver is only used in DT platforms, there's no need to get the
> i2c_device_id as an argument of the probe function. Since this data
> can be get from the matching of_device_id.
>
> There's a temporary .probe_new field in struct
On Fri, 13 Jan 2017, Javier Martinez Canillas wrote:
> If a driver is only used in DT platforms, there's no need to get the
> i2c_device_id as an argument of the probe function. Since this data
> can be get from the matching of_device_id.
>
> There's a temporary .probe_new field in struct
Hi,
On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote:
> If a driver is only used in DT platforms, there's no need to get the
> i2c_device_id as an argument of the probe function. Since this data
> can be get from the matching of_device_id.
>
> There's a temporary .probe_new field in struct
Hi,
On 2017년 01월 13일 22:34, Javier Martinez Canillas wrote:
> If a driver is only used in DT platforms, there's no need to get the
> i2c_device_id as an argument of the probe function. Since this data
> can be get from the matching of_device_id.
>
> There's a temporary .probe_new field in struct
If a driver is only used in DT platforms, there's no need to get the
i2c_device_id as an argument of the probe function. Since this data
can be get from the matching of_device_id.
There's a temporary .probe_new field in struct i2c_driver that can be
used as probe callback for the case when
If a driver is only used in DT platforms, there's no need to get the
i2c_device_id as an argument of the probe function. Since this data
can be get from the matching of_device_id.
There's a temporary .probe_new field in struct i2c_driver that can be
used as probe callback for the case when
6 matches
Mail list logo
