On 03/16, Dan Carpenter wrote:
> Generally, it's better to fix the bug in the existing code, and then
> do the cleanup later. That way the fixes can be backported to stable
> kernels more easily.
Hummm... the backport argue make a lot of sense for me. I will generate
a v2 with the bug fixes in th
Generally, it's better to fix the bug in the existing code, and then
do the cleanup later. That way the fixes can be backported to stable
kernels more easily.
I don't know this subsystem very well. Perhaps Jonathan doesn't care
for one reason or another (like maybe he's not going to back port th
On 03/16, Dan Carpenter wrote:
> You're right that there is a bug but this is not the right fix.
>
> The ade7854_i2c_write_reg_32() function returns 6 on success which makes
> no sense. It should be zero or negative error codes. All the write_reg
> functions in drivers/staging/iio/meter/ade7854-
You're right that there is a bug but this is not the right fix.
The ade7854_i2c_write_reg_32() function returns 6 on success which makes
no sense. It should be zero or negative error codes. All the write_reg
functions in drivers/staging/iio/meter/ade7854-i2c.c have the same bug.
Please, fix tha
On 03/15, Dan Carpenter wrote:
> On Wed, Mar 14, 2018 at 03:12:18PM -0300, Rodrigo Siqueira wrote:
> > There is some improper error handling for IRQ and device register. This
> > patch adds a proper verification. The IRQ correction was extracted from
> > John Syne patches.
> >
> > Signed-off-by:
On Wed, Mar 14, 2018 at 03:12:18PM -0300, Rodrigo Siqueira wrote:
> There is some improper error handling for IRQ and device register. This
> patch adds a proper verification. The IRQ correction was extracted from
> John Syne patches.
>
> Signed-off-by: Rodrigo Siqueira
> Signed-off-by: John Syn
