linux-kernel - Re: [PATCH v2 2/7] bus: Introduce firewall controller framework

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]

Message-ID: <CACRpkdajhivkOkZ63v-hr7+6ObhTffYOx5uZP0P-MYvuVnyweA@mail.gmail.com>
Date:   Fri, 14 Feb 2020 17:05:07 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Grant Likely <grant.likely@....com>
Cc:     Benjamin GAIGNARD <benjamin.gaignard@...com>,
        "robh@...nel.org" <robh@...nel.org>,
        Loic PALLARDY <loic.pallardy@...com>,
        "arnd@...db.de" <arnd@...db.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "system-dt@...ts.openampproject.org" 
        <system-dt@...ts.openampproject.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lkml@...ux.net" <lkml@...ux.net>,
        "linux-imx@....com" <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        "fabio.estevam@....com" <fabio.estevam@....com>,
        "stefano.stabellini@...inx.com" <stefano.stabellini@...inx.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/7] bus: Introduce firewall controller framework

On Fri, Jan 31, 2020 at 10:06 AM Greg KH <gregkh@...uxfoundation.org> wrote:

> Why do people want to abuse the platform bus so much?  If a device is on
> a bus that can have such a controller, then it is on a real bus, use it!

I'm not saying it is a good thing, but the reason why it is (ab)used so
much can be found in:
drivers/of/platform.c

TL;DR: struct platform_device is the Device McDeviceFace and
platform bus the Bus McBusFace used by the device tree parser since
it is slightly to completely unaware of what devices it is actually
spawning.

And everything and its dog is using device tree in the embedded
world. (A quick glance in drivers/acpi gives me the impression
that ACPI is doing the very same thing but I am not a domain expert
there so I am not really sure.)

Whenever a device is created from a device tree it gets spawned
on either the platform bus or the amba bus. In 99 cases out of
100 it is going to be a platform_device.

In most device trees all devices ultimately spawn from the device
tree and the root of absolutely everything including irq chips on
the SoC, timers, PCI hosts and USB root hubs and whatnot is a
platform device, because that is how the core device tree parser has
chosen to spawn off devices.

This generic code goes back to
commit eca3930163ba8884060ce9d9ff5ef0d9b7c7b00f
"of: Merge of_platform_bus_type with platform_bus_type"
where the device tree-specific bus was replaced by the
platform bus. This code was then moved down to drivers/of
and used in multiple architectures. Grant's patch makes perfect
sense because at the time some devices were created using board
files (thus platform_device) and others using device tree and having
two different probe paths and driver files for this reason alone
was not reasonable. The same reasoning will apply to ACPI
vs device tree drivers.

What we  *could* have done was to handle special devices
special, like happened for AMBA PrimeCells. Mea Culpa, I suppose
I am one of the guilty.

Supporting new bus types for root devices in systems described
in device tree would requiring patching drivers/of/platform.c
and people are afraid of that because the code there is pretty
complex.

Instead platform_device is (ab)used to carry stuff over from the
device tree to respective subsystem.

In some cases the struct platform_device from device tree is
discarded after use, it is just left dangling in memory with no other
purpose than to serve as .parent for whatever device on whatever
bus we were really creating.

For some devices such as root irq_chips they serve no purpose
whatsoever, they are just created and sitting around never
to be probed, because the code instantiating them parse the
device tree directly.

For the devices that actually probe to drive a piece of silicon,
arguably a different type of device on a different bus should be
created, such as (I am making this up) struct soc_device
on soc_bus. (Incidentally soc_bus exists, but its current use case
is not for this.)

I don't really see any better option for Benjamin or anyone else
though?

The reason why it is used so much should at least be clarified
now I think.

Yours,
Linus Walleij