The newly added regulator ramp-delay specifiers in regulator desc
lacked the documentation. Add some. Also fix a typo.
Signed-off-by: Matti Vaittinen <[email protected]>
---
include/linux/regulator/driver.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 4aec20387857..5b6f594f99ae 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -337,6 +337,12 @@ enum regulator_type {
* @pull_down_val_on: Enabling value for control when using regmap
* set_pull_down
*
+ * @ramp_reg: Register for controlling the regulator ramp-rate.
+ * @ramp_mask: Bitmask for the ramp-rate control register.
+ * @ramp_delay_table: Table for mapping the regulator ramp-rate values. Values
+ * should be given in units of V/S (uV/uS). See the
+ * regulator_set_ramp_delay_regmap().
+ *
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
*
@@ -462,7 +468,7 @@ struct regulator_err_state {
};
/**
- * struct regulator_irq_data - regulator error/notification status date
+ * struct regulator_irq_data - regulator error/notification status data
*
* @states: Status structs for each of the associated regulators.
* @num_states: Amount of associated regulators.
base-commit: 36a21d51725af2ce0700c6ebcb6b9594aac658a6
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
On Wed, Aug 18, 2021 at 07:18:19AM +0300, Matti Vaittinen wrote:
> The newly added regulator ramp-delay specifiers in regulator desc
> lacked the documentation. Add some. Also fix a typo.
This should've been two patches.
On Wed, 18 Aug 2021 07:18:19 +0300, Matti Vaittinen wrote:
> The newly added regulator ramp-delay specifiers in regulator desc
> lacked the documentation. Add some. Also fix a typo.
>
>
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: Minor regulator documentation fixes.
commit: c049742fbc71129c481a6d5e52392b9aa482cc9e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On Wed, 2021-08-18 at 13:17 +0100, Mark Brown wrote:
> On Wed, Aug 18, 2021 at 07:18:19AM +0300, Matti Vaittinen wrote:
> > The newly added regulator ramp-delay specifiers in regulator desc
> > lacked the documentation. Add some. Also fix a typo.
>
> This should've been two patches.
I was thinking of that. I thought that it made less of a hassle with
single patch. After all, both changes were doc updates - and I didn't
think the typofix warranted backport or a Fixed tag.
Could you please educate me & explain why would you have preferred two
patches? (I see you any ways applied this so I guess there's no need to
split & resend - thanks).
Best Regards
Matti
On Thu, Aug 19, 2021 at 08:06:48AM +0300, Matti Vaittinen wrote:
> I was thinking of that. I thought that it made less of a hassle with
> single patch. After all, both changes were doc updates - and I didn't
> think the typofix warranted backport or a Fixed tag.
> Could you please educate me & explain why would you have preferred two
> patches? (I see you any ways applied this so I guess there's no need to
> split & resend - thanks).
It's two changes that don't overlap in any way. Part of the reason for
splitting patches up is that it reduces the cogantive load checking that
the patch actually does the thing described in the changelog, with two
changes in one patch you need to hold two things in your head at once.
The more trivial the patch the bigger the extra effort relative to what
they'd have taken otherwise.
On Thu, 2021-08-19 at 12:43 +0100, Mark Brown wrote:
> On Thu, Aug 19, 2021 at 08:06:48AM +0300, Matti Vaittinen wrote:
>
> > I was thinking of that. I thought that it made less of a hassle
> > with
> > single patch. After all, both changes were doc updates - and I
> > didn't
> > think the typofix warranted backport or a Fixed tag.
> > Could you please educate me & explain why would you have preferred
> > two
> > patches? (I see you any ways applied this so I guess there's no
> > need to
> > split & resend - thanks).
>
> It's two changes that don't overlap in any way. Part of the reason
> for
> splitting patches up is that it reduces the cogantive load checking
> that
> the patch actually does the thing described in the changelog, with
> two
> changes in one patch you need to hold two things in your head at
> once.
> The more trivial the patch the bigger the extra effort relative to
> what
> they'd have taken otherwise.
Fair enough. Thanks for explanation.
--Matti