[Ksummit-2013-discuss] [ARM ATTEND] Describing complex, non-probable system topologies

Olof Johansson olof at lixom.net
Sat Aug 3 01:16:57 EDT 2013

On Fri, Aug 2, 2013 at 3:32 PM, Greg KH <greg at kroah.com> wrote:
> On Fri, Aug 02, 2013 at 05:09:32PM +0100, Will Deacon wrote:
>> On Fri, Aug 02, 2013 at 03:20:10PM +0100, Greg KH wrote:
>> > On Fri, Aug 02, 2013 at 12:53:34PM +0100, Will Deacon wrote:
>> > > We can change the mindset by yelling, but if you're writing a new
>> > > driver for a peripheral on an ARM SoC, platform_bus is mighty tempting
>> > > because you get a bunch of device-tree parsing code for free (see
>> > > drivers/of/platform.c).
>> >
>> > I know :(
>> >
>> > So, who do I "yell at", and what do I do to make things easier for you
>> > from the driver-core perspective?
>> I would anticipate most of these drivers going through the arm-soc tree, so
>> Olof and Kevin would be doing the yelling. You could join in the chorus too!
>> We basically need reviewers to adopt the position that a new bus should be
>> considered and dismissed before using the platform_bus, then you can yell
>> transitively through them.
> I don't scale if I'm forced to review every driver to ensure that they
> shouldn't be using platform device and should be creating their own bus
> type.  You can do that, along with the other ARM developers reviewing
> these new subsystems and code being added.

For most new platforms, using basic platform_bus devices makes sense
when the setup is simple and just has a few devices. It's only when
they need to add support for {S,IO}MMUs and get the more advanced
functionality going that things get messy and platform_bus stops

So, we have the option of having someone care about the {S,IO}MMU
pieces, and when they spot the attempts to make that work, push them
towards a proper bus architecture. Until then, the simpler solution is
probably a reasonable idea compared to having newcomers worry about
defining new bus architectures and raising the bar for what it takes
to sort out the initial contributions and getting engaged upstream.


More information about the linux-arm-kernel mailing list