From: Benjamin Herrenschmidt <firstname.lastname@example.org> To: Andrew Jeffery <email@example.com>, Rob Herring <firstname.lastname@example.org> Cc: Mark Rutland <email@example.com>, firstname.lastname@example.org, Greg Kroah-Hartman <email@example.com>, Eugene.Cho@dell.com, firstname.lastname@example.org, email@example.com, Joel Stanley <firstname.lastname@example.org>, email@example.com, OpenBMC Maillist <firstname.lastname@example.org>, email@example.com 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: <firstname.lastname@example.org> (raw) In-Reply-To: <1531967302.2140539.1445583600.0F5ED287@webmail.messagingengine.com> 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 ? Cheers, Ben
next prev parent 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Eugene.Cho@dell.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields' \ /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
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).