[GIT,PULL] ARM: soc: Marvell MMP changes for v5.5
mbox series

Message ID 5104777b69d711e8746f3c39dfac615f85d64b3f.camel@v3.sk
State New
Headers show
Series
  • [GIT,PULL] ARM: soc: Marvell MMP changes for v5.5
Related show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git tags/mmp-soc-for-v5.5

Message

Lubomir Rintel Oct. 1, 2019, 10:51 a.m. UTC
Hi,

I'd be very thankful if you pulled the tree with Marvell MMP SoC changes into
the Arm SoC branch targetting v5.5.

The contents of the tree is essentially just the v3 of "Initial support
for Marvell MMP3 SoC" patch set. There are three changes:

- Fix for a kbuild test bot error on x86_64
- Removed the aliases from the DTS tree
- Added reference the Git tree I'm asking you to pull from to the
  MAINTAINERS file

The tree has been tested on a Dell Wyse 3020 thin client, and also tested not
to ruin the existing MMP support on an OLPC XO-1.75 laptop.

Thank you
Lubo

The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:

  Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git tags/mmp-soc-for-v5.5

for you to fetch changes up to de7d5a2bfcaa1cb5f62d5bb4dfbbb066ff7dd06e:

  MAINTAINERS: mmp: add Git repository (2019-10-01 11:20:50 +0200)

----------------------------------------------------------------
ARM: Marvell MMP patches for v5.5

This tag includes initial support for the Marvell MMP3 processor.

MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad FZ-A1 tablet
and Dell Wyse 3020/Tx0D thin clients.

----------------------------------------------------------------
Lubomir Rintel (17):
      dt-bindings: arm: cpu: Add Marvell MMP3 SMP enable method
      dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
      dt-bindings: arm: mrvl: Document MMP3 compatible string
      dt-bindings: mrvl,intc: Add a MMP3 interrupt controller
      dt-bindings: phy-mmp3-usb: Add bindings
      ARM: l2c: add definition for FWA in PL310 aux register
      ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMP
      ARM: mmp: map the PGU as well
      ARM: mmp: DT: convert timer driver to use TIMER_OF_DECLARE
      ARM: mmp: define MMP_CHIPID by the means of CIU_REG()
      ARM: mmp: add support for MMP3 SoC
      ARM: mmp: add SMP support
      ARM: mmp: move cputype.h to include/linux/soc/
      ARM: mmp: remove MMP3 USB PHY registers from regs-usb.h
      phy: phy-mmp3-usb: add a new driver
      ARM: dts: mmp3: Add MMP3 SoC dts file
      MAINTAINERS: mmp: add Git repository

 Documentation/devicetree/bindings/arm/cpus.yaml    |   1 +
 .../devicetree/bindings/arm/mrvl/mrvl.txt          |  14 -
 .../devicetree/bindings/arm/mrvl/mrvl.yaml         |  35 ++
 .../bindings/interrupt-controller/mrvl,intc.txt    |  14 +-
 .../devicetree/bindings/phy/phy-mmp3-usb.txt       |  13 +
 MAINTAINERS                                        |   9 +
 arch/arm/boot/dts/mmp3.dtsi                        | 527 +++++++++++++++++++++
 arch/arm/include/asm/hardware/cache-l2x0.h         |   2 +
 arch/arm/mach-mmp/Kconfig                          |  22 +-
 arch/arm/mach-mmp/Makefile                         |   4 +
 arch/arm/mach-mmp/addr-map.h                       |   7 +
 arch/arm/mach-mmp/common.c                         |  19 +-
 arch/arm/mach-mmp/common.h                         |   1 +
 arch/arm/mach-mmp/devices.c                        |   2 +-
 arch/arm/mach-mmp/mmp-dt.c                         |   5 +-
 arch/arm/mach-mmp/mmp2-dt.c                        |   7 +-
 arch/arm/mach-mmp/mmp2.c                           |   2 +-
 arch/arm/mach-mmp/mmp3.c                           |  29 ++
 arch/arm/mach-mmp/platsmp.c                        |  32 ++
 arch/arm/mach-mmp/pm-mmp2.c                        |   2 +-
 arch/arm/mach-mmp/pm-pxa910.c                      |   2 +-
 arch/arm/mach-mmp/pxa168.c                         |   2 +-
 arch/arm/mach-mmp/pxa910.c                         |   2 +-
 arch/arm/mach-mmp/regs-usb.h                       |  94 ----
 arch/arm/mach-mmp/time.c                           |  43 +-
 arch/arm/mm/Kconfig                                |   2 +-
 drivers/clk/Kconfig                                |   5 +
 drivers/clk/mmp/Makefile                           |   2 +-
 drivers/phy/marvell/Kconfig                        |  11 +
 drivers/phy/marvell/Makefile                       |   1 +
 drivers/phy/marvell/phy-mmp3-usb.c                 | 291 ++++++++++++
 include/Kbuild                                     |   1 +
 .../mach-mmp => include/linux/soc/mmp}/cputype.h   |  27 ++
 33 files changed, 1069 insertions(+), 161 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mmp3-usb.txt
 create mode 100644 arch/arm/boot/dts/mmp3.dtsi
 create mode 100644 arch/arm/mach-mmp/mmp3.c
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 drivers/phy/marvell/phy-mmp3-usb.c
 rename {arch/arm/mach-mmp => include/linux/soc/mmp}/cputype.h (71%)

Comments

Olof Johansson Oct. 2, 2019, 8:11 p.m. UTC | #1
Hi,

Thanks for sending these in. A couple of items I think needs addressing:

1) The MAINTAINERS update seems to have an erroneous entry for
"linux/soc/mmp/" -- other platforms use "include/linux/soc/mmp/"
format.

2) I don't see any Acks from the subsystem maintainers for the code
you've changed, in particular for phy-mmp3-usb. Ideally you should
collect acks from said maintainers if you want to merge the patches
yourself.

3) We prefer to see contents broken up a bit more. Normally we ask for
these categories to be separate:
 - Any branch contents that you need to share with patches going in
through another tree (this is usually dt-binding include file changes
these days)
 - arch/arm/mach*  and drivers/soc/ changes (these go into our "arm/soc" branch)
 - device-tree changes (these go into our "arm/dt" branch)
 - driver subsystem changes if merged through our tree (these go into
"arm/drivers"). If there's no good reason to merge them with other
contents and they can go in through driver maintainer trees without
regressing anybody, that's preferred.
 - configuration changes (defconfig updates). Speaking of which,
MACH_MMP3_DT should be enabled in multi_v7_defconfig I think.

Maybe this seems like a lot of awkward sorting, and in some cases it's
overkill to do it. But if you think you'll keep sending in more
contributions over time, it's useful to get familiar with the
workflow.


For now, there's really two actions and a question:
 1) Fixup the MAINTAINERS entry
 2) Make sure you send the driver patches to the right places and
collect acks (or get them to pick them up)

Then, beyond that I'll leave it up to you on what to do, whether you
want to send a few pull requests, or -- if you don't have any
downstream users to your tree -- we can also cherry-pick patches apart
(or you can send us the series of patches and we can apply them).


-Olof


On Tue, Oct 1, 2019 at 3:51 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Hi,
>
> I'd be very thankful if you pulled the tree with Marvell MMP SoC changes into
> the Arm SoC branch targetting v5.5.
>
> The contents of the tree is essentially just the v3 of "Initial support
> for Marvell MMP3 SoC" patch set. There are three changes:
>
> - Fix for a kbuild test bot error on x86_64
> - Removed the aliases from the DTS tree
> - Added reference the Git tree I'm asking you to pull from to the
>   MAINTAINERS file
>
> The tree has been tested on a Dell Wyse 3020 thin client, and also tested not
> to ruin the existing MMP support on an OLPC XO-1.75 laptop.
>
> Thank you
> Lubo
>
> The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
>
>   Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git tags/mmp-soc-for-v5.5
>
> for you to fetch changes up to de7d5a2bfcaa1cb5f62d5bb4dfbbb066ff7dd06e:
>
>   MAINTAINERS: mmp: add Git repository (2019-10-01 11:20:50 +0200)
>
> ----------------------------------------------------------------
> ARM: Marvell MMP patches for v5.5
>
> This tag includes initial support for the Marvell MMP3 processor.
>
> MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad FZ-A1 tablet
> and Dell Wyse 3020/Tx0D thin clients.
>
> ----------------------------------------------------------------
> Lubomir Rintel (17):
>       dt-bindings: arm: cpu: Add Marvell MMP3 SMP enable method
>       dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
>       dt-bindings: arm: mrvl: Document MMP3 compatible string
>       dt-bindings: mrvl,intc: Add a MMP3 interrupt controller
>       dt-bindings: phy-mmp3-usb: Add bindings
>       ARM: l2c: add definition for FWA in PL310 aux register
>       ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMP
>       ARM: mmp: map the PGU as well
>       ARM: mmp: DT: convert timer driver to use TIMER_OF_DECLARE
>       ARM: mmp: define MMP_CHIPID by the means of CIU_REG()
>       ARM: mmp: add support for MMP3 SoC
>       ARM: mmp: add SMP support
>       ARM: mmp: move cputype.h to include/linux/soc/
>       ARM: mmp: remove MMP3 USB PHY registers from regs-usb.h
>       phy: phy-mmp3-usb: add a new driver
>       ARM: dts: mmp3: Add MMP3 SoC dts file
>       MAINTAINERS: mmp: add Git repository
>
>  Documentation/devicetree/bindings/arm/cpus.yaml    |   1 +
>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |  14 -
>  .../devicetree/bindings/arm/mrvl/mrvl.yaml         |  35 ++
>  .../bindings/interrupt-controller/mrvl,intc.txt    |  14 +-
>  .../devicetree/bindings/phy/phy-mmp3-usb.txt       |  13 +
>  MAINTAINERS                                        |   9 +
>  arch/arm/boot/dts/mmp3.dtsi                        | 527 +++++++++++++++++++++
>  arch/arm/include/asm/hardware/cache-l2x0.h         |   2 +
>  arch/arm/mach-mmp/Kconfig                          |  22 +-
>  arch/arm/mach-mmp/Makefile                         |   4 +
>  arch/arm/mach-mmp/addr-map.h                       |   7 +
>  arch/arm/mach-mmp/common.c                         |  19 +-
>  arch/arm/mach-mmp/common.h                         |   1 +
>  arch/arm/mach-mmp/devices.c                        |   2 +-
>  arch/arm/mach-mmp/mmp-dt.c                         |   5 +-
>  arch/arm/mach-mmp/mmp2-dt.c                        |   7 +-
>  arch/arm/mach-mmp/mmp2.c                           |   2 +-
>  arch/arm/mach-mmp/mmp3.c                           |  29 ++
>  arch/arm/mach-mmp/platsmp.c                        |  32 ++
>  arch/arm/mach-mmp/pm-mmp2.c                        |   2 +-
>  arch/arm/mach-mmp/pm-pxa910.c                      |   2 +-
>  arch/arm/mach-mmp/pxa168.c                         |   2 +-
>  arch/arm/mach-mmp/pxa910.c                         |   2 +-
>  arch/arm/mach-mmp/regs-usb.h                       |  94 ----
>  arch/arm/mach-mmp/time.c                           |  43 +-
>  arch/arm/mm/Kconfig                                |   2 +-
>  drivers/clk/Kconfig                                |   5 +
>  drivers/clk/mmp/Makefile                           |   2 +-
>  drivers/phy/marvell/Kconfig                        |  11 +
>  drivers/phy/marvell/Makefile                       |   1 +
>  drivers/phy/marvell/phy-mmp3-usb.c                 | 291 ++++++++++++
>  include/Kbuild                                     |   1 +
>  .../mach-mmp => include/linux/soc/mmp}/cputype.h   |  27 ++
>  33 files changed, 1069 insertions(+), 161 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-mmp3-usb.txt
>  create mode 100644 arch/arm/boot/dts/mmp3.dtsi
>  create mode 100644 arch/arm/mach-mmp/mmp3.c
>  create mode 100644 arch/arm/mach-mmp/platsmp.c
>  create mode 100644 drivers/phy/marvell/phy-mmp3-usb.c
>  rename {arch/arm/mach-mmp => include/linux/soc/mmp}/cputype.h (71%)
>
Lubomir Rintel Oct. 9, 2019, 1:06 p.m. UTC | #2
Hello,

On Wed, 2019-10-02 at 13:11 -0700, Olof Johansson wrote:
> Hi,
> 
> Thanks for sending these in. A couple of items I think needs addressing:
> 
> 1) The MAINTAINERS update seems to have an erroneous entry for
> "linux/soc/mmp/" -- other platforms use "include/linux/soc/mmp/"
> format.

Thanks for catching this. Will fix.

> 2) I don't see any Acks from the subsystem maintainers for the code
> you've changed, in particular for phy-mmp3-usb. Ideally you should
> collect acks from said maintainers if you want to merge the patches
> yourself.

I'm in the process of getting them.

I'm wondering what's the usual way of getting the attention when the
maintainer won't respond to mails where they're Cc'd. Is it acceptable
to ping them-off list (that is what I've done this time)?

> 3) We prefer to see contents broken up a bit more. Normally we ask for
> these categories to be separate:
>  - Any branch contents that you need to share with patches going in
> through another tree (this is usually dt-binding include file changes
> these days)
>  - arch/arm/mach*  and drivers/soc/ changes (these go into our "arm/soc" branch)
>  - device-tree changes (these go into our "arm/dt" branch)
>  - driver subsystem changes if merged through our tree (these go into
> "arm/drivers"). If there's no good reason to merge them with other
> contents and they can go in through driver maintainer trees without
> regressing anybody, that's preferred.

That is not the case here (apart from the dt changes, which are sort of
independent due to their nature) the latter patches are dependent on
the earlier ones.

The independent patches related to MMP3 (basically the irqchip) went in
separately already.

>  - configuration changes (defconfig updates). Speaking of which,
> MACH_MMP3_DT should be enabled in multi_v7_defconfig I think.

Yes. The defconfig changes are independent and I intend to submit them
separately.

My previous attempt to get a defconfig change applied (that would be
CONFIG_MACH_MMP2_DT [1]) was not successful, which I was not sending
more, at least I verify that I send it in the correct direction.

[1] https://lore.kernel.org/lkml/20190828074204.287415-1-lkundrak@v3.sk/

> Maybe this seems like a lot of awkward sorting, and in some cases it's
> overkill to do it. But if you think you'll keep sending in more
> contributions over time, it's useful to get familiar with the
> workflow.

Yes. Thanks for taking time to explain this to me.

> For now, there's really two actions and a question:
>  1) Fixup the MAINTAINERS entry
>  2) Make sure you send the driver patches to the right places and
> collect acks (or get them to pick them up)
> 
> Then, beyond that I'll leave it up to you on what to do, whether you
> want to send a few pull requests, or -- if you don't have any
> downstream users to your tree -- we can also cherry-pick patches apart
> (or you can send us the series of patches and we can apply them).

I don't really have a preference and I have no idea about downstream
users. I sent a pull request because Arnd suggested I send one [1].

[1] https://lore.kernel.org/lkml/CAK8P3a0Jq93AVYau_7odZz73ZL22buVCveiHoC6oGf=Oy6KEKQ@mail.gmail.com/

> -Olof
> 
> 
> On Tue, Oct 1, 2019 at 3:51 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
> > Hi,
> > 
> > I'd be very thankful if you pulled the tree with Marvell MMP SoC changes into
> > the Arm SoC branch targetting v5.5.
> > 
> > The contents of the tree is essentially just the v3 of "Initial support
> > for Marvell MMP3 SoC" patch set. There are three changes:
> > 
> > - Fix for a kbuild test bot error on x86_64
> > - Removed the aliases from the DTS tree
> > - Added reference the Git tree I'm asking you to pull from to the
> >   MAINTAINERS file
> > 
> > The tree has been tested on a Dell Wyse 3020 thin client, and also tested not
> > to ruin the existing MMP support on an OLPC XO-1.75 laptop.
> > 
> > Thank you
> > Lubo
> > 
> > The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
> > 
> >   Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
> > 
> > are available in the Git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git tags/mmp-soc-for-v5.5
> > 
> > for you to fetch changes up to de7d5a2bfcaa1cb5f62d5bb4dfbbb066ff7dd06e:
> > 
> >   MAINTAINERS: mmp: add Git repository (2019-10-01 11:20:50 +0200)
> > 
> > ----------------------------------------------------------------
> > ARM: Marvell MMP patches for v5.5
> > 
> > This tag includes initial support for the Marvell MMP3 processor.
> > 
> > MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad FZ-A1 tablet
> > and Dell Wyse 3020/Tx0D thin clients.
> > 
> > ----------------------------------------------------------------
> > Lubomir Rintel (17):
> >       dt-bindings: arm: cpu: Add Marvell MMP3 SMP enable method
> >       dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
> >       dt-bindings: arm: mrvl: Document MMP3 compatible string
> >       dt-bindings: mrvl,intc: Add a MMP3 interrupt controller
> >       dt-bindings: phy-mmp3-usb: Add bindings
> >       ARM: l2c: add definition for FWA in PL310 aux register
> >       ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMP
> >       ARM: mmp: map the PGU as well
> >       ARM: mmp: DT: convert timer driver to use TIMER_OF_DECLARE
> >       ARM: mmp: define MMP_CHIPID by the means of CIU_REG()
> >       ARM: mmp: add support for MMP3 SoC
> >       ARM: mmp: add SMP support
> >       ARM: mmp: move cputype.h to include/linux/soc/
> >       ARM: mmp: remove MMP3 USB PHY registers from regs-usb.h
> >       phy: phy-mmp3-usb: add a new driver
> >       ARM: dts: mmp3: Add MMP3 SoC dts file
> >       MAINTAINERS: mmp: add Git repository
> > 
> >  Documentation/devicetree/bindings/arm/cpus.yaml    |   1 +
> >  .../devicetree/bindings/arm/mrvl/mrvl.txt          |  14 -
> >  .../devicetree/bindings/arm/mrvl/mrvl.yaml         |  35 ++
> >  .../bindings/interrupt-controller/mrvl,intc.txt    |  14 +-
> >  .../devicetree/bindings/phy/phy-mmp3-usb.txt       |  13 +
> >  MAINTAINERS                                        |   9 +
> >  arch/arm/boot/dts/mmp3.dtsi                        | 527 +++++++++++++++++++++
> >  arch/arm/include/asm/hardware/cache-l2x0.h         |   2 +
> >  arch/arm/mach-mmp/Kconfig                          |  22 +-
> >  arch/arm/mach-mmp/Makefile                         |   4 +
> >  arch/arm/mach-mmp/addr-map.h                       |   7 +
> >  arch/arm/mach-mmp/common.c                         |  19 +-
> >  arch/arm/mach-mmp/common.h                         |   1 +
> >  arch/arm/mach-mmp/devices.c                        |   2 +-
> >  arch/arm/mach-mmp/mmp-dt.c                         |   5 +-
> >  arch/arm/mach-mmp/mmp2-dt.c                        |   7 +-
> >  arch/arm/mach-mmp/mmp2.c                           |   2 +-
> >  arch/arm/mach-mmp/mmp3.c                           |  29 ++
> >  arch/arm/mach-mmp/platsmp.c                        |  32 ++
> >  arch/arm/mach-mmp/pm-mmp2.c                        |   2 +-
> >  arch/arm/mach-mmp/pm-pxa910.c                      |   2 +-
> >  arch/arm/mach-mmp/pxa168.c                         |   2 +-
> >  arch/arm/mach-mmp/pxa910.c                         |   2 +-
> >  arch/arm/mach-mmp/regs-usb.h                       |  94 ----
> >  arch/arm/mach-mmp/time.c                           |  43 +-
> >  arch/arm/mm/Kconfig                                |   2 +-
> >  drivers/clk/Kconfig                                |   5 +
> >  drivers/clk/mmp/Makefile                           |   2 +-
> >  drivers/phy/marvell/Kconfig                        |  11 +
> >  drivers/phy/marvell/Makefile                       |   1 +
> >  drivers/phy/marvell/phy-mmp3-usb.c                 | 291 ++++++++++++
> >  include/Kbuild                                     |   1 +
> >  .../mach-mmp => include/linux/soc/mmp}/cputype.h   |  27 ++
> >  33 files changed, 1069 insertions(+), 161 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> >  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> >  create mode 100644 Documentation/devicetree/bindings/phy/phy-mmp3-usb.txt
> >  create mode 100644 arch/arm/boot/dts/mmp3.dtsi
> >  create mode 100644 arch/arm/mach-mmp/mmp3.c
> >  create mode 100644 arch/arm/mach-mmp/platsmp.c
> >  create mode 100644 drivers/phy/marvell/phy-mmp3-usb.c
> >  rename {arch/arm/mach-mmp => include/linux/soc/mmp}/cputype.h (71%)
> >
Olof Johansson Oct. 9, 2019, 3:16 p.m. UTC | #3
On Wed, Oct 9, 2019 at 6:06 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> Hello,
>
> On Wed, 2019-10-02 at 13:11 -0700, Olof Johansson wrote:
> > Hi,
> >
> > Thanks for sending these in. A couple of items I think needs addressing:
> >
> > 1) The MAINTAINERS update seems to have an erroneous entry for
> > "linux/soc/mmp/" -- other platforms use "include/linux/soc/mmp/"
> > format.
>
> Thanks for catching this. Will fix.
>
> > 2) I don't see any Acks from the subsystem maintainers for the code
> > you've changed, in particular for phy-mmp3-usb. Ideally you should
> > collect acks from said maintainers if you want to merge the patches
> > yourself.
>
> I'm in the process of getting them.

Great!

> I'm wondering what's the usual way of getting the attention when the
> maintainer won't respond to mails where they're Cc'd. Is it acceptable
> to ping them-off list (that is what I've done this time)?

Eventually you will time out. At that point, make sure you have an
accurate "Cc: [... maintainer ...]" in the S-o-b sequence, to show
that you kept them in the loop.

If you apply the patch with a link to the posting, others can easily
find where/how you posted it if they want to look at email thread
history as well.

Sometimes for "simpler", more hardware-specific patches, general
driver subsystem maintainers don't pay very close attention due to
volume, etc.

> > 3) We prefer to see contents broken up a bit more. Normally we ask for
> > these categories to be separate:
> >  - Any branch contents that you need to share with patches going in
> > through another tree (this is usually dt-binding include file changes
> > these days)
> >  - arch/arm/mach*  and drivers/soc/ changes (these go into our "arm/soc" branch)
> >  - device-tree changes (these go into our "arm/dt" branch)
> >  - driver subsystem changes if merged through our tree (these go into
> > "arm/drivers"). If there's no good reason to merge them with other
> > contents and they can go in through driver maintainer trees without
> > regressing anybody, that's preferred.
>
> That is not the case here (apart from the dt changes, which are sort of
> independent due to their nature) the latter patches are dependent on
> the earlier ones.
>
> The independent patches related to MMP3 (basically the irqchip) went in
> separately already.

Ok! In that case, I propose still building separate branches, but you
can use the dependencies as your base.

I.e. if you need mach changes as base for the driver changes, still
send separate pull requests for the two of them, but you can use your
mach branch as base for the driver branch.

That allows us to still merge per topic, but bring dependencies in.
This also works (but requires careful coordination) if you want an
external maintainer to bring in a branch that depends on something in
our tree. Reach out to us before you go down that route the first time
though (and I don't think that is needed here/yet).


> >  - configuration changes (defconfig updates). Speaking of which,
> > MACH_MMP3_DT should be enabled in multi_v7_defconfig I think.
>
> Yes. The defconfig changes are independent and I intend to submit them
> separately.

Sounds good. For those, you can send just a patch if you want (if it
is just one patch), no need to send a pull request. Up to you what's
easier at your end.

> My previous attempt to get a defconfig change applied (that would be
> CONFIG_MACH_MMP2_DT [1]) was not successful, which I was not sending
> more, at least I verify that I send it in the correct direction.
>
> [1] https://lore.kernel.org/lkml/20190828074204.287415-1-lkundrak@v3.sk/

That patch looks fine, I must have missed it since it wasn't sent to
soc@kernel.org.

Only comment is that you probably don't what the SERIAL_8250_PXA
option as a module, since you likely want it for boot console?


> > Maybe this seems like a lot of awkward sorting, and in some cases it's
> > overkill to do it. But if you think you'll keep sending in more
> > contributions over time, it's useful to get familiar with the
> > workflow.
>
> Yes. Thanks for taking time to explain this to me.
>
> > For now, there's really two actions and a question:
> >  1) Fixup the MAINTAINERS entry
> >  2) Make sure you send the driver patches to the right places and
> > collect acks (or get them to pick them up)
> >
> > Then, beyond that I'll leave it up to you on what to do, whether you
> > want to send a few pull requests, or -- if you don't have any
> > downstream users to your tree -- we can also cherry-pick patches apart
> > (or you can send us the series of patches and we can apply them).
>
> I don't really have a preference and I have no idea about downstream
> users. I sent a pull request because Arnd suggested I send one [1].
>
> [1] https://lore.kernel.org/lkml/CAK8P3a0Jq93AVYau_7odZz73ZL22buVCveiHoC6oGf=Oy6KEKQ@mail.gmail.com/

Ok, that's fine. For now, I suggest you make an attempt to prepare the
patches as above to get used to it, and if you think it's too much
work just let us know and we can show how we'd sort it (by doing the
cherry-picks).

And thanks for your efforts so far on getting the MMP platforms better
supported!


-Olof
Lubomir Rintel Oct. 17, 2019, 2:28 p.m. UTC | #4
On Wed, 2019-10-09 at 08:16 -0700, Olof Johansson wrote:
> On Wed, Oct 9, 2019 at 6:06 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
> > Hello,
> > 
> > On Wed, 2019-10-02 at 13:11 -0700, Olof Johansson wrote:
> > > Hi,
> > > 
> > > Thanks for sending these in. A couple of items I think needs addressing:
> > > 
> > > 1) The MAINTAINERS update seems to have an erroneous entry for
> > > "linux/soc/mmp/" -- other platforms use "include/linux/soc/mmp/"
> > > format.
> > 
> > Thanks for catching this. Will fix.
> > 
> > > 2) I don't see any Acks from the subsystem maintainers for the code
> > > you've changed, in particular for phy-mmp3-usb. Ideally you should
> > > collect acks from said maintainers if you want to merge the patches
> > > yourself.
> > 
> > I'm in the process of getting them.
> 
> Great!
> 
> > I'm wondering what's the usual way of getting the attention when the
> > maintainer won't respond to mails where they're Cc'd. Is it acceptable
> > to ping them-off list (that is what I've done this time)?
> 
> Eventually you will time out. At that point, make sure you have an
> accurate "Cc: [... maintainer ...]" in the S-o-b sequence, to show
> that you kept them in the loop.
> 
> If you apply the patch with a link to the posting, others can easily
> find where/how you posted it if they want to look at email thread
> history as well.
> 
> Sometimes for "simpler", more hardware-specific patches, general
> driver subsystem maintainers don't pay very close attention due to
> volume, etc.\

Thanks for I suggestion. I got an ack Kishon (along with some
suggestions about commit message wording) now and he's been quick to
respond before.

> > > 3) We prefer to see contents broken up a bit more. Normally we ask for
> > > these categories to be separate:
> > >  - Any branch contents that you need to share with patches going in
> > > through another tree (this is usually dt-binding include file changes
> > > these days)
> > >  - arch/arm/mach*  and drivers/soc/ changes (these go into our "arm/soc" branch)
> > >  - device-tree changes (these go into our "arm/dt" branch)
> > >  - driver subsystem changes if merged through our tree (these go into
> > > "arm/drivers"). If there's no good reason to merge them with other
> > > contents and they can go in through driver maintainer trees without
> > > regressing anybody, that's preferred.
> > 
> > That is not the case here (apart from the dt changes, which are sort of
> > independent due to their nature) the latter patches are dependent on
> > the earlier ones.
> > 
> > The independent patches related to MMP3 (basically the irqchip) went in
> > separately already.
> 
> Ok! In that case, I propose still building separate branches, but you
> can use the dependencies as your base.
> 
> I.e. if you need mach changes as base for the driver changes, still
> send separate pull requests for the two of them, but you can use your
> mach branch as base for the driver branch.

Okay, I'll try to do just that.

> That allows us to still merge per topic, but bring dependencies in.
> This also works (but requires careful coordination) if you want an
> external maintainer to bring in a branch that depends on something in
> our tree. Reach out to us before you go down that route the first time
> though (and I don't think that is needed here/yet).
> 
> 
> > >  - configuration changes (defconfig updates). Speaking of which,
> > > MACH_MMP3_DT should be enabled in multi_v7_defconfig I think.
> > 
> > Yes. The defconfig changes are independent and I intend to submit them
> > separately.
> 
> Sounds good. For those, you can send just a patch if you want (if it
> is just one patch), no need to send a pull request. Up to you what's
> easier at your end.
> 
> > My previous attempt to get a defconfig change applied (that would be
> > CONFIG_MACH_MMP2_DT [1]) was not successful, which I was not sending
> > more, at least I verify that I send it in the correct direction.
> > 
> > [1] https://lore.kernel.org/lkml/20190828074204.287415-1-lkundrak@v3.sk/
> 
> That patch looks fine, I must have missed it since it wasn't sent to
> soc@kernel.org.
> 
> Only comment is that you probably don't what the SERIAL_8250_PXA
> option as a module, since you likely want it for boot console?

Actually, think it's not needed at all; CONFIG_SERIAL_8250 with
CONFIG_SERIAL_OF_PLATFORM will do. I'll drop it.

I'll also amend it with the MMP3 option and send it in as a separate
patch.

> > > Maybe this seems like a lot of awkward sorting, and in some cases it's
> > > overkill to do it. But if you think you'll keep sending in more
> > > contributions over time, it's useful to get familiar with the
> > > workflow.
> > 
> > Yes. Thanks for taking time to explain this to me.
> > 
> > > For now, there's really two actions and a question:
> > >  1) Fixup the MAINTAINERS entry
> > >  2) Make sure you send the driver patches to the right places and
> > > collect acks (or get them to pick them up)
> > > 
> > > Then, beyond that I'll leave it up to you on what to do, whether you
> > > want to send a few pull requests, or -- if you don't have any
> > > downstream users to your tree -- we can also cherry-pick patches apart
> > > (or you can send us the series of patches and we can apply them).
> > 
> > I don't really have a preference and I have no idea about downstream
> > users. I sent a pull request because Arnd suggested I send one [1].
> > 
> > [1] https://lore.kernel.org/lkml/CAK8P3a0Jq93AVYau_7odZz73ZL22buVCveiHoC6oGf=Oy6KEKQ@mail.gmail.com/
> 
> Ok, that's fine. For now, I suggest you make an attempt to prepare the
> patches as above to get used to it, and if you think it's too much
> work just let us know and we can show how we'd sort it (by doing the
> cherry-picks).
> 
> And thanks for your efforts so far on getting the MMP platforms better
> supported!

Thank you

Lubo