All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Wang, Haiyue" <haiyue.wang@linux.intel.com>,
	openbmc@lists.ozlabs.org, openbmc-request@lists.ozlabs.org,
	Andrew Jeffery <andrew@aj.id.au>, Joel Stanley <joel@jms.id.au>
Subject: Re: openbmc Digest, Vol 32, Issue 32
Date: Thu, 12 Apr 2018 18:20:49 +1000	[thread overview]
Message-ID: <1523521249.11062.168.camel@kernel.crashing.org> (raw)
In-Reply-To: <45b6959c-5743-744f-d4d6-4f40984f1323@linux.intel.com>

On Thu, 2018-04-12 at 15:55 +0800, Wang, Haiyue wrote:
> Hi Andrew,
> 
> Facebook uses the 'devmem' utility and python script to implement the 
> soc register
> 
> read and write in a simple way. And the yocto layer is also very clear 
> like different

Using /dev/mem is really bad and very much discouraged. In fact for
security reasons, /dev/mem should be disabled in the kernel in
production. We need to do something better, hence the proposal.

> chip vendor and common parts.
> 
> 
> Kernel device tree upstream is also very slow, we needs two parts 
> (device tree + user app)

What do you mean by "very slow" ? I don't understand your statement.

> to finish the soc setting. But Facebook just uses user app, this 
> development is fast, and
> 
> simple is the best.

Sorry I don't really get what you mean. Please elaborate.

> Well, just for sharing what I found, I may misunderstood the BIG idea 
> after this kernel

The basic idea is to have a mechanism by which the SoC code in the
kernel can expose to userspace via sysfs a *small* selected set of
tunables that userspace might have to tweak for various platform
specific reasons.

To qualify, these things have to strictly be things that don't fit
within any existing Linux ABI and subsystem, and typically that affect
the *host* and not the BMC itself (or to a very limited extent).

Some examples are the tunables to control whether the host can access
the AHB bus via the backdoor on LPC or PCIe (and if yes which regions
are enabled).

> patch design. :-)
> 
> 
> soc_gpio_table = {
> 
> 	'A10': [
> 
> 	Function('SDA3', BitsEqual(0x90, [16], 0x1)),
> 
> 	Function('GPIOQ1', None)
> 
> 	],
> 
> 	'A11': [
> 
> 	Function('SCL3', BitsEqual(0x90, [16], 0x1)),
> 
> 	Function('GPIOQ0', None)
> 
> 	],
> 
> https://github.com/facebook/openbmc/blob/helium/common/recipes-utils/openbmc-gpio/files/openbmc-gpio-1/phymemory.py
> 
> https://github.com/facebook/openbmc/blob/helium/meta-aspeed/recipes-utils/ast-mdio/files/ast-mdio.py
> 
> https://github.com/facebook/openbmc/blob/helium/meta-aspeed/recipes-utils/openbmc-gpio/files/openbmc-gpio-1/ast2500_gpio_table.py

I don't undertsand what those links are supposed to be. Please
elaborate on what you mean rather than posting random links.

Cheers,
Ben.


> 
> BR,
> 
> Haiyue
> 
> 
> On 2018-04-12 13:32, openbmc-request@lists.ozlabs.org wrote:
> > Message: 1
> > Date: Thu, 12 Apr 2018 13:21:43 +0930
> > From: Andrew Jeffery<andrew@aj.id.au>
> > To:openbmc@lists.ozlabs.org
> > Cc: Andrew Jeffery<andrew@aj.id.au>,joel@jms.id.au,jk@ozlabs.org,
> > 	benh@kernel.crashing.org
> > Subject: [RFC PATCH linux dev-4.13 1/3] soc: aspeed: Miscellaneous
> > 	control interfaces
> > Message-ID:<20180412035145.21488-2-andrew@aj.id.au>
> > 
> > The ASPEED BMC SoCs have many knobs and switches that are sometimes
> > design-specific and often defy any approach to unify them under an
> > existing subsystem.
> > 
> > Add a driver to translate a devicetree table into sysfs entries to
> > expose bits and fields for manipulation from userspace. This encompasses
> > concepts from scratch registers to boolean conditions to enable or
> > disable host interface features.
> > 
> > Signed-off-by: Andrew Jeffery<andrew@aj.id.au>
> > ---
> >   drivers/soc/Kconfig                  |   1 +
> >   drivers/soc/Makefile                 |   1 +
> >   drivers/soc/aspeed/Kconfig           |  11 +++
> >   drivers/soc/aspeed/Makefile          |   1 +
> >   drivers/soc/aspeed/aspeed-bmc-misc.c | 187 +++++++++++++++++++++++++++++++++++
> >   5 files changed, 201 insertions(+)
> >   create mode 100644 drivers/soc/aspeed/Kconfig
> >   create mode 100644 drivers/soc/aspeed/Makefile
> >   create mode 100644 drivers/soc/aspeed/aspeed-bmc-misc.c
> > 
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index 07fc0ac51c52..776fd5978f70 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -1,6 +1,7 @@
> >   menu "SOC (System On Chip) specific Drivers"
> >   
> >   source "drivers/soc/actions/Kconfig"
> > +source "drivers/soc/aspeed/Kconfig"
> >   source "drivers/soc/atmel/Kconfig"
> >   source "drivers/soc/bcm/Kconfig"
> >   source "drivers/soc/fsl/Kconfig"
> > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> > index 9241125416ba..94a5b97c4466 100644
> > --- a/drivers/soc/Makefile
> > +++ b/drivers/soc/Makefile
> > @@ -3,6 +3,7 @@
> >   #
> >   
> >   obj-$(CONFIG_ARCH_ACTIONS)	+= actions/
> > +obj-$(CONFIG_ARCH_ASPEED)       += aspeed/
> >   obj-$(CONFIG_ARCH_AT91)		+= atmel/
> >   obj-y				+= bcm/
> >   obj-$(CONFIG_ARCH_DOVE)		+= dove/
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > new file mode 100644
> > index 000000000000..704a4efe180f
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -0,0 +1,11 @@
> > +menu "ASPEED SoC drivers"
> > +
> > +config ASPEED_BMC_MISC
> > +	bool "Miscellaneous ASPEED BMC interfaces"
> > +	depends on ARCH_ASPEED || COMPILE_TEST
> > +	default ARCH_ASPEED
> > +	help
> > +	  Say yes to expose VGA and LPC scratch registers, and other
> > +	  miscellaneous control interfaces specific to the ASPEED BMC SoCs
> > +
> > +endmenu

  reply	other threads:[~2018-04-12  8:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.355.1523511154.2391.openbmc@lists.ozlabs.org>
2018-04-12  7:55 ` openbmc Digest, Vol 32, Issue 32 Wang, Haiyue
2018-04-12  8:20   ` Benjamin Herrenschmidt [this message]
2018-04-12  8:42     ` Wang, Haiyue
2018-04-13  4:43       ` Benjamin Herrenschmidt
2018-04-13  5:11         ` Wang, Haiyue
2018-04-13  5:41           ` Benjamin Herrenschmidt
2018-04-13  5:55             ` Wang, Haiyue
2018-04-13  0:30   ` Andrew Jeffery
2018-04-13  0:37     ` Wang, Haiyue

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=1523521249.11062.168.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=andrew@aj.id.au \
    --cc=haiyue.wang@linux.intel.com \
    --cc=joel@jms.id.au \
    --cc=openbmc-request@lists.ozlabs.org \
    --cc=openbmc@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 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.