On Mon, 09 May 2022, Vladimir Oltean wrote: > On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote: > > > > +struct regmap *ocelot_init_regmap_from_resource(struct device *child, > > > > + const struct resource *res) > > > > +{ > > > > + struct device *dev = child->parent; > > > > + > > > > + return ocelot_spi_devm_init_regmap(dev, child, res); > > > > > > So much for being bus-agnostic :-/ > > > Maybe get the struct ocelot_ddata and call ocelot_spi_devm_init_regmap() > > > via a function pointer which is populated by ocelot-spi.c? If you do > > > that don't forget to clean up drivers/mfd/ocelot.h of SPI specific stuff. > > > > That was my initial design. "core" was calling into "spi" exclusively > > via function pointers. > > > > The request was "Please find a clearer way to do this without function > > pointers" > > > > https://lore.kernel.org/netdev/Ydwju35sN9QJqJ%2FP@xxxxxxxxxx/ > > Yeah, I'm not sure what Lee was looking for, either. In any case I agree > with the comment that you aren't configuring a bus. In this context it > seems more appropriate to call this function pointer "init_regmap", with > different implementations per transport. FWIW, I'm still against using function pointers for this. What about making ocelot_init_regmap_from_resource() an inline function and pushing it into one of the header files? [As an aside, you don't need to pass both dev (parent) and child] In there you could simply do: inline struct regmap *ocelot_init_regmap_from_resource(struct device *dev, const struct resource *res) { if (dev_get_drvdata(dev->parent)->spi) return ocelot_spi_devm_init_regmap(dev, res); return NULL; } Also, do you really need devm in the title? > Or alternatively you could leave the "core"/"spi" pseudo-separation up > to the next person who needs to add support for some other register I/O > method. Or this. Your call. -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog