[RESEND PATCH v4] MAINTAINERS: add polarfire rng, pci and clock drivers

Conor.Dooley at microchip.com Conor.Dooley at microchip.com
Thu Jul 7 07:07:06 PDT 2022


On 07/07/2022 14:37, Arnd Bergmann wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, Jul 7, 2022 at 3:30 PM <Conor.Dooley at microchip.com> wrote:
>>
>> On 22/06/2022 23:58, Conor Dooley wrote:
>>> From: Conor Dooley <conor.dooley at microchip.com>
>>>
>>> Hardware random, PCI and clock drivers for the PolarFire SoC have been
>>> upstreamed but are not covered by the MAINTAINERS entry, so add them.
>>> Daire is the author of the clock & PCI drivers, so add him as a
>>> maintainer in place of Lewis.
>>>
>>> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
>>> Acked-by: Stephen Boyd <sboyd at kernel.org>
>>> Signed-off-by: Conor Dooley <conor.dooley at microchip.com>
>>
>> Arnd, Palmer:
>> Does the SoC tree make more sense for this patch?
>> I am missing an ack from Herbert (but I don't think that's blocking
>> for a MAINTAINERS update to my own entry?).
>>
>> If SoC is the better option, should I resend this to soc at kernel.org?
>> Unfortunately, since I originally sent this patch there have been
>> other changes to this entry that will conflict in -next (all are
>> additions so easily resolved...).
>>
>> I was hoping to get this patch applied to v5.19-rc(foo) since we
>> never added maintainers entries for these drivers rather than wait
>> for v5.20.
>>
>> If you (plural) would rather wait for v5.20, I can resubmit this patch
>> after v5.20-mw1 with an additional i2c entry (if the driver is applied)
>> that already has an ack from Wolfram.
> 
> I tend to take MAINTAINERS updates as bugfixes in the soc tre
> (for 5.19), and I can pick it up if you send it to soc at kernel.org.

Cool, I will resend to soc at kernel.org.

> 
> There should never be a need to wait for the merge window
> with these updates, it's either a bugfix (for 5.19) or for the current
> -next cycle (5.20).

I was just suggesting that to avoid conflicts in linux-next
but they will/can be trivially resolved.

Thanks Arnd.
Conor.



More information about the linux-riscv mailing list