Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932199AbbESKDq (ORCPT ); Tue, 19 May 2015 06:03:46 -0400 Received: from mail-vn0-f44.google.com ([209.85.216.44]:33974 "EHLO mail-vn0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbbESKDm (ORCPT ); Tue, 19 May 2015 06:03:42 -0400 MIME-Version: 1.0 In-Reply-To: <20150519091442.GF14396@lpalcu-linux> References: <1431698778-29462-1-git-send-email-laurentiu.palcu@intel.com> <1431698778-29462-3-git-send-email-laurentiu.palcu@intel.com> <20150519091442.GF14396@lpalcu-linux> Date: Tue, 19 May 2015 19:03:40 +0900 X-Google-Sender-Auth: pTFHXvE0RFmxcqrdDfEV-41Vz2Y Message-ID: Subject: Re: [PATCH 2/2] power_supply: Add support for TI BQ25890 charger chip From: Krzysztof Kozlowski To: Laurentiu Palcu Cc: Krzysztof Kozlowski , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1557 Lines: 40 2015-05-19 18:14 GMT+09:00 Laurentiu Palcu : > Hi Krzysztof, > > On Tue, May 19, 2015 at 05:40:25PM +0900, Krzysztof Kozlowski wrote: >> > + >> > +static int bq25890_chip_reset(struct bq25890_device *bq) >> > +{ >> > + int ret; >> > + >> > + ret = bq25890_field_write(bq, F_REG_RST, 1); >> > + if (ret < 0) >> > + return ret; >> > + >> > + do { >> > + ret = bq25890_field_read(bq, F_REG_RST); >> > + if (ret < 0) >> > + return ret; >> > + >> > + usleep_range(5, 10); >> > + } while (ret == 1); >> >> Is it possible to loop here indefinetely? > According to specifications, this field is "Reset to 0 after register > reset is completed", so I'm trusting the chip will behave as advertised! > :) We could implement a safety mechanism to avoid looping in case the > chip misbehaves but I don't think it's worth it. What do you think? I just prefer to use some retry counter because it would be better to fail the reset instead of being stuck here. The chip may behave correctly but still a bug could exist in the driver. The retry counter won't be much complicated here also. But I do not insist so if you really think it is not worth it then I am fine. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/