archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <>
To: Andrew Jeffery <>, Rob Herring <>
Cc: 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: Thu, 19 Jul 2018 14:35:24 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 2018-07-19 at 11:58 +0930, Andrew Jeffery wrote:
> > > 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.
> > 
> > Such as ? The only other option is to have one or more kernel drivers
> > that have built-in the precise and complete list of those tunables that
> > need to be exposed.
> > 
> > It's not impossible, but I worry that it's not going to scale terribly
> > well, and that vendors will constantly "fork" that driver to add
> > different things to that list.
> Picking on that last point, "different things" doesn't necessarily
> mean "different fields in the SoC" (though it may). We could just
> need to use different initial values for the fields already
> described. 

I don't worry about initial values too much. Those could be specified
by userspace. It would be trivial to have something akin to
/etc/sysctl.conf that contains the initial values and a script blasting
them early. In fact I prefer this being in userspace to be frank. It
could be in the initramfs if we want it done early enough, maybe with a
usermode helper.

Unless we have some demonstrable reasons why some of these must be set
before the various kernel drivers initialize.

> So taking that into account, the field descriptions could vary wildly
> from platform to platform - where "platform" here is the combination
> of the BMC, its host system, and the host system's required
> configuration - not just referring to the BMC in isolation.  That in
> turn may cause a fork of the driver (changes that are incompatible
> with other platforms), or not scale terribly well as Ben suggests.

I really only worry about the actual set of registers/fields. I think
folding in initial values goes a bit too far.

> The initial value concept can help reduce the impact on userspace as
> userpace may no-longer need to care about it, so I think it's a
> desirable property.

I don't worry too much about userspace containing system specific bits
and pieces such as a config file with the appropriate initial values
for the platform. Userspace will have to contain platform specific
stuff regardless (if anything, stuff like thermal control is
intrinsicly different from one platform to the next).

>  With respect to devicetree, the field definitions will stay in the
> SoC dtsi, but the initial values would be described on a per-platform 
> basis in the dts.

If the fields are in the SoC dtsi, then Rob has a reasonable argument
that the list of fields is rather fixed for a given SoC and thus could
be hard wired in the driver.... 

I think at this stage, we need to create more clarity. In order to do
that, I think we need to come up with a list, as exhaustive as we can,
of what are the fields/register we need for our platforms, and find any
reason why userspace wouldn't be a good enough location to stick the
initial values.

Then we need Dell and Yadro (and maybe others) to help with their
variant of that list for the same SoCs to begin with.

With that, we'll get an idea of whether we think we can get a
reasonable stable long term list that's appropriate for most vendors.

If that's the case, then my objections to have it in the kernel instead
of the DT fade away a bit.

If one or two of those fields absolutely must have their defaults
early, then we can consider a specific set of one or two properties in
the SoC node for that SoC family that provides those specific defaults.

But unless we have that list, I think we'll be throwing too many
hypotheticals around to convince Rob and others.

Andrew, can you start with a list that shows what you expect us to need
on our systems ?


  reply	other threads:[~2018-07-19  4:36 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
2018-07-18 23:58                   ` Benjamin Herrenschmidt
2018-07-19  2:28                     ` Andrew Jeffery
2018-07-19  4:35                       ` Benjamin Herrenschmidt [this message]
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 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --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).