linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Rob Herring <robh@kernel.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	linux-realtek-soc@lists.infradead.org,
	"Tony Lindgren" <tony@atomide.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Michal Simek" <michal.simek@xilinx.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"Lee Jones" <lee.jones@linaro.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	"Alexander Sverdlin" <alexander.sverdlin@gmail.com>,
	LAKML <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hartley Sweeten" <hsweeten@visionengravers.com>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Architecture Mailman List" <boot-architecture@lists.linaro.org>,
	U-Boot <u-boot@lists.denx.de>
Subject: Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper)
Date: Fri, 15 Nov 2019 12:15:50 +0100	[thread overview]
Message-ID: <faa9924a-1c61-349c-9c35-da83fd0b3547@suse.de> (raw)
In-Reply-To: <CAL_JsqLr=fw6zxa=69rtgZ4oxzdw=cVDr3km5ya0pRGsNT1xLw@mail.gmail.com>

Am 14.11.19 um 23:09 schrieb Rob Herring:
> On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote:
>> On the other hand, one might argue that such information should just be
>> parsed by EBBR-conformant bootloaders and be passed to the kernel via
>> standard UEFI interfaces and DMI tables. But I'm not aware of Barebox
>> having implemented any of that yet, and even for U-Boot (e.g., Realtek
>> based consumer devices...) not everyone has the GPL sources or tools to
>> update their bootloader. So, having the kernel we control gather
>> information relevant to kernel developers does make some sense to me.
> 
> UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system.

Not sure, that's why I CC'ed the EBBR folks for input. If it's not
mandatory today, the next revision of EBBR could just require it - if
that's the unified way between SBBR and EBBR. Little point in doing it
only for EBBR.

On my UEFI+DT based Raspberry Pi 3 Model B I do see it, note the
non-filled Processor Information delivered by U-Boot:

raspi3:~ # dmidecode
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 253 bytes.
Table at 0x3CB3E020.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: U-Boot
	Version: 2019.10
	Release Date: 10/26/2019
	ROM Size: 64 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		Selectable boot is supported
		I2O boot is supported
		Targeted content distribution is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: raspberrypi
	Product Name: rpi
	Version: Not Specified
	Serial Number: 00000000********
	UUID: 30303030-3030-3030-6437-623461336666
	Wake-up Type: Reserved
	SKU Number: Not Specified
	Family: Not Specified

Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
	Manufacturer: raspberrypi
	Product Name: rpi
	Version: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Features:
		Board is a hosting board
	Location In Chassis: Not Specified
	Chassis Handle: 0x0000
	Type: Motherboard

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
	Manufacturer: raspberrypi
	Type: Desktop
	Lock: Not Present
	Version: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: Unspecified
	Contained Elements: 0

Handle 0x0004, DMI type 4, 48 bytes
Processor Information
	Socket Designation: Not Specified
	Type: Central Processor
	Family: Unknown
	Manufacturer: Unknown
	ID: 00 00 00 00 00 00 00 00
	Version: Unknown
	Voltage: Unknown
	External Clock: Unknown
	Max Speed: Unknown
	Current Speed: Unknown
	Status: Unpopulated
	Upgrade: None
	L1 Cache Handle: Not Provided
	L2 Cache Handle: Not Provided
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified
	Characteristics: None

Handle 0x0005, DMI type 32, 11 bytes
System Boot Information
	Status: No errors detected

Handle 0x0006, DMI type 127, 4 bytes
End Of Table


Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

  reply	other threads:[~2019-11-15 11:16 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-03  1:36 [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber
2019-11-03  1:36 ` [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding Andreas Färber
2019-11-06  4:41   ` Rob Herring
2019-11-03  1:36 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 Andreas Färber
2019-11-03  1:45   ` Andreas Färber
2019-11-11  4:56   ` [PATCH] base: soc: Export soc_device_to_device() helper Andreas Färber
2019-11-11  5:27     ` Greg Kroah-Hartman
2019-11-11  5:42       ` Andreas Färber
2019-11-11  6:40         ` Greg Kroah-Hartman
2019-11-11 20:10           ` Andreas Färber
2019-11-12  0:29             ` Andreas Färber
2019-11-12  5:23             ` Greg Kroah-Hartman
2019-11-12  7:29               ` Uwe Kleine-König
2019-11-12 10:47                 ` Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Andreas Färber
2019-11-14 22:09                   ` Rob Herring
2019-11-15 11:15                     ` Andreas Färber [this message]
2019-11-15 11:49                     ` Andreas Färber
2019-11-15  8:52                   ` Neil Armstrong
2019-11-15  8:58                     ` Geert Uytterhoeven
2019-11-15 12:00                       ` Andreas Färber
2019-11-15 12:34                         ` Geert Uytterhoeven
2019-11-18 15:55                           ` Tony Lindgren
2019-11-12 10:48                 ` [PATCH] base: soc: Export soc_device_to_device() helper Lee Jones
2020-01-02 14:29   ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 James Tai
2020-01-02 14:39     ` Andreas Färber
2020-01-02 15:02       ` James Tai
2020-01-03  5:07     ` Stanley Chang[昌育德]
2019-11-03  1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber
2020-01-02 14:32   ` James Tai
2020-01-03  5:07     ` Stanley Chang[昌育德]
2020-01-02 14:33   ` James Tai
2020-01-02 14:34   ` James Tai
2019-11-03  1:36 ` [RFC 04/11] ARM: dts: rtd1195: " Andreas Färber
2019-11-03  1:36 ` [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property Andreas Färber
2019-11-06  4:46   ` Rob Herring
2019-11-06  8:42     ` Andreas Färber
2019-11-03  1:36 ` [RFC 06/11] soc: realtek: chip: Detect RTD1296 Andreas Färber
2020-01-02 14:35   ` James Tai
2019-11-03  1:36 ` [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 Andreas Färber
2019-11-03  1:36 ` [RFC 08/11] soc: realtek: chip: Detect RTD1293 Andreas Färber
2019-11-03  1:36 ` [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again Andreas Färber
2019-11-03  1:36 ` [RFC 10/11] soc: realtek: chip: Detect RTD1294 Andreas Färber
2019-11-03  1:36 ` [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse Andreas Färber
2019-11-07  7:16 ` [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber

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=faa9924a-1c61-349c-9c35-da83fd0b3547@suse.de \
    --to=afaerber@suse.de \
    --cc=alexander.sverdlin@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=boot-architecture@lists.linaro.org \
    --cc=festevam@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=hsweeten@visionengravers.com \
    --cc=jonathanh@nvidia.com \
    --cc=kernel@pengutronix.de \
    --cc=khilman@baylibre.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-realtek-soc@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tony@atomide.com \
    --cc=u-boot@lists.denx.de \
    --cc=u.kleine-koenig@pengutronix.de \
    /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).