On Mon, 2020-11-30 at 19:13 +0800, Ikjoon Jang wrote: > On Wed, Sep 30, 2020 at 10:21:59AM +0800, Crystal Guo wrote: > > Force the write operation in case the read already happens > > to return the correct value. > > > > Signed-off-by: Crystal Guo <crystal.guo@xxxxxxxxxxxx> > > --- > > drivers/reset/reset-ti-syscon.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c > > index 5d1f8306cd4f..c34394f1e9e2 100644 > > --- a/drivers/reset/reset-ti-syscon.c > > +++ b/drivers/reset/reset-ti-syscon.c > > @@ -97,7 +97,7 @@ static int ti_syscon_reset_assert(struct reset_controller_dev *rcdev, > > mask = BIT(control->assert_bit); > > value = (control->flags & ASSERT_SET) ? mask : 0x0; > > > > - return regmap_update_bits(data->regmap, control->assert_offset, mask, value); > > + return regmap_write_bits(data->regmap, control->assert_offset, mask, value); > > } > > I don't think there are no reset controllers with cached regmap, > thus I don't think this is needed. > Are there any specific reasons behind this, what I've missed here? > > We need to be sure that all other devices using this driver > should have no side effects on write. > > I can think of a weird controller doing unwanted things internally > on every write disregarding the current state. (or is this overly > paranoid?) > The specific reason is that, the clear bit may keep the same value with the set bit, but the clear operation can be only be completed by writing 1 to the clear bit, not just with the current fake state "1". > > > > /** > > @@ -128,7 +128,7 @@ static int ti_syscon_reset_deassert(struct reset_controller_dev *rcdev, > > mask = BIT(control->deassert_bit); > > value = (control->flags & DEASSERT_SET) ? mask : 0x0; > > > > - return regmap_update_bits(data->regmap, control->deassert_offset, mask, value); > > + return regmap_write_bits(data->regmap, control->deassert_offset, mask, value); > > } > > > > /**
