linux-aspeed.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Joel Stanley <joel@jms.id.au>
To: linux-aspeed@lists.ozlabs.org
Subject: [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings
Date: Fri, 2 Aug 2019 05:51:23 +0000	[thread overview]
Message-ID: <CACPK8Xc4Vigeu1B1Su5392BSCSKfoEDqt_tiDtgKmNH5ucAvAg@mail.gmail.com> (raw)
In-Reply-To: <fd8e57f0-aee2-403e-b6fb-76d0c18fe306@www.fastmail.com>

On Tue, 30 Jul 2019 at 01:09, Andrew Jeffery <andrew@aj.id.au> wrote:

> > > The bang-for-buck is in fixing up the KCS bindings which removes all-but-two of
> > > the remaining warnings (which we can't feasibly remove), but doing so forces
> > > code changes (which I'd avoided up until this point).
> > >
> > > Reflecting broadly on the fixes, I think I've made a mistake way back by using
> > > syscon/simple-mfds to expose the innards of the SCU and LPC controllers in the
> > > devicetree. This series cleans up what's currently there, but I have half a
> > > mind to rev the SCU and LPC bindings to not use simple-mfd and instead have a
> > > driver implementation that uses `platform_device_register_full()` or similar to
> > > deal with the mess.
> > >
> > > Rob - I'm looking for your thoughts here and on the series, I've never felt
> > > entirely comfortable with what I cooked up. Your advice would be appreciated.
> >
> > The series generally looks fine to me from a quick scan. As far as
> > dropping 'simple-mfd', having less fine grained description in DT is
> > generally my preference. It comes down to whether what you have
> > defined is maintainable. As most of it is just additions, I think what
> > you have is fine. Maybe keep all this in mind for the next chip
> > depending how the SCU and LPC change.
>
> Okay, I think the timing of that suggestion is good given where things are with
> the AST2600. I'll keep that in mind.
>
> Consensus so far seems to be that the series is fine. I'll split it up and send out
> the sub-series to the relevant lists with the acks accumulated here.

The series look good. I suggest posting the KCS bindings and driver
changes as their own series to go through the IPMI tree.

Please add my tag to all the patches except the OCC one, which I need
to do some investigation in to.

Reviewed-by: Joel Stanley <joel@jms.id.au>

The others can go via the aspeed tree. Perhaps post them as their own
series too so I don't get confused and apply the wrong ones. That way
if Rob wants to send his reviewed-by he can.

Cheers,

Joel

  reply	other threads:[~2019-08-02  5:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  5:39 [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings Andrew Jeffery
2019-07-26  5:39 ` [PATCH 01/17] ARM: dts: aspeed-g5: Move EDAC node to APB Andrew Jeffery
2019-07-29 17:26   ` Stefan Schaeckeler
2019-07-26  5:39 ` [PATCH 02/17] ARM: dts: aspeed-g5: Use recommended generic node name for SDMC Andrew Jeffery
2019-07-29 17:29   ` Stefan Schaeckeler
2019-07-26  5:39 ` [PATCH 03/17] ARM: dts: aspeed-g5: Fix aspeed, external-nodes description Andrew Jeffery
2019-07-26  5:39 ` [PATCH 04/17] ARM: dts: vesnin: Add unit address for memory node Andrew Jeffery
2019-07-26  7:56   ` Alexander A. Filippov
2019-07-26  5:39 ` [PATCH 05/17] ARM: dts: fp5280g2: Cleanup gpio-keys-polled properties Andrew Jeffery
2019-07-26  5:39 ` [PATCH 06/17] ARM: dts: swift: " Andrew Jeffery
2019-07-26 17:53   ` Adriana Kobylak
2019-07-26  5:39 ` [PATCH 07/17] ARM: dts: witherspoon: " Andrew Jeffery
2019-07-26  5:39 ` [PATCH 08/17] ARM: dts: aspeed: Cleanup lpc-ctrl and snoop regs Andrew Jeffery
2019-07-26  5:39 ` [PATCH 09/17] ARM: dts: ibm-power9-dual: Add a unit address for OCC nodes Andrew Jeffery
2019-07-26  5:39 ` [RFC PATCH 10/17] dt-bindings: pinctrl: aspeed: Add reg property as a hint Andrew Jeffery
2019-07-26  5:39 ` [RFC PATCH 11/17] dt-bindings: misc: Document reg for aspeed, p2a-ctrl nodes Andrew Jeffery
2019-07-26  5:39 ` [RFC PATCH 12/17] ARM: dts: aspeed: Add reg hints to syscon children Andrew Jeffery
2019-07-26  5:39 ` [RFC PATCH 13/17] dt-bindings: ipmi: aspeed: Introduce a v2 binding for KCS Andrew Jeffery
2019-07-26  5:39 ` [RFC PATCH 14/17] ipmi: kcs: Finish configuring ASPEED KCS device before enable Andrew Jeffery
2019-07-26 17:04   ` Wang, Haiyue
2019-07-26 17:24     ` Wang, Haiyue
2019-07-26  5:39 ` [RFC PATCH 15/17] ipmi: kcs: aspeed: Implement v2 bindings Andrew Jeffery
2019-07-26 17:30   ` Wang, Haiyue
2019-07-26  5:39 ` [RFC PATCH 16/17] ARM: dts: aspeed-g5: Change KCS nodes to v2 binding Andrew Jeffery
2019-07-26  5:39 ` [RFC PATCH 17/17] ARM: dts: aspeed-g5: Sort LPC child nodes by unit address Andrew Jeffery
2019-07-29 21:55 ` [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings Linus Walleij
2019-07-30  0:49   ` Andrew Jeffery
2019-07-30  0:53 ` Rob Herring
2019-07-30  1:09   ` Andrew Jeffery
2019-08-02  5:51     ` Joel Stanley [this message]
2019-08-05  0:48       ` Andrew Jeffery

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=CACPK8Xc4Vigeu1B1Su5392BSCSKfoEDqt_tiDtgKmNH5ucAvAg@mail.gmail.com \
    --to=joel@jms.id.au \
    --cc=linux-aspeed@lists.ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).