Hi, thank you for the comment.
I understood the naming conventions you mentioned,
and I'll update them in the next version.
>> diff --git a/drivers/media/dvb-core/dvb_i2c.c
>> b/drivers/media/dvb-core/dvb_i2c.c
>> new file mode 100644
>> index 0000000..4ea4e5e
>> --- /dev/null
>> +++ b/drivers/media/dvb-core/dvb_i2c.c
....
>> +static struct i2c_client *
>> +dvb_i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info *info,
>> + const unsigned short *probe_addrs)
>> +{
>> + struct i2c_client *cl;
>> +
>> + request_module(I2C_MODULE_PREFIX "%s", info->type);
>> + /* Create the i2c client */
>> + if (info->addr == 0 && probe_addrs)
>> + cl = i2c_new_probed_device(adap, info, probe_addrs, NULL);
>> + else
>> + cl = i2c_new_device(adap, info);
>> + if (!cl || !cl->dev.driver)
>> + return NULL;
>> + return cl;
>
> The best would be to also register the device with the media controller,
> if CONFIG_MEDIA_CONTROLLER is defined, just like v4l2_i2c_subdev_init()
> does.
I'll comment to your patch on this.
> I would also try to use similar names for the function calls to the ones
> that the v4l subsystem uses for subdevices.
So the name should be dvb_i2c_new_subdev()?
I am a bit worried that it would be rather confusing because
this func is different from v4l2_i2c_new_subdev() in that
it does not return "struct dvb_frontend *", requires info.platform_data
parameter,
and is a static/internal function.
One more thing that I'm wondering about is whether we should add
fe->demod_i2c_bus
to support tuner devices on a (dedicated) i2c bus hosted on a demod device.
I guess that this structure is pretty common (to reduce noise),
and this removes i2c_adapter from "out" structure and
confines the usage of "out" structure to just device-specific ones.
--
akihiro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
