Add the newly introduced pwm driver to the existing PolarFire SoC entry.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a5012ba6ff9..5db66c743595 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17532,6 +17532,7 @@ F:	drivers/char/hw_random/mpfs-rng.c
 F:	drivers/clk/microchip/clk-mpfs.c
 F:	drivers/mailbox/mailbox-mpfs.c
 F:	drivers/pci/controller/pcie-microchip-host.c
+F:	drivers/pwm/pwm-microchip-core.c
 F:	drivers/rtc/rtc-mpfs.c
 F:	drivers/soc/microchip/
 F:	drivers/spi/spi-microchip-core.c
-- 
2.37.3

On Fri, Oct 07, 2022 at 12:35:13PM +0100, Conor Dooley wrote:
> Add the newly introduced pwm driver to the existing PolarFire SoC entry.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

I assume you will rework the series and resend this one with the driver
patche. Applying patch #4 alone doesn't make sense, so I'm marking this
one as "changes requested", too, in the PWM patchwork instance.

IMHO patches #1 and #2 make sense to be applied already without the
driver given the binding is already there. I assume they will go in via
the riscv tree, so I will mark these two as "handled elsewhere".

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

On Wed, Nov 09, 2022 at 10:35:25AM +0100, Uwe Kleine-König wrote:
> On Fri, Oct 07, 2022 at 12:35:13PM +0100, Conor Dooley wrote:
> > Add the newly introduced pwm driver to the existing PolarFire SoC entry.
> > 
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> 
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> 
> I assume you will rework the series and resend this one with the driver
> patche. Applying patch #4 alone doesn't make sense, so I'm marking this
> one as "changes requested", too, in the PWM patchwork instance.
> 
> IMHO patches #1 and #2 make sense to be applied already without the
> driver given the binding is already there. I assume they will go in via
> the riscv tree, so I will mark these two as "handled elsewhere".

Right. Makes sense to me - I'll take the dt-binding & the dt via the
riscv (or soc, we're changing things up there [a]) tree.

Thanks,
Conor.

[a] - https://lore.kernel.org/linux-riscv/mhng-e4210f56-fcc3-4db8-abdb-d43b3ebe695d@palmer-ri-x1c9a/