archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <>
To: Benjamin Herrenschmidt <>
Cc: Andrew Jeffery <>,
	Mark Rutland <>,,
	 Greg Kroah-Hartman <>,,,
	 "" <>,
	Joel Stanley <>,,
	 OpenBMC Maillist <>,
Subject: Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields
Date: Wed, 18 Jul 2018 13:50:56 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jul 16, 2018 at 10:56 PM Benjamin Herrenschmidt
<> wrote:
> On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> > If that data is one set per SoC, then i'm not that concerned having
> > platform-specific data in the driver. That doesn't mean the driver is
> > not "generic". It's still not clear to me in this thread, how much of
> > this is board specific, but given that you've placed all the data in
> > an SoC dtsi file it seems to be all per SoC.
> So Rob, I think that's precisely where the disconnect is.
> I think we all (well hopefully) agree that those few tunables don't fit
> in any existing subystem and aren't likely to ever do (famous last
> words...).
> Where we disagree is we want to make this parametrized via the DT, and
> you want us to hard wire the list in some kind of SoC driver for a
> given SoC family/version.
> The reason I think hard wiring the list in the driver is not a great
> solution is that that list in itself is prone to variations, possibly
> fairly often, between boards, vendors, versions of boards, etc...

Can we separate the list of what's enabled from the details of the
registers?  Even if we put all this into DT, we may still want to have
some separation for dts file structure. Some portion of this has to be
SoC specific because you are simply exposing SoC registers.

> We can't know for sure every SoC tunable (out of the gazillions in
> those chips) are going to be needed for a given system. We know which
> ones we do use for ours, and that's a couple of handfuls, but it could
> be that Dell need a slightly different set, and so might Yadro, or so
> might our next board revision for that matter.

That's very hand wavy. Do you have some concrete examples (i.e. dts
files) showing the differences.

One problem I'm having with this is you are still going to need per
board specifics in userspace. You may be moving some of details out,
but moving to DT is not going to completely eliminate that. I agree
that not using /dev/mem is a good thing, but there are several ways
you could do that independent of any DT binding.

> Now, updating the device-tree in the board flash with whatever vendor
> specific information is needed is a LOT easier than getting the kernel
> driver constantly updated. The device-tree after all is there to
> reflect among other things system specific ways in which the SoC is
> wired and configured. This is rather close...

Sadly, updating my kernel is easier than updating my PC firmware
(though packaged firmware on my current laptop changes that). I can
assure you that ARM boards are generally much worse in that regard.
BTW, you may want to pay attention to EBBR[1][2]. Not sure how much
you care for BMCs, but there may be some interest.



  parent reply	other threads:[~2018-07-18 19:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11  5:31 [RFC PATCH v2 0/4] sysfs interface to miscellaneous BMC controls and fields Andrew Jeffery
2018-07-11  5:31 ` [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields Andrew Jeffery
2018-07-11 20:04   ` Rob Herring
2018-07-12  0:14     ` Benjamin Herrenschmidt
2018-07-12  0:53     ` Andrew Jeffery
2018-07-12 15:11       ` Rob Herring
2018-07-13  0:55         ` Benjamin Herrenschmidt
2018-07-13  6:31           ` Andrew Jeffery
2018-07-13 15:14             ` Alexander Amelkin
2018-07-13 18:49               ` Eugene.Cho
2018-07-13 19:03                 ` Greg KH
2018-07-13 19:06                   ` Eugene.Cho
2018-07-15 14:21                     ` Avi Fishman
2018-07-16  0:57               ` Andrew Jeffery
2018-07-16 13:55             ` Rob Herring
2018-07-17  1:04               ` Andrew Jeffery
2018-07-17  4:56               ` Benjamin Herrenschmidt
2018-07-17 23:28                 ` Andrew Jeffery
2018-07-18 19:07                   ` Rob Herring
2018-07-19  1:57                     ` Andrew Jeffery
2018-07-18 19:50                 ` Rob Herring [this message]
2018-07-18 23:58                   ` Benjamin Herrenschmidt
2018-07-19  2:28                     ` Andrew Jeffery
2018-07-19  4:35                       ` Benjamin Herrenschmidt
2018-07-20  0:07                         ` Andrew Jeffery
2018-07-20  4:56                           ` Benjamin Herrenschmidt
2018-08-10  0:22                             ` Kun Yi
2018-08-23 15:32                           ` Alexander Amelkin
2018-07-11  5:31 ` [RFC PATCH v2 2/4] Documentation: ABI: Add sysfs-devices-platform-field to testing Andrew Jeffery
2018-07-11  5:31 ` [RFC PATCH v2 3/4] misc: Add bmc-misc-ctrl Andrew Jeffery
2018-07-11  5:31 ` [RFC PATCH v2 4/4] dts: aspeed-g5: Describe VGA, SIO scratch and DAC mux fields 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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).