Thread (57 messages) 57 messages, 5 authors, 2022-09-11

Re: [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi

From: Colin Foster <colin.foster@in-advantage.com>
Date: 2022-05-09 17:30:54
Also in: linux-arm-kernel, linux-gpio

On Mon, May 09, 2022 at 05:20:29PM +0000, Vladimir Oltean wrote:
On Mon, May 09, 2022 at 04:49:22PM -0700, Colin Foster wrote:
quoted
quoted
quoted
+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@google.com/ (local)
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.

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.
That's true. If it comes down to it I can do that. Though I really do
like having the SPI-specific stuff clearly separated, I can bring them
together if it speeds things up. I'll wait for feedback.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help