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 07:44:16 -0700
From:	Greg KH <gregkh@...e.de>
To:	Arnd Bergmann <arnd@...db.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 Tue, Oct 18, 2011 at 04:00:03PM +0200, Arnd Bergmann wrote:
> 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.

Ah, ok, that's nicer, and makes sense.

So yes, you can leave the structure here, or use a helper function, but
either way, you shouldn't be returning a struct device * from the
register function, that doesn't make sense.

greg k-h
--
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/