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

[Greg KH]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/