On Tue, Jan 28, 2020 at 9:30 PM Benjamin GAIGNARD <benjamin.gaignard@xxxxxx> wrote: > On 1/28/20 5:57 PM, Greg KH wrote: > > On Tue, Jan 28, 2020 at 04:41:29PM +0000, Benjamin GAIGNARD wrote: > >> On 1/28/20 4:52 PM, Greg KH wrote: > >>> So put this in the bus-specific code that controls the bus that these > >>> devices live on. Why put it in the driver core when this is only on one > >>> "bus" (i.e. the catch-all-and-a-bag-of-chips platform bus)? > >> It is really similar to what pin controller does, configuring an > >> hardware block given DT information. > > Great, then use that instead :) > I think that Linus W. will complain if I do that :) So the similarity would be something like the way that pin control states are configured in the device tree and the pin control handles are taken before probe in drivers/base/pinctrl.c embedding a hook into dd.c. Not that it in any way controls any hardware even remotely similar to pin control. Pin control is an electronic thing, this firewalling is about bus access. IIUC this framework wants to discover at kernel boot time whether certain devices are accessible to it or not by inspecting the state of the firewalling hardware and then avoid probing those that are inaccessible. It needs the same deep hooks into dd.c to achieve this I believe. Yours, Linus Walleij
