This patch makes the use of IRQ optional to make the DA9061/62 usable
for designs that don't have the IRQ pin connected, because the regulator
is usable without IRQ.
Signed-off-by: Christoph Niedermaier <[email protected]>
Acked-by: Mark Brown <[email protected]>
Reviewed-by: Adam Ward <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Reported-by: kernel test robot <[email protected]>
Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
---
Cc: Support Opensource <[email protected]>
Cc: Adam Thomson <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: [email protected]
Cc: [email protected]
To: [email protected]
---
V2: - Rebase on current next 20230209
- Add Reviewed-by and Acked-by tags
V3: - Rebase on current next 20230307
v4: - Rebase on current next 20230309
- Fix a missing variable change reported by kernel test robot
v5: - Rebase on current next 20230713
- Add Marek's Reviewed-by tag
---
drivers/regulator/da9062-regulator.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c
index c28b061eef02..1d354db0c1bd 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -924,7 +924,7 @@ static int da9062_regulator_probe(struct platform_device *pdev)
struct da9062_regulator *regl;
struct regulator_config config = { };
const struct da9062_regulator_info *rinfo;
- int irq, n, ret;
+ int n, ret;
int max_regulators;
switch (chip->chip_type) {
@@ -1012,12 +1012,11 @@ static int da9062_regulator_probe(struct platform_device *pdev)
}
/* LDOs overcurrent event support */
- irq = platform_get_irq_byname(pdev, "LDO_LIM");
- if (irq < 0)
- return irq;
- regulators->irq_ldo_lim = irq;
+ regulators->irq_ldo_lim = platform_get_irq_byname_optional(pdev, "LDO_LIM");
+ if (regulators->irq_ldo_lim < 0)
+ return 0;
- ret = devm_request_threaded_irq(&pdev->dev, irq,
+ ret = devm_request_threaded_irq(&pdev->dev, regulators->irq_ldo_lim,
NULL, da9062_ldo_lim_event,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
"LDO_LIM", regulators);
--
2.11.0
On Thu, Jul 13, 2023 at 11:03:28AM +0200, Christoph Niedermaier wrote:
> This patch makes the use of IRQ optional to make the DA9061/62 usable
> for designs that don't have the IRQ pin connected, because the regulator
> is usable without IRQ.
Are there any dependencies for this patch? The fact that I acked it
makes me think there were MFD parts
> Reported-by: kernel test robot <[email protected]>
> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
I really doubt that the LKP bot ran into an issue due to a system with
this device without an IRQ wired up...
From: Mark Brown [mailto:[email protected]]
Sent: Thursday, July 13, 2023 2:30 PM
> On Thu, Jul 13, 2023 at 11:03:28AM +0200, Christoph Niedermaier wrote:
>
>> This patch makes the use of IRQ optional to make the DA9061/62 usable
>> for designs that don't have the IRQ pin connected, because the regulator
>> is usable without IRQ.
>
> Are there any dependencies for this patch? The fact that I acked it
> makes me think there were MFD parts
It's a patch series. This patch is the last one in this series, that is
missing to have the ability to run the DA9061/62 without a connected IRQ
pin. The other patches are already upstreamed and yes there are MFD parts,
see below:
1: commit 7ef5c57758c4 ("dt-bindings: mfd: da9062: Move IRQ to optional properties")
2: commit 7d61f6313e90 ("mfd: da9062: Use MFD_CELL_OF macro")
3: commit c923d5001ba0 ("mfd: da9062: Remove IRQ requirement")
4: This patch ("regulator: da9062: Make the use of IRQ optional")
>> Reported-by: kernel test robot <[email protected]>
>> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
> I really doubt that the LKP bot ran into an issue due to a system with
> this device without an IRQ wired up...
In V3 of this patch the kernel test robot found an issue. I had really
overlooked that. Thanks to LKP. I forgot to replace the irq variable in
the function devm_request_threaded_irq(). So it affected the path with
IRQ. In V4 I fixed that. In V5 I only rebased it on the current next
20230713 and add Marek's Reviewed-by tag.
Regards
Christoph
On Thu, Jul 13, 2023 at 03:36:38PM +0000, Christoph Niedermaier wrote:
> From: Mark Brown [mailto:[email protected]]
> > Are there any dependencies for this patch? The fact that I acked it
> > makes me think there were MFD parts
> It's a patch series. This patch is the last one in this series, that is
> missing to have the ability to run the DA9061/62 without a connected IRQ
> pin. The other patches are already upstreamed and yes there are MFD parts,
> see below:
Oh, dear. Why weren't they applied, it's not even the confusion there
was over what Reviewed-by means...
> >> Reported-by: kernel test robot <[email protected]>
> >> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> > I really doubt that the LKP bot ran into an issue due to a system with
> > this device without an IRQ wired up...
> In V3 of this patch the kernel test robot found an issue. I had really
> overlooked that. Thanks to LKP. I forgot to replace the irq variable in
> the function devm_request_threaded_irq(). So it affected the path with
> IRQ. In V4 I fixed that. In V5 I only rebased it on the current next
> 20230713 and add Marek's Reviewed-by tag.
That doesn't mean you should include tags like this, it makes it look
like they reported the commit...
On Thu, 13 Jul 2023 11:03:28 +0200, Christoph Niedermaier wrote:
> This patch makes the use of IRQ optional to make the DA9061/62 usable
> for designs that don't have the IRQ pin connected, because the regulator
> is usable without IRQ.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: da9062: Make the use of IRQ optional
commit: 497897cb200d03b89524e6b4dfb71c77af324766
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
From: Mark Brown [mailto:[email protected]]
Sent: Thursday, July 13, 2023 6:34 PM
> On Thu, Jul 13, 2023 at 03:36:38PM +0000, Christoph Niedermaier wrote:
>> From: Mark Brown [mailto:[email protected]]
>
>>> Are there any dependencies for this patch? The fact that I acked it
>>> makes me think there were MFD parts
>
>> It's a patch series. This patch is the last one in this series, that is
>> missing to have the ability to run the DA9061/62 without a connected IRQ
>> pin. The other patches are already upstreamed and yes there are MFD parts,
>> see below:
>
> Oh, dear. Why weren't they applied, it's not even the confusion there
> was over what Reviewed-by means...
>
>>>> Reported-by: kernel test robot <[email protected]>
>>>> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
>>> I really doubt that the LKP bot ran into an issue due to a system with
>>> this device without an IRQ wired up...
>
>> In V3 of this patch the kernel test robot found an issue. I had really
>> overlooked that. Thanks to LKP. I forgot to replace the irq variable in
>> the function devm_request_threaded_irq(). So it affected the path with
>> IRQ. In V4 I fixed that. In V5 I only rebased it on the current next
>> 20230713 and add Marek's Reviewed-by tag.
>
> That doesn't mean you should include tags like this, it makes it look
> like they reported the commit...
Thanks for helping me. May I asked which tags are you referring to here?
Regards
Christoph
On Fri, Jul 14, 2023 at 07:03:28PM +0000, Christoph Niedermaier wrote:
> From: Mark Brown [mailto:[email protected]]
> Sent: Thursday, July 13, 2023 6:34 PM
> > On Thu, Jul 13, 2023 at 03:36:38PM +0000, Christoph Niedermaier wrote:
> >> From: Mark Brown [mailto:[email protected]]
> >>>> Reported-by: kernel test robot <[email protected]>
> >>>> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> > That doesn't mean you should include tags like this, it makes it look
> > like they reported the commit...
> Thanks for helping me. May I asked which tags are you referring to here?
The ones quoted above.
From: Mark Brown [mailto:[email protected]]
Sent: Friday, July 14, 2023 9:17 PM
> On Fri, Jul 14, 2023 at 07:03:28PM +0000, Christoph Niedermaier wrote:
>> From: Mark Brown [mailto:[email protected]]
>> Sent: Thursday, July 13, 2023 6:34 PM
>>> On Thu, Jul 13, 2023 at 03:36:38PM +0000, Christoph Niedermaier wrote:
>>>> From: Mark Brown [mailto:[email protected]]
>
>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
>>> That doesn't mean you should include tags like this, it makes it look
>>> like they reported the commit...
>
>> Thanks for helping me. May I asked which tags are you referring to here?
>
> The ones quoted above.
The kernel test robot wrote:
[...]
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
| Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
[...]
Maybe that misled me.
Regards
Christoph
From: Mark Brown [mailto:[email protected]]
Sent: Friday, July 14, 2023 10:21 PM
> On Fri, Jul 14, 2023 at 08:15:40PM +0000, Christoph Niedermaier wrote:
>>> On Fri, Jul 14, 2023 at 07:03:28PM +0000, Christoph Niedermaier wrote:
>
>>> The ones quoted above.
>
>> The kernel test robot wrote:
>> [...]
>> If you fix the issue, kindly add following tag where applicable
>> | Reported-by: kernel test robot <[email protected]>
>> | Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>> [...]
>
>> Maybe that misled me.
>
> Yes, I wish it wouldn't do that. That really only applies when you're
> sending a patch that's substantially a fix for the issue it reports, for
> things that have not yet been applied it's just a normal review comment
> and you shouldn't add the tags.
Thank you for this clarification.
Regards
Christoph
On Fri, Jul 14, 2023 at 08:15:40PM +0000, Christoph Niedermaier wrote:
> > On Fri, Jul 14, 2023 at 07:03:28PM +0000, Christoph Niedermaier wrote:
> > The ones quoted above.
> The kernel test robot wrote:
> [...]
> If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot <[email protected]>
> | Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> [...]
> Maybe that misled me.
Yes, I wish it wouldn't do that. That really only applies when you're
sending a patch that's substantially a fix for the issue it reports, for
things that have not yet been applied it's just a normal review comment
and you shouldn't add the tags.