Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 5 Jun 2023 20:01:03 +0530
From:   Raag Jadav <raagjadav@gmail.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] regulator: act8945a: rely on hardware for operating
 mode
Message-ID: <20230605143103.GA3068@pc>
References: <20230605104830.68552-1-raagjadav@gmail.com>
 <04b8fa24-e5a8-4871-a397-f1c0c886449a@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04b8fa24-e5a8-4871-a397-f1c0c886449a@sirena.org.uk>
Precedence: bulk

On Mon, Jun 05, 2023 at 01:16:33PM +0100, Mark Brown wrote:
> On Mon, Jun 05, 2023 at 04:18:29PM +0530, Raag Jadav wrote:
> 
> > Convert ->get_mode() and ->set_mode() hooks to read/write operating mode
> > from/to hardware instead of relying on driver memory.
> 
> Why is this change being made - what is the benefit here?

Original implementation uses drvdata to load/store
operating mode for the regulator.

This change doesn't really add anything new.
It is just to make sure that the driver is in sync
with the current state of affairs in the hardware
instead of relying on locally stored status in the memory.

> > While at it, map fixed-frequency PWM regulators to REGULATOR_MODE_FAST.
> 
> Don't combine multiple changes into a single patch, this just makes
> everything harder to review.

Will split in v2.

Cheers,
Raag