From: Jacky Huang <ychuang3@nuvoton.com>

This patchset adds initial support for the Nuvoton ma35d1 SoC, including
initial device tree, clock driver, reset driver, and serial driver.

This patchset cover letter is based from the initial support for Nuvoton
ma35d1 to keep tracking the version history.

This patchset had been applied to Linux kernel 6.3-rc2 and tested on the
Nuvoton ma35d1 SOM evaluation board.

(ma35d1 information: https://www.nuvoton.com/products/microprocessors/arm-cortex-a35-mpus/)
MA35D1 porting on linux-5.10.y can be found at: https://github.com/OpenNuvoton/MPU-Family

Jacky Huang (15):
  arm64: Kconfig.platforms: Add config for Nuvoton MA35 platform
  arm64: defconfig: Add Nuvoton MA35 family support
  mfd: Add the header file of Nuvoton ma35d1 system manager
  dt-bindings: clock: nuvoton: add binding for ma35d1 clock controller
  dt-bindings: reset: nuvoton: add binding for ma35d1 IP reset control
  dt-bindings: mfd: syscon: Add nuvoton,ma35d1-sys compatible
  dt-bindings: arm: Add initial bindings for Nuvoton platform
  dt-bindings: clock: Document ma35d1 clock controller bindings
  dt-bindings: reset: Document ma35d1 reset controller bindings
  dt-bindings: serial: Document ma35d1 uart controller bindings
  arm64: dts: nuvoton: Add initial ma35d1 device tree
  clk: nuvoton: Add clock driver for ma35d1 clock controller
  reset: Add Nuvoton ma35d1 reset driver support
  tty: serial: Add Nuvoton ma35d1 serial driver support
  MAINTAINERS: Add entry for NUVOTON MA35

 .../devicetree/bindings/arm/nuvoton.yaml      |  30 +
 .../bindings/clock/nuvoton,ma35d1-clk.yaml    |  83 ++
 .../devicetree/bindings/mfd/syscon.yaml       |   1 +
 .../bindings/reset/nuvoton,ma35d1-reset.yaml  |  50 +
 .../serial/nuvoton,ma35d1-serial.yaml         |  52 +
 MAINTAINERS                                   |  12 +
 arch/arm64/Kconfig.platforms                  |   9 +
 arch/arm64/boot/dts/nuvoton/Makefile          |   2 +
 .../boot/dts/nuvoton/ma35d1-iot-512m.dts      |  24 +
 .../boot/dts/nuvoton/ma35d1-som-256m.dts      |  23 +
 arch/arm64/boot/dts/nuvoton/ma35d1.dtsi       | 272 +++++
 arch/arm64/configs/defconfig                  |   1 +
 drivers/clk/Makefile                          |   1 +
 drivers/clk/nuvoton/Makefile                  |   4 +
 drivers/clk/nuvoton/clk-ma35d1-divider.c      | 144 +++
 drivers/clk/nuvoton/clk-ma35d1-pll.c          | 534 ++++++++++
 drivers/clk/nuvoton/clk-ma35d1.c              | 970 ++++++++++++++++++
 drivers/clk/nuvoton/clk-ma35d1.h              | 198 ++++
 drivers/reset/Kconfig                         |   6 +
 drivers/reset/Makefile                        |   1 +
 drivers/reset/reset-ma35d1.c                  | 152 +++
 drivers/tty/serial/Kconfig                    |  18 +
 drivers/tty/serial/Makefile                   |   1 +
 drivers/tty/serial/ma35d1_serial.c            | 842 +++++++++++++++
 drivers/tty/serial/ma35d1_serial.h            |  93 ++
 .../dt-bindings/clock/nuvoton,ma35d1-clk.h    | 253 +++++
 .../dt-bindings/reset/nuvoton,ma35d1-reset.h  | 108 ++
 include/linux/mfd/ma35d1-sys.h                |  95 ++
 include/uapi/linux/serial_core.h              |   3 +
 29 files changed, 3982 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/nuvoton.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml
 create mode 100644 Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
 create mode 100644 Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml
 create mode 100644 arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
 create mode 100644 arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
 create mode 100644 arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
 create mode 100644 drivers/clk/nuvoton/Makefile
 create mode 100644 drivers/clk/nuvoton/clk-ma35d1-divider.c
 create mode 100644 drivers/clk/nuvoton/clk-ma35d1-pll.c
 create mode 100644 drivers/clk/nuvoton/clk-ma35d1.c
 create mode 100644 drivers/clk/nuvoton/clk-ma35d1.h
 create mode 100644 drivers/reset/reset-ma35d1.c
 create mode 100644 drivers/tty/serial/ma35d1_serial.c
 create mode 100644 drivers/tty/serial/ma35d1_serial.h
 create mode 100644 include/dt-bindings/clock/nuvoton,ma35d1-clk.h
 create mode 100644 include/dt-bindings/reset/nuvoton,ma35d1-reset.h
 create mode 100644 include/linux/mfd/ma35d1-sys.h

-- 
2.34.1

On 15/03/2023 08:28, Jacky Huang wrote:
> From: Jacky Huang <ychuang3@nuvoton.com>
> 
> This patchset adds initial support for the Nuvoton ma35d1 SoC, including
> initial device tree, clock driver, reset driver, and serial driver.
> 
> This patchset cover letter is based from the initial support for Nuvoton
> ma35d1 to keep tracking the version history.
> 

To maintainers: patches should not be applied independently because it
will start failing tests...

Best regards,
Krzysztof

On Wed, Mar 15, 2023, at 08:28, Jacky Huang wrote:
> From: Jacky Huang <ychuang3@nuvoton.com>
>
> This patchset adds initial support for the Nuvoton ma35d1 SoC, including
> initial device tree, clock driver, reset driver, and serial driver.
>
> This patchset cover letter is based from the initial support for Nuvoton
> ma35d1 to keep tracking the version history.
>
> This patchset had been applied to Linux kernel 6.3-rc2 and tested on the
> Nuvoton ma35d1 SOM evaluation board.
>
> (ma35d1 information: 
> https://www.nuvoton.com/products/microprocessors/arm-cortex-a35-mpus/)
> MA35D1 porting on linux-5.10.y can be found at: 
> https://github.com/OpenNuvoton/MPU-Family

Hi Jacky,

Thanks a lot for your submission. I saw this presented at
EmbeddedWorld yesterday and asked about mainline Linux
support, but did not expect to see the patches this soon ;-)

The easiest process for getting the series merged is to
have me add it the entire series to the SoC tree after the
individual drivers have been reviewed by the respective
subsystem maintainers that are already on Cc here. When
the review is complete, you can add soc@kernel.org to Cc,
so they show up in patchwork, or alternatively send a pull
request for a git tree to that address. Until then, you
can add my own email address to Cc so I can follow the
reviews.

After the initial merge, the normal method for additional
device drivers is to have them sent for inclusion to the
subsystem maintainers. The soc tree and soc@kernel.org address
is then only used for changes in arch/arm64, i.e. updates
to the dts files, Kconfig, defconfig and MAINTAINERS, 
as well as the drivers/soc and drivers/firmware directories,
if you have anything in there.

If you have any additional questions about the process,
feel free to also ask me.

     Arnd

On 2023/3/16 下午 10:05, Arnd Bergmann wrote:
> On Wed, Mar 15, 2023, at 08:28, Jacky Huang wrote:
>> From: Jacky Huang <ychuang3@nuvoton.com>
>>
>> This patchset adds initial support for the Nuvoton ma35d1 SoC, including
>> initial device tree, clock driver, reset driver, and serial driver.
>>
>> This patchset cover letter is based from the initial support for Nuvoton
>> ma35d1 to keep tracking the version history.
>>
>> This patchset had been applied to Linux kernel 6.3-rc2 and tested on the
>> Nuvoton ma35d1 SOM evaluation board.
>>
>> (ma35d1 information:
>> https://www.nuvoton.com/products/microprocessors/arm-cortex-a35-mpus/)
>> MA35D1 porting on linux-5.10.y can be found at:
>> https://github.com/OpenNuvoton/MPU-Family
> Hi Jacky,
>
> Thanks a lot for your submission. I saw this presented at
> EmbeddedWorld yesterday and asked about mainline Linux
> support, but did not expect to see the patches this soon ;-)
>
> The easiest process for getting the series merged is to
> have me add it the entire series to the SoC tree after the
> individual drivers have been reviewed by the respective
> subsystem maintainers that are already on Cc here. When
> the review is complete, you can add soc@kernel.org to Cc,
> so they show up in patchwork, or alternatively send a pull
> request for a git tree to that address. Until then, you
> can add my own email address to Cc so I can follow the
> reviews.
>
> After the initial merge, the normal method for additional
> device drivers is to have them sent for inclusion to the
> subsystem maintainers. The soc tree and soc@kernel.org address
> is then only used for changes in arch/arm64, i.e. updates
> to the dts files, Kconfig, defconfig and MAINTAINERS,
> as well as the drivers/soc and drivers/firmware directories,
> if you have anything in there.
>
> If you have any additional questions about the process,
> feel free to also ask me.
>
>       Arnd

Hi Anrd,

Thank you very much for your kind help. You explained it so well,
I have understood the process. We got a lot of suggestions for this
patchset, and there are a lot of issues to fix. When most of the
problems get solved and acknowledged by the reviewers, I will
add you and soc@kernel.org to Cc.


Best regards,

Jacky Huang

On Fri, Mar 17, 2023, at 07:30, Jacky Huang wrote:
> On 2023/3/16 下午 10:05, Arnd Bergmann wrote:
>
> Thank you very much for your kind help. You explained it so well,
> I have understood the process. We got a lot of suggestions for this
> patchset, and there are a lot of issues to fix. When most of the
> problems get solved and acknowledged by the reviewers, I will
> add you and soc@kernel.org to Cc.

Ok, sounds good. Two more clarifications from me:

1. I expect you will have to go through two or three submissions
that get more feedback before everyone is happy. Please include
my arnd@arndb.de on Cc on all the submissions, but only include
the soc@kernel.org address when all patches have an Acked-by
or Reviewed-by from the respective subsystem maintainer.

2. I think the series looks very good at this point, and most of the
feedback was about minor details, so I am optimistic that we can
actually merge it soon.

I only now saw that you had already submitted this several times
at the beginning of last year, and this is technically 'v5'
of the series, and it would make sense to add 'v6' to the subject
next time and link back to the previous [1] and this[2] submission
on lore.kernel.org.


    Arnd

[1] https://lore.kernel.org/all/20220510032558.10304-1-ychuang3@nuvoton.com/
[2] https://lore.kernel.org/all/20230315072902.9298-1-ychuang570808@gmail.com/

Dear Arnd,


Thanks for you advice.


On 2023/3/17 下午 09:21, Arnd Bergmann wrote:
> On Fri, Mar 17, 2023, at 07:30, Jacky Huang wrote:
>> On 2023/3/16 下午 10:05, Arnd Bergmann wrote:
>>
>> Thank you very much for your kind help. You explained it so well,
>> I have understood the process. We got a lot of suggestions for this
>> patchset, and there are a lot of issues to fix. When most of the
>> problems get solved and acknowledged by the reviewers, I will
>> add you and soc@kernel.org to Cc.
> Ok, sounds good. Two more clarifications from me:
>
> 1. I expect you will have to go through two or three submissions
> that get more feedback before everyone is happy. Please include
> my arnd@arndb.de on Cc on all the submissions, but only include
> the soc@kernel.org address when all patches have an Acked-by
> or Reviewed-by from the respective subsystem maintainer.


Sure, I will add you on Cc. Thank you.


> 2. I think the series looks very good at this point, and most of the
> feedback was about minor details, so I am optimistic that we can
> actually merge it soon.
>
> I only now saw that you had already submitted this several times
> at the beginning of last year, and this is technically 'v5'
> of the series, and it would make sense to add 'v6' to the subject
> next time and link back to the previous [1] and this[2] submission
> on lore.kernel.org.
>
>
>      Arnd
>
> [1] https://lore.kernel.org/all/20220510032558.10304-1-ychuang3@nuvoton.com/
> [2] https://lore.kernel.org/all/20230315072902.9298-1-ychuang570808@gmail.com/


In fact, I was thinking about this before submitting the patch. Looks 
like this is causing

confusion for reviewers, so thanks for the suggestion. I will submit the 
next version as v6,

and add the history of v1 ~ v4, and this version will be regarded as v5.


Best regards,

Jacky Huang

On 17/03/2023 14:21, Arnd Bergmann wrote:
> I only now saw that you had already submitted this several times
> at the beginning of last year, and this is technically 'v5'
> of the series, and it would make sense to add 'v6' to the subject
> next time and link back to the previous [1] and this[2] submission
> on lore.kernel.org.

... and address previous feedback. Or at least make it clear in
changelog that you addressed it, so our review was not ignored.

Best regards,
Krzysztof

On 2023/3/18 上午 12:06, Krzysztof Kozlowski wrote:
> On 17/03/2023 14:21, Arnd Bergmann wrote:
>> I only now saw that you had already submitted this several times
>> at the beginning of last year, and this is technically 'v5'
>> of the series, and it would make sense to add 'v6' to the subject
>> next time and link back to the previous [1] and this[2] submission
>> on lore.kernel.org.
> ... and address previous feedback. Or at least make it clear in
> changelog that you addressed it, so our review was not ignored.
>
> Best regards,
> Krzysztof


Dear Krzysztof,


Thank you.

Of course, I will add back the changelog.

And, I have a question. If subsequent modifications made to a patch, 
should the

"Reviewed-by" still be valid? Can we keep it?

Best regards,

Jacky Huang

On Sat, Mar 18, 2023, at 04:07, Jacky Huang wrote:
> On 2023/3/18 上午 12:06, Krzysztof Kozlowski wrote:
>> On 17/03/2023 14:21, Arnd Bergmann wrote:
>>> I only now saw that you had already submitted this several times
>>> at the beginning of last year, and this is technically 'v5'
>>> of the series, and it would make sense to add 'v6' to the subject
>>> next time and link back to the previous [1] and this[2] submission
>>> on lore.kernel.org.
>> ... and address previous feedback. Or at least make it clear in
>> changelog that you addressed it, so our review was not ignored.
>>
>
> Of course, I will add back the changelog.
>
> And, I have a question. If subsequent modifications made to a patch, 
> should the
>
> "Reviewed-by" still be valid? Can we keep it?

In general yes, but it's a bit of a grey area and you have
to apply common sense. Examples where I would drop the
Reviewed-by tag are

- if you changed something based on feedback from a reviewer and
  they provided a Reviewed-by tag based on that changed, but then
  another person asked you change the same thing differently, or
  back to the original version

- if you combine a patch with another one that was not also
  reviewed by the same person.

      Arnd