On Monday 04 November 2013, Stephen Warren wrote:
> On 11/04/2013 01:43 PM, Arnd Bergmann wrote:
> > int devm_probe_gpio(struct device *dev, const struct devm_probe *probe)
> ...
> > #define DEVM_GPIO(_struct, _member, _index) { \
> ...
> > #define DEVM_GPIO_NAMED(_struct, _member, _name) { \
>
> Should those save the GPIO flags too? Or, do we assume that gpiod-based
> GPIOs already handle the flags inside the gpiod API?
The latter. I would certainly hope to get away with assigning just one
structure field per callback function.
> > /*
> > * this lists all properties we access from the driver. The list
> > * is interpreted by devm_probe() and can be programmatically
> > * verified to match the binding.
> > */
> > static const struct devm_probe foo_probe_list[] = {
> > DEVM_ALLOC(foo_priv),
> > DEVM_IOMAP(foo_priv, regs, 0, 0),
> > DEVM_PROP_BOOL(foo_priv, oldstyle_dma, "foo,oldstyle-dma"),
>
> I wonder if it makes sense to handle pure data here, or whether this
> only makes sense for resources/services that are provided by some other
> device?
>
> I guess it's nice for all resources and configuration to come through to
> probe() in the same way, but I rather wonder how we'd handle bindings
> that have large custom (driver-specific) tables of data. Would be simply
> defer such things to custom code in probe()? If so, it feels slightly
> inconsistent to handle some data in the probe_list[] and some in code in
> probe(). Still, I guess there's something to be said for keeping the
> simple cases simple.
Right, and I didn't intend to solve all cases in a completely generic way.
Thinking about it some more, a driver could actually add a custom callback
for some properties, but I don't know if that adds any value over just
interpreting them from the regular probe() function.
> > DEVM_DMA_SLAVE(foo_priv, rxdma, "rx");
> > DEVM_DMA_SLAVE(foo_priv, txdma, "tx");
> > DEVM_GPIO(foo_priv, gpio, 0);
> > DEVM_IRQ_NAMED(foo_priv, irq, foo_irq_handler, "fifo", IRQF_SHARED),
>
> What about the case where some resources are optional, or only required
> based on the values of certain other properties? I suppose that probe()
> could call devm_probe() multiple times, with different probe_list[]s,
> based on whatever algorithm they need.
That's one open question that I haven't found the best solution for yet.
My first take on that was to add another field in struct devm_probe to
mark a property as optional, but that would increase the overall
complexity. I'd first want to do a survey of what kinds of properties
are typically optional. If it's only a few of them, we could have
something like
DEVM_DMA_SLAVE_OPTIONAL()
for the cases that need it, with a variant of the callback function.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
