linux-kernel - Re: [PATCH 2/6] drivers/base: add bus for System-on-Chip devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Oct 2011 16:00:03 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Lee Jones <lee.jones@...aro.org>, jamie@...ieiles.com,
	linux-kernel@...r.kernel.org, linus.walleij@...ricsson.com
Subject: Re: [PATCH 2/6] drivers/base: add bus for System-on-Chip devices

On Monday 17 October 2011, Greg KH wrote:
> > You also commented that the argument to soc_device_unregister should
> > be a soc_device (as, consequently, the return type of soc_device_register).
> > Agree with that comment, but it means that the definition of struct
> > soc_device needs to remain visible in order to be used as the parent
> > for other devices.
> 
> No it doesn't:
>         struct device * soc_device_to_device(struct soc device *soc);

Right, that works of course. I believe the more common way is to
expose the derived type to its users, and it also simplifies the
interface.

> Anyway, what are you using this soc device to be the parent of?

Basically everything. The SoC is probably about 90% of the system in
modern embedded systems. Typically, there are on-chip buses like
AMBA or PLB that contain dozens of internal devices (interrupt
controller, serial, dmaengine, rtc, timer, watchdog, ...) as well
as buses (i2c, spi, mmc, usb, pci, ...) that have off-chip child
devices. You can think of an soc device as a kind of über-MFD
that holds all of these together.

If you remember the early discussions about this patch set, I
specifically asked for making the soc_device be a representation
of the whole soc with a hierarchical view of its child devices
under it, as opposed to having an artificial device node that only
serves to export strings along the lines of /proc/cpuinfo.

See patch 5/6 for the one that moves all platform devices that
are part of the dbx500 soc below the soc_device.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/