All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Vadot <manu@bidouilliste.com>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	linux-sunxi@googlegroups.com, Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control
Date: Mon, 20 Aug 2018 09:42:10 +0200	[thread overview]
Message-ID: <20180820094210.6d856029d51dad480782a783@bidouilliste.com> (raw)
In-Reply-To: <20180614153548.9644-1-wens@csie.org>


 Hello Chen-Yu,

On Thu, 14 Jun 2018 23:35:44 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> Hi,
> 
> This series is the remaining A64 syscon changes from the R40 DWMAC
> series. The series aligns how the A64 system control exports a regmap
> for the sun8i DWMAC driver to access with what we've done for the R40.
> 
> Originally the A64 used the generic syscon for this bit of hardware.
> But this block also contains mapping bits for the onboard SRAM, used
> by various peripherals, and other vendor specific bits we may use in
> the future. It is by no means generic. And we already have a device
> tree binding and driver for the SRAM part.
> 
> The first patch make the SRAM control device export a regmap, exposing
> a single EMAC control register, for the DWMAC driver to consume.
> 
> The second and third patches rename the A64 compatible string to read
> "system control", which is what the block is named in the user manual.
> 
> The last patch fixes up the device node, and also adds the lone mappable
> SRAM block, which is needed by the Display Engine.
> 
> Changes since v2:
> 
>   - changed the compatible string from "*-sram-controller" to
>     "*-system-control"
> 
> 
> ChenYu
> 
> Chen-Yu Tsai (2):
>   dt-bindings: sram: Rename A64 SRAM controller compatible
>   soc: sunxi: sram: Add updated compatible string for A64 system control
> 
> Icenowy Zheng (2):
>   soc: sunxi: export a regmap for EMAC clock reg on A64
>   arm64: dts: allwinner: a64: add SRAM controller device tree node
> 
>  .../devicetree/bindings/sram/sunxi-sram.txt   |  3 +-
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++++-
>  drivers/soc/sunxi/sunxi_sram.c                | 61 ++++++++++++++++++-
>  3 files changed, 78 insertions(+), 5 deletions(-)
> 
> -- 
> 2.17.1

 I wish to have seen this serie before as it have some inconsistencies.

 In patch 2 you renamed allwinner,sun50i-a64-sram-controller to
allwinner,sun50i-a64-system-control but the former was never used in
the DTS, the compatible used was allwinner,sun50i-a64-system-controller.
 You also say that you've never seen use of it. How can you make that
claim ? There is a lot of downstream users of DTS now (FreeBSD, NetBSD,
OpenBSD and even RiscOS and Haiku iirc), it's not just Linux.
 Also this compatible is currently the one used in the u-boot dts,
which mean that users of the embedded DTB use or can use it (which is
the default for EFI users of U-Boot).

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

WARNING: multiple messages have this Message-ID (diff)
From: manu@bidouilliste.com (Emmanuel Vadot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control
Date: Mon, 20 Aug 2018 09:42:10 +0200	[thread overview]
Message-ID: <20180820094210.6d856029d51dad480782a783@bidouilliste.com> (raw)
In-Reply-To: <20180614153548.9644-1-wens@csie.org>


 Hello Chen-Yu,

On Thu, 14 Jun 2018 23:35:44 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> Hi,
> 
> This series is the remaining A64 syscon changes from the R40 DWMAC
> series. The series aligns how the A64 system control exports a regmap
> for the sun8i DWMAC driver to access with what we've done for the R40.
> 
> Originally the A64 used the generic syscon for this bit of hardware.
> But this block also contains mapping bits for the onboard SRAM, used
> by various peripherals, and other vendor specific bits we may use in
> the future. It is by no means generic. And we already have a device
> tree binding and driver for the SRAM part.
> 
> The first patch make the SRAM control device export a regmap, exposing
> a single EMAC control register, for the DWMAC driver to consume.
> 
> The second and third patches rename the A64 compatible string to read
> "system control", which is what the block is named in the user manual.
> 
> The last patch fixes up the device node, and also adds the lone mappable
> SRAM block, which is needed by the Display Engine.
> 
> Changes since v2:
> 
>   - changed the compatible string from "*-sram-controller" to
>     "*-system-control"
> 
> 
> ChenYu
> 
> Chen-Yu Tsai (2):
>   dt-bindings: sram: Rename A64 SRAM controller compatible
>   soc: sunxi: sram: Add updated compatible string for A64 system control
> 
> Icenowy Zheng (2):
>   soc: sunxi: export a regmap for EMAC clock reg on A64
>   arm64: dts: allwinner: a64: add SRAM controller device tree node
> 
>  .../devicetree/bindings/sram/sunxi-sram.txt   |  3 +-
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++++-
>  drivers/soc/sunxi/sunxi_sram.c                | 61 ++++++++++++++++++-
>  3 files changed, 78 insertions(+), 5 deletions(-)
> 
> -- 
> 2.17.1

 I wish to have seen this serie before as it have some inconsistencies.

 In patch 2 you renamed allwinner,sun50i-a64-sram-controller to
allwinner,sun50i-a64-system-control but the former was never used in
the DTS, the compatible used was allwinner,sun50i-a64-system-controller.
 You also say that you've never seen use of it. How can you make that
claim ? There is a lot of downstream users of DTS now (FreeBSD, NetBSD,
OpenBSD and even RiscOS and Haiku iirc), it's not just Linux.
 Also this compatible is currently the one used in the u-boot dts,
which mean that users of the embedded DTB use or can use it (which is
the default for EFI users of U-Boot).

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

  parent reply	other threads:[~2018-08-20  7:42 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 15:35 [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control Chen-Yu Tsai
2018-06-14 15:35 ` Chen-Yu Tsai
     [not found] ` <20180614153548.9644-1-wens-jdAy2FN1RRM@public.gmane.org>
2018-06-14 15:35   ` [PATCH v3 1/4] soc: sunxi: export a regmap for EMAC clock reg on A64 Chen-Yu Tsai
2018-06-14 15:35     ` Chen-Yu Tsai
2018-06-14 15:35   ` [PATCH v3 2/4] dt-bindings: sram: Rename A64 SRAM controller compatible Chen-Yu Tsai
2018-06-14 15:35     ` Chen-Yu Tsai
     [not found]     ` <20180614153548.9644-3-wens-jdAy2FN1RRM@public.gmane.org>
2018-06-20 18:04       ` Rob Herring
2018-06-20 18:04         ` Rob Herring
2018-06-14 15:35   ` [PATCH v3 3/4] soc: sunxi: sram: Add updated compatible string for A64 system control Chen-Yu Tsai
2018-06-14 15:35     ` Chen-Yu Tsai
2018-06-14 15:35   ` [PATCH v3 4/4] arm64: dts: allwinner: a64: add SRAM controller device tree node Chen-Yu Tsai
2018-06-14 15:35     ` Chen-Yu Tsai
     [not found]     ` <20180614153548.9644-5-wens-jdAy2FN1RRM@public.gmane.org>
2018-06-14 17:09       ` Jagan Teki
2018-06-14 17:09         ` [linux-sunxi] " Jagan Teki
     [not found]         ` <CAMty3ZARNpBOQKvS7knH8kWE2+bvjuJoAA4cFGZK8+GzTUQ5zA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-06-14 17:27           ` Jernej Škrabec
2018-06-14 17:27             ` [linux-sunxi] " Jernej Škrabec
2018-06-14 23:09             ` Icenowy Zheng
2018-06-14 23:09               ` [linux-sunxi] " Icenowy Zheng
     [not found]               ` <5C14D945-0795-4100-86E2-6FBF04350715-h8G6r0blFSE@public.gmane.org>
2018-06-19  7:36                 ` Jagan Teki
2018-06-19  7:36                   ` [linux-sunxi] " Jagan Teki
     [not found]                   ` <CAMty3ZCsPXh7Fhmhtd7UjTmJ9id+NeaZDVqkix1iQz7-fDqoUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-06-19 14:27                     ` Icenowy Zheng
2018-06-19 14:27                       ` [linux-sunxi] " Icenowy Zheng
2018-06-15  9:14   ` [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control Maxime Ripard
2018-06-15  9:14     ` Maxime Ripard
2018-06-18  2:11     ` Chen-Yu Tsai
2018-06-18  2:11       ` Chen-Yu Tsai
     [not found]       ` <CAGb2v64Ar+rOgiXbjtRrQojHUZteLa9N7OwM3XY7ZcpS87Qpmw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-06-18  7:34         ` Maxime Ripard
2018-06-18  7:34           ` Maxime Ripard
2018-06-19 15:20           ` Chen-Yu Tsai
2018-06-19 15:20             ` Chen-Yu Tsai
2018-08-20  7:42 ` Emmanuel Vadot [this message]
2018-08-20  7:42   ` Emmanuel Vadot
     [not found]   ` <20180820094210.6d856029d51dad480782a783-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
2018-08-20  8:41     ` Chen-Yu Tsai
2018-08-20  8:41       ` Chen-Yu Tsai
2018-08-20 14:01       ` Emmanuel Vadot
2018-08-20 14:01         ` Emmanuel Vadot
     [not found]         ` <20180820160149.65771a35c5b46f5ddb483428-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
2018-08-20 14:25           ` Chen-Yu Tsai
2018-08-20 14:25             ` Chen-Yu Tsai
2018-08-20 14:29             ` Emmanuel Vadot
2018-08-20 14:29               ` Emmanuel Vadot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180820094210.6d856029d51dad480782a783@bidouilliste.com \
    --to=manu@bidouilliste.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.