| Message ID | 20230713090328.3879-1-cniedermaier@dh-electronics.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [V5] regulator: da9062: Make the use of IRQ optional | expand |
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 <lkp@intel.com> > Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ 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:broonie@kernel.org] 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 <lkp@intel.com> >> Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ > > 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:broonie@kernel.org] > > 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 <lkp@intel.com> > >> Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ > > 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:broonie@kernel.org] 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:broonie@kernel.org] > >>> 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 <lkp@intel.com> >>>> Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ > >>> 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:broonie@kernel.org] > 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:broonie@kernel.org] > >>>> Reported-by: kernel test robot <lkp@intel.com> > >>>> Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ > > 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:broonie@kernel.org] 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:broonie@kernel.org] >> 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:broonie@kernel.org] > >>>>>> Reported-by: kernel test robot <lkp@intel.com> >>>>>> Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ > >>> 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 <lkp@intel.com> | Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ [...] Maybe that misled me. 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 <lkp@intel.com> > | Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ > [...] > 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.
From: Mark Brown [mailto:broonie@kernel.org] 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 <lkp@intel.com> >> | Link: https://lore.kernel.org/oe-kbuild-all/202303082246.GuLdPL0t-lkp@intel.com/ >> [...] > >> 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
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);