On Tue, Nov 6, 2018 at 8:58 AM Rob Herring <robh@xxxxxxxxxx> wrote:
> It doesn't really sound like the host should be in DT. The bridge
> should register itself as an anybus provider and that should in turn
> enable the anybus host protocol.
Very good point. Just to make sure we're on the same page, could you point
me to a relevant example where something registers as a provider?
v1 of this patch did not have the host in DT. The host just required platform
data with a regmap and a reset (the interrupt was passed via resources):
struct anybuss_host_pdata {
struct regmap *regmap;
void (*reset)(struct device *dev, bool reset);
};
But there were problems with this approach.
The review feedback told me that my self-rolled reset callback should really
be a reset controller. I looked for ways to pass a handle to a reset controller
via platform data. This has recently been introduced via:
reset_controller_add_lookup()
This binds a client device to a reset controller, without using the devicetree,
so the device can grab its controller via (devm_)reset_control_get*. Great!
But... to make the binding, you have to specify the full device names of the
controllers and client devices. See this example from psc-da850.c:
static struct reset_control_lookup da850_psc0_reset_lookup_table[] = {
RESET_LOOKUP("da850-psc0", 15, "davinci-rproc.0", NULL),
};
I very quickly found myself in ida_simple_get() hell, trying to second-guess
what the devices I was creating, would be called !
So instead I put the host in DT, then I could easily connect the reset
controller. This also greatly simplified the bridge driver, a lot of boilerplate
would simply disappear.
Suggestions are very welcome :)
Sven
