Hello,

Here I want to introduce a new patch series, which aims to support IOMUX
functions provided by SIUL2 [System Integration Unit Lite2] on S32 SoCs,
such as S32G2. This series is originally from NXP's implementation on
nxp-auto-linux repo[1] and it will be required by upstream kernel for
supporting a variety of devices on S32 SoCs which need to config PINMUXs,
such as PHYs and MAC controllers.

Thanks,
Chester

Changes in v5:
- dt-bindings: No change
- driver:
  - Refactor register r/w access based on REGMAP_MMIO and regmap APIs.
  - Tag PM functions with '__maybe_unused'.
  - Add mask check while parsing pin ID from a pinmux value.
  - Simplify s32_pinconf_mscr_* functions.

Changes in v4:
- Link: https://lore.kernel.org/linux-arm-kernel/20230118094728.3814-2-clin@suse.com/T/
- dt-bindings:
  - Change the representation of available slew-rate DT values from
    register values to real frequencies.
- driver:
  - Add a mapping table for converting the slew rates to register
    settings.
  - Move driver files into an independent folder drivers/pinctrl/nxp
- Add a MAINTAINER patch.

Changes in v3:
- Link: https://lore.kernel.org/lkml/20221221073232.21888-1-clin@suse.com/T/
- dt-bindings:
  - Remove the minItems from reg because there's no optional item for
    s32g2.
  - List supported properties of pinmux-node and pincfg-node and add more
    descriptions.
  - Adjust the location of "required:".
  - Fix descriptions and wordings.
  - Rename the yaml file to nxp,s32g2-siul2-pinctrl.yaml.
- Rename pinctrl-s32g.c to pinctrl-s32g2.c
- Adjust Kconfig options [menu-invisible] and names [S32G -> S32G2].
- Add .suppress_bind_attrs
- Drop the .remove callback and replace the module_platform_driver() call
  with builtin_platform_driver()

Changes in v2:
- Link: https://lore.kernel.org/lkml/20221128054820.1771-1-clin@suse.com/T/
- Move the "nxp,pins" ID range information from DT to the driver.
- dt-bindings:
  - Fix schema issues.
  - Add descriptions for reg entries.
  - Revise the example.
- Refine the compatible name from "nxp,s32g-..." to "nxp,s32g2-...".
- Fix the copyright format suggested by NXP.

[1] https://github.com/nxp-auto-linux/linux/tree/bsp35.0-5.15.73-rt

Chester Lin (3):
  dt-bindings: pinctrl: add schema for NXP S32 SoCs
  pinctrl: add NXP S32 SoC family support
  MAINTAINERS: Add NXP S32 pinctrl maintainer and reviewer

 .../pinctrl/nxp,s32g2-siul2-pinctrl.yaml      | 123 +++
 MAINTAINERS                                   |   8 +
 drivers/pinctrl/Kconfig                       |   1 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/nxp/Kconfig                   |  15 +
 drivers/pinctrl/nxp/Makefile                  |   4 +
 drivers/pinctrl/nxp/pinctrl-s32.h             |  75 ++
 drivers/pinctrl/nxp/pinctrl-s32cc.c           | 945 ++++++++++++++++++
 drivers/pinctrl/nxp/pinctrl-s32g2.c           | 773 ++++++++++++++
 9 files changed, 1945 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml
 create mode 100644 drivers/pinctrl/nxp/Kconfig
 create mode 100644 drivers/pinctrl/nxp/Makefile
 create mode 100644 drivers/pinctrl/nxp/pinctrl-s32.h
 create mode 100644 drivers/pinctrl/nxp/pinctrl-s32cc.c
 create mode 100644 drivers/pinctrl/nxp/pinctrl-s32g2.c

-- 
2.37.3

On Mon, Feb 20, 2023 at 3:33 AM Chester Lin <clin@suse.com> wrote:

> Here I want to introduce a new patch series, which aims to support IOMUX
> functions provided by SIUL2 [System Integration Unit Lite2] on S32 SoCs,
> such as S32G2. This series is originally from NXP's implementation on
> nxp-auto-linux repo[1] and it will be required by upstream kernel for
> supporting a variety of devices on S32 SoCs which need to config PINMUXs,
> such as PHYs and MAC controllers.
>
> Thanks,
> Chester
>
> Changes in v5:
> - dt-bindings: No change
> - driver:
>   - Refactor register r/w access based on REGMAP_MMIO and regmap APIs.
>   - Tag PM functions with '__maybe_unused'.
>   - Add mask check while parsing pin ID from a pinmux value.
>   - Simplify s32_pinconf_mscr_* functions.

This looks really good any no more comments arrived, so patches are applied
for v6.4!

Thanks for your work on this so far Chester! (I suppose there will be
maintenance
for this family going forward.)

Yours,
Linus Walleij

Mon, Mar 06, 2023 at 02:28:56PM +0100, Linus Walleij kirjoitti:
> On Mon, Feb 20, 2023 at 3:33 AM Chester Lin <clin@suse.com> wrote:
> 
> > Here I want to introduce a new patch series, which aims to support IOMUX
> > functions provided by SIUL2 [System Integration Unit Lite2] on S32 SoCs,
> > such as S32G2. This series is originally from NXP's implementation on
> > nxp-auto-linux repo[1] and it will be required by upstream kernel for
> > supporting a variety of devices on S32 SoCs which need to config PINMUXs,
> > such as PHYs and MAC controllers.
> >
> > Thanks,
> > Chester
> >
> > Changes in v5:
> > - dt-bindings: No change
> > - driver:
> >   - Refactor register r/w access based on REGMAP_MMIO and regmap APIs.
> >   - Tag PM functions with '__maybe_unused'.
> >   - Add mask check while parsing pin ID from a pinmux value.
> >   - Simplify s32_pinconf_mscr_* functions.
> 
> This looks really good any no more comments arrived, so patches are applied
> for v6.4!
> 
> Thanks for your work on this so far Chester! (I suppose there will be
> maintenance
> for this family going forward.)

Can you unpull this?

-- 
With Best Regards,
Andy Shevchenko

On Tue, Mar 7, 2023 at 12:28 AM <andy.shevchenko@gmail.com> wrote:
> Mon, Mar 06, 2023 at 02:28:56PM +0100, Linus Walleij kirjoitti:
> > On Mon, Feb 20, 2023 at 3:33 AM Chester Lin <clin@suse.com> wrote:
> >
> > > Here I want to introduce a new patch series, which aims to support IOMUX
> > > functions provided by SIUL2 [System Integration Unit Lite2] on S32 SoCs,
> > > such as S32G2. This series is originally from NXP's implementation on
> > > nxp-auto-linux repo[1] and it will be required by upstream kernel for
> > > supporting a variety of devices on S32 SoCs which need to config PINMUXs,
> > > such as PHYs and MAC controllers.
> > >
> > > Thanks,
> > > Chester
> > >
> > > Changes in v5:
> > > - dt-bindings: No change
> > > - driver:
> > >   - Refactor register r/w access based on REGMAP_MMIO and regmap APIs.
> > >   - Tag PM functions with '__maybe_unused'.
> > >   - Add mask check while parsing pin ID from a pinmux value.
> > >   - Simplify s32_pinconf_mscr_* functions.
> >
> > This looks really good any no more comments arrived, so patches are applied
> > for v6.4!
> >
> > Thanks for your work on this so far Chester! (I suppose there will be
> > maintenance
> > for this family going forward.)
>
> Can you unpull this?

If need be.

Are there serious issues with the patch set such that they cannot be fixed
by add-on patches?

Yours,
Linus Walleij

On Tue, Mar 7, 2023 at 11:22 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Mar 7, 2023 at 12:28 AM <andy.shevchenko@gmail.com> wrote:

...

> > Can you unpull this?

> If need be.
>
> Are there serious issues with the patch set such that they cannot be fixed
> by add-on patches?

There are a few absent error checks, some error code shadowing, etc.
I can't tell if these all are serious, but the amount of them is like a dozen.

I reviewed the patch, so you can look into that yourself and decide.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Mar 7, 2023 at 10:56 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Mar 7, 2023 at 11:22 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Mar 7, 2023 at 12:28 AM <andy.shevchenko@gmail.com> wrote:
>
> ...
>
> > > Can you unpull this?
>
> > If need be.
> >
> > Are there serious issues with the patch set such that they cannot be fixed
> > by add-on patches?
>
> There are a few absent error checks, some error code shadowing, etc.
> I can't tell if these all are serious, but the amount of them is like a dozen.
>
> I reviewed the patch, so you can look into that yourself and decide.

I looked at it and some of the comments are pretty serious and need
addressing ASAP.

However it only affects this hardware so it's not like it's breaking the
world. I generally prefer in-tree development over too many big patch
iterations, it gets more focused.

I think if Chester can follow up with a patch or several addressing the
comments in the next week or two that's fine.

However if we get closer to -rc6 and nothing has happened I would
not be so happy and then I might just revert the driver patch.

Yours,
Linus Walleij

Hi Linus and Andy,

On Tue, Mar 07, 2023 at 01:49:00PM +0100, Linus Walleij wrote:
> On Tue, Mar 7, 2023 at 10:56 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, Mar 7, 2023 at 11:22 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Tue, Mar 7, 2023 at 12:28 AM <andy.shevchenko@gmail.com> wrote:
> >
> > ...
> >
> > > > Can you unpull this?
> >
> > > If need be.
> > >
> > > Are there serious issues with the patch set such that they cannot be fixed
> > > by add-on patches?
> >
> > There are a few absent error checks, some error code shadowing, etc.
> > I can't tell if these all are serious, but the amount of them is like a dozen.
> >
> > I reviewed the patch, so you can look into that yourself and decide.
> 
> I looked at it and some of the comments are pretty serious and need
> addressing ASAP.
> 

Thanks for reviewing the patch.

Please kindly leave review comments if it doesn't take too much time for you.
I just want to ensure that I won't miss anything.

> However it only affects this hardware so it's not like it's breaking the
> world. I generally prefer in-tree development over too many big patch
> iterations, it gets more focused.
> 
> I think if Chester can follow up with a patch or several addressing the
> comments in the next week or two that's fine.
> 

I will do my best to solve it.

Thanks,
Chester

> However if we get closer to -rc6 and nothing has happened I would
> not be so happy and then I might just revert the driver patch.
> 
> Yours,
> Linus Walleij

On Tue, Mar 07, 2023 at 09:09:59PM +0800, Chester Lin wrote:
> Hi Linus and Andy,
> 
> On Tue, Mar 07, 2023 at 01:49:00PM +0100, Linus Walleij wrote:
> > On Tue, Mar 7, 2023 at 10:56 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Tue, Mar 7, 2023 at 11:22 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > On Tue, Mar 7, 2023 at 12:28 AM <andy.shevchenko@gmail.com> wrote:
> > >
> > > ...
> > >
> > > > > Can you unpull this?
> > >
> > > > If need be.
> > > >
> > > > Are there serious issues with the patch set such that they cannot be fixed
> > > > by add-on patches?
> > >
> > > There are a few absent error checks, some error code shadowing, etc.
> > > I can't tell if these all are serious, but the amount of them is like a dozen.
> > >
> > > I reviewed the patch, so you can look into that yourself and decide.
> > 
> > I looked at it and some of the comments are pretty serious and need
> > addressing ASAP.
> > 
> 
> Thanks for reviewing the patch.
> 
> Please kindly leave review comments if it doesn't take too much time for you.
> I just want to ensure that I won't miss anything.
> 

Sorry that I just found that my mailbox didn't receive Andy's mail [comments on
v5 2/3]. I will try answering it and come up with a patch ASAP.

Thanks for your patience,
Chester

> > However it only affects this hardware so it's not like it's breaking the
> > world. I generally prefer in-tree development over too many big patch
> > iterations, it gets more focused.
> > 
> > I think if Chester can follow up with a patch or several addressing the
> > comments in the next week or two that's fine.
> > 
> 
> I will do my best to solve it.
> 
> Thanks,
> Chester
> 
> > However if we get closer to -rc6 and nothing has happened I would
> > not be so happy and then I might just revert the driver patch.
> > 
> > Yours,
> > Linus Walleij

On Tue, Mar 7, 2023 at 4:53 PM Chester Lin <clin@suse.com> wrote:

...

> Sorry that I just found that my mailbox didn't receive Andy's mail [comments on
> v5 2/3]. I will try answering it and come up with a patch ASAP.

The thread is available here:
https://lore.kernel.org/all/20230220023320.3499-1-clin@suse.com/

You can even download it using the `b4` tool (available in your distro
quite likely).

-- 
With Best Regards,
Andy Shevchenko