From: Jonathan Cameron <jic23@kernel.org>
To: Marcin Niestroj <m.niestroj@grinn-global.com>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Daniel Baluta <daniel.baluta@intel.com>,
Gregor Boirie <gregor.boirie@parrot.com>,
Sanchayan Maity <maitysanchayan@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/2] iio: bmi160: Support hardware fifo
Date: Sat, 19 Nov 2016 12:43:47 +0000 [thread overview]
Message-ID: <cf833286-dbb5-3362-a117-be0563edee91@kernel.org> (raw)
In-Reply-To: <584172c4-10ea-f7a6-56ea-062441d8e5d4@grinn-global.com>
On 14/11/16 17:30, Marcin Niestroj wrote:
> On 12.11.2016 16:55, Jonathan Cameron wrote:
>> On 09/11/16 17:16, Marcin Niestroj wrote:
>>> On 09.11.2016 15:16, Marcin Niestroj wrote:
>>>> Hi,
>>>> Thanks for review, below are my comments.
>>>>
>>>> On 03.11.2016 13:09, Peter Meerwald-Stadler wrote:
>>>>>
>>>>>> This patch was developed primarily based on bmc150_accel hardware fifo
>>>>>> implementation.
>>>>>
>>>>> parts of the patch are cleanup and bugfixing; should be separate?
>>>>>
>>>>> more comments below
>>>>>
>>>>>> IRQ handler was added, which for now is responsible only for handling
>>>>>> watermark interrupts. The BMI160 chip has two interrupt outputs. By
>>>>>> default INT is considered to be connected. If INT2 is used instead, the
>>>>>> interrupt-names device-tree property can be used to specify that.
>>>>>>
>>>>>> Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
>>>
>>> <snip>
>>>
>>>>>> @@ -574,8 +1114,11 @@ int bmi160_core_probe(struct device *dev,
>>>>>> struct regmap *regmap,
>>>>>>
>>>>>> data = iio_priv(indio_dev);
>>>>>> dev_set_drvdata(dev, indio_dev);
>>>>>> + data->irq = irq;
>>>>>> data->regmap = regmap;
>>>>>>
>>>>>> + mutex_init(&data->mutex);
>>>>>> +
>>>>>> ret = bmi160_chip_init(data, use_spi);
>>>>>> if (ret < 0)
>>>>>> return ret;
>>>>>> @@ -591,10 +1134,50 @@ int bmi160_core_probe(struct device *dev,
>>>>>> struct regmap *regmap,
>>>>>> indio_dev->info = &bmi160_info;
>>>>>>
>>>>>> ret = iio_triggered_buffer_setup(indio_dev, NULL,
>>>>>> - bmi160_trigger_handler, NULL);
>>>>>> + bmi160_trigger_handler,
>>>>>> + &bmi160_buffer_ops);
>>>>>> if (ret < 0)
>>>>>> goto uninit;
>>>>>>
>>>>>> + if (data->irq > 0) {
>>>>>> + /* Check which interrupt pin is connected to our board */
>>>>>> + irq2 = of_irq_get_byname(dev->of_node, "INT2");
>>>>>> + if (irq2 == data->irq) {
>>>>>> + dev_dbg(dev, "Using interrupt line INT2\n");
>>>>>> + data->irq_data = &bmi160_irq2_data;
>>>>>> + } else {
>>>>>> + dev_dbg(dev, "Using interrupt line INT1\n");
>>>>>> + data->irq_data = &bmi160_irq1_data;
>>>>>> + }
>>>>>> +
>>>>>> + ret = devm_request_threaded_irq(dev,
>>>>>> + data->irq,
>>>>>> + bmi160_irq_handler,
>>>>>> + bmi160_irq_thread_handler,
>>>>>> + IRQF_ONESHOT,
>>>>>> + BMI160_IRQ_NAME,
>>>>>> + indio_dev);
>>>>>> + if (ret)
>>>>>> + return ret;
>>>
>>> I just noticed, that there should be a "goto buffer_cleanup" instead.
>>>
>>>>>> +
>>>>>> + ret = bmi160_enable_irq(data);
>>>>>> + if (ret < 0)
>>>>>> + goto buffer_cleanup;
>>>>>> +
>>>>>> + if (block_supported) {
>>>>>> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
>>>>>> + indio_dev->info = &bmi160_info_fifo;
>>>>>> + indio_dev->buffer->attrs = bmi160_fifo_attributes;
>>>>>> + data->fifo_buffer = devm_kmalloc(dev,
>>>>>> + BMI160_FIFO_LENGTH,
>>>>>> + GFP_KERNEL);
>>>>>> + if (!data->fifo_buffer) {
>>>>>> + ret = -ENOMEM;
>>>>>
>>>>> need to disable irq on failure?
>>>>
>>>> Yes, I missed that.
>>>
>>> I am just wondering now if it is really neccessary. bmi160_enable_irq()
>>> is just enabling IRQ output on INT1 or INT2 depending on device-tree.
>>> This alone will not trigger interrupts, as all should be masked at this
>>> stage.
>> You should always unwind everything in error paths as it makes them
>> 'obviously' correct rather than subject to subtle bugs.
>
> Ok. And what about issuing a softreset of the device? This should
> revert all registers to defaults.
That's fine, but best to add a comment saying what it's effects are if they
can be specifically listed (such as 'will disable the interrupt'.)
Again makes it 'obviously correct' which I like as a reviewer!
Jonathan
>
>>>
>>>>
>>>>>
>>>>>> + goto buffer_cleanup;
>>>>>> + }
>>>>>> + }
>>>>>> + }
>>>>>> +
>>>>>> ret = iio_device_register(indio_dev);
>>>>>> if (ret < 0)
>>>>>> goto buffer_cleanup;
>>>>>> diff --git a/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>>> b/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>>> index 07a179d..aa63f89 100644
>>>>>> --- a/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>>> +++ b/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>>> @@ -23,6 +23,10 @@ static int bmi160_i2c_probe(struct i2c_client
>>>>>> *client,
>>>>>> {
>>>>>> struct regmap *regmap;
>>>>>> const char *name = NULL;
>>>>>> + bool block_supported =
>>>>>> + i2c_check_functionality(client->adapter, I2C_FUNC_I2C) ||
>>>>>> + i2c_check_functionality(client->adapter,
>>>>>> + I2C_FUNC_SMBUS_READ_I2C_BLOCK);
>>>>>>
>>>>>> regmap = devm_regmap_init_i2c(client, &bmi160_regmap_config);
>>>>>> if (IS_ERR(regmap)) {
>>>>>> @@ -34,7 +38,8 @@ static int bmi160_i2c_probe(struct i2c_client *client,
>>>>>> if (id)
>>>>>> name = id->name;
>>>>>>
>>>>>> - return bmi160_core_probe(&client->dev, regmap, name, false);
>>>>>> + return bmi160_core_probe(&client->dev, regmap, name, client->irq,
>>>>>> + false, block_supported);
>>>>>> }
>>>>>>
>>>>>> static int bmi160_i2c_remove(struct i2c_client *client)
>>>>>> diff --git a/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>>> b/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>>> index 1ec8b12..9b57fbe 100644
>>>>>> --- a/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>>> +++ b/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>>> @@ -25,7 +25,8 @@ static int bmi160_spi_probe(struct spi_device *spi)
>>>>>> (int)PTR_ERR(regmap));
>>>>>> return PTR_ERR(regmap);
>>>>>> }
>>>>>> - return bmi160_core_probe(&spi->dev, regmap, id->name, true);
>>>>>> + return bmi160_core_probe(&spi->dev, regmap, id->name, spi->irq,
>>>>>> + true, true);
>>>>>> }
>>>>>>
>>>>>> static int bmi160_spi_remove(struct spi_device *spi)
>>>>>>
>>>>>
>>>>
>>>
>>
>
next prev parent reply other threads:[~2016-11-19 12:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 11:25 [PATCH 1/2] iio: bmi160: Support hardware fifo Marcin Niestroj
2016-11-03 11:25 ` Marcin Niestroj
2016-11-03 11:25 ` [PATCH 2/2] Documentation: DT: Add bmi160 imu binding Marcin Niestroj
2016-11-03 11:25 ` Marcin Niestroj
2016-11-06 12:41 ` Jonathan Cameron
2016-11-06 12:41 ` Jonathan Cameron
2016-11-09 15:18 ` Marcin Niestroj
2016-11-09 15:18 ` Marcin Niestroj
2016-11-12 13:15 ` Jonathan Cameron
2016-11-12 13:15 ` Jonathan Cameron
2016-11-10 18:55 ` Rob Herring
2016-11-10 18:55 ` Rob Herring
2016-11-03 12:09 ` [PATCH 1/2] iio: bmi160: Support hardware fifo Peter Meerwald-Stadler
2016-11-09 14:16 ` Marcin Niestroj
2016-11-09 17:16 ` Marcin Niestroj
2016-11-12 15:55 ` Jonathan Cameron
2016-11-14 17:30 ` Marcin Niestroj
2016-11-19 12:43 ` Jonathan Cameron [this message]
2016-11-12 15:53 ` Jonathan Cameron
2016-11-06 12:35 ` Jonathan Cameron
2016-11-06 12:35 ` Jonathan Cameron
2016-11-09 14:52 ` Marcin Niestroj
2016-11-09 14:52 ` Marcin Niestroj
2016-11-12 13:13 ` Jonathan Cameron
2016-11-12 13:13 ` 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=cf833286-dbb5-3362-a117-be0563edee91@kernel.org \
--to=jic23@kernel.org \
--cc=daniel.baluta@intel.com \
--cc=gregor.boirie@parrot.com \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=m.niestroj@grinn-global.com \
--cc=maitysanchayan@gmail.com \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.