From: Jonathan Cameron <jic23@kernel.org>
To: Mani Sadhasivam <manivannanece23@gmail.com>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Linux iio <linux-iio@vger.kernel.org>
Subject: Re: [PATCH] iio:light: Add support for STMicro VL6180 sensor
Date: Mon, 13 Mar 2017 20:13:29 +0000 [thread overview]
Message-ID: <50348765-3a51-0f7b-e243-012890646dd7@kernel.org> (raw)
In-Reply-To: <CANBTL1V5mo7GaeMspo0rUW=B+XEh0A_3X_Sa71n7MQPB1xTztQ@mail.gmail.com>
<snip>
>>>>> + * 2. ALS integration time: 100ms
>>>>> + * 3. ALS gain: 1
>>>>> + */
>>>>> +static int vl6180_init(struct vl6180_data *data)
>>>>> +{
>>>>> + struct i2c_client *client = data->client;
>>>>> + int ret;
>>>>> +
>>>>> + ret = vl6180_read_byte(client, VL6180_MODEL_ID);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + if (ret != VL6180_MODEL_ID_VAL) {
>>>>> + dev_err(&client->dev, "invalid model ID %02x\n", ret);
>>>>> + return -ENODEV;
>>>>> + }
>>>>> +
>>>>> + ret = vl6180_hold(data, true);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + ret = vl6180_read_byte(client, VL6180_OUT_OF_RESET);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + if (ret != 0x01) {
>>>>> + dev_err(&client->dev, "device is not fresh out of reset\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>> Why would it necessarily be fresh out of reset? If it is in some fashion
>>>> supposed to be guaranteed here, please add a comment explaining why.
>>> Device sometimes suffers from false reset condition. Hence, this check ensures that
>>> the device always starts up in the fresh reset condition.
>>> Will add a comment here.
>> Ensures it or checks that it is the case?
>>
>> What about a module remove and reprobe? Should work in that case as well.
> If the device is not fresh out of reset it won't get registered, by
> this way we can prevent
> the device to run in false reset condition.
Remove and probe needs to work if at all possible. It's a common enough
thing to do for one reason or another.
A classic option would be to allow provision of a gpios to manually perform
the reset. Sounds like that's not an option on your board however.
If not, is it possible to get the device to a known state by simply writing
all it's registers? If it's really impossible to continue in this state
we need detailed explanation of why here in comments in the code.
>
> When the module is removed and installed again without resetting the
> device, this check
> will get into act.
>>>>> +
>>>>> + ret = vl6180_write_byte(client, VL6180_INTR_CONFIG,
>>>>> + VL6180_ALS_READY | VL6180_RANGE_READY);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + ret = vl6180_write_word(client, VL6180_ALS_IT, VL6180_ALS_IT_100);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + ret = vl6180_write_byte(client, VL6180_ALS_GAIN, VL6180_ALS_GAIN_1);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + ret = vl6180_write_byte(client, VL6180_OUT_OF_RESET, 0x00);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + return vl6180_hold(data, false);
>>>>> +}
>>>>> +
>>>>> +static int vl6180_probe(struct i2c_client *client,
>>>>> + const struct i2c_device_id *id)
>>>>> +{
>>>>> + struct vl6180_data *data;
>>>>> + struct iio_dev *indio_dev;
>>>>> + int ret;
>>>>> +
>>>>> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>>>>> + if (!indio_dev)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + data = iio_priv(indio_dev);
>>>>> + i2c_set_clientdata(client, indio_dev);
>>>>> + data->client = client;
>>>>> + mutex_init(&data->lock);
>>>>> +
>>>>> + indio_dev->dev.parent = &client->dev;
>>>>> + indio_dev->info = &vl6180_info;
>>>>> + indio_dev->channels = vl6180_channels;
>>>>> + indio_dev->num_channels = ARRAY_SIZE(vl6180_channels);
>>>>> + indio_dev->name = VL6180_DRV_NAME;
>>>>> + indio_dev->modes = INDIO_DIRECT_MODE;
>>>>> +
>>>>> + ret = vl6180_init(data);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>> +
>>>>> + ret = devm_iio_device_register(&client->dev, indio_dev);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>> return devm_iio_device_register directly.
>>>>
>>>> The static checkers will fire on this anyway, but best to fix
>>>> it now.
>>> Ack
>>>>> +
>>>>> + return ret;
>>>>> +}
>>>>> +
>>>>> +static const struct of_device_id vl6180_of_match[] = {
>>>>> + { .compatible = "st,vl6180", },
>>>>> + { },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, vl6180_of_match);
>>>>> +
>>>>> +static const struct i2c_device_id vl6180_id[] = {
>>>>> + { "vl6180", 0 },
>>>>> + { }
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(i2c, vl6180_id);
>>>>> +
>>>>> +static struct i2c_driver vl6180_driver = {
>>>>> + .driver = {
>>>>> + .name = VL6180_DRV_NAME,
>>>>> + .of_match_table = of_match_ptr(vl6180_of_match),
>>>>> + },
>>>>> + .probe = vl6180_probe,
>>>>> + .id_table = vl6180_id,
>>>>> +};
>>>>> +
>>>>> +module_i2c_driver(vl6180_driver);
>>>>> +
>>>>> +MODULE_AUTHOR("Peter Meerwald-Stadler <pmeerw@pmeerw.net>");
>>>>> +MODULE_AUTHOR("Manivannan Sadhasivam <manivannanece23@gmail.com>");
>>>>> +MODULE_DESCRIPTION("STMicro VL6180 ALS and proximity sensor driver");
>>>>> +MODULE_LICENSE("GPL");
>>>>>
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2017-03-13 20:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 18:40 [PATCH] iio:light: Add support for STMicro VL6180 sensor Manivannan Sadhasivam
2017-03-03 7:05 ` Rob Herring
2017-03-03 9:12 ` Peter Meerwald-Stadler
2017-03-03 14:57 ` Mani Sadhasivam
2017-03-04 17:53 ` Jonathan Cameron
2017-03-04 18:37 ` Jonathan Cameron
2017-03-05 13:02 ` Mani Sadhasivam
2017-03-05 13:46 ` Mani Sadhasivam
2017-03-05 13:58 ` Jonathan Cameron
2017-03-06 16:19 ` Mani Sadhasivam
2017-03-13 20:13 ` Jonathan Cameron [this message]
2017-03-16 2:23 ` Mani Sadhasivam
2017-03-17 17:21 ` Peter Meerwald-Stadler
2017-03-17 18:21 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50348765-3a51-0f7b-e243-012890646dd7@kernel.org \
--to=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=manivannanece23@gmail.com \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox