[RFC PATCH] soc: bcm2835: auxiliar devices enable infrastructure

Stephen Warren swarren at wwwdotorg.org
Mon Aug 10 21:19:40 PDT 2015

On 08/04/2015 02:41 AM, kernel at martin.sperl.org wrote:
> From: Martin Sperl <kernel at martin.sperl.org>
> The bcm2835 soc contains 3 auxiliar devices (spi1, spi2 and uart1)
> that all are enabled via a shared register.
> To serialize access this soc-driver is created that implements
>   bcm2835aux_enable(struct device *dev, const char *property);
>   bcm2835aux_disable(struct device *dev, const char *property);
> Ehich will read the property from the device tree of the device
> and enable/disable that specific device as per device tree.
> First use of this api will be spi-bcm2835aux, which will
> set the following property in the device tree for the devices:
>   brcm,aux-enable = <&aux_enable 4>;  
> And call:
>   bcm2835aux_enable(&spi->dev, "brcm,aux-enable");
> This allows to define different property names based on the
> driver.

You need to send patches like this to a broader audience, such as CCing
the ARM kernel mailing list.

> diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-aux.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-aux.txt

> +Broadcom BCM2835 auxiliar device enable register

auxiliary. Same elsewhere.

> +- reg: Should contain register location and length for the enabl
> +       register

> +	reg = <0x7e215004 0x04>;

I think both registers 0x7e215000 and 0x7e215004 are part of the
"global" auxiliary register set. As such, I'd expect:

	reg = <0x7e215000 0x08>;

> diff --git a/drivers/soc/bcm/bcm2835-aux.c b/drivers/soc/bcm/bcm2835-aux.c

> +static void *bcm2835aux_find_base(struct device *dev, const char *property)

> +	/* now find the device it points to */
> +	found = driver_find_device(&bcm2835aux_driver.driver, NULL,
> +				   np, bcm2835aux_dev_match);
> +	if (!found) {
> +		dev_err(dev, "device for phandle of %s not found\n",
> +			property);
> +		return ERR_PTR(-ENODEV);

That should probably be -EPROBE_DEFER, so that client drivers can defer
their own probe if this driver isn't yet probed but the client driver
will need its services.

> diff --git a/include/linux/soc/bcm/bcm2835-aux.h b/include/linux/soc/bcm/bcm2835-aux.h

> +int bcm2835aux_enable(struct device *dev, const char *property);
> +int bcm2835aux_disable(struct device *dev, const char *property);

Will client drivers call bcm2835aux_enable() only from their probe()? If
so, that set of APIs is fine. Otherwise, I would expect more functions:

struct bcm2835aux;
struct bcm2835aux *bcm2835aux_get_handle(struct device *dev,
		const char *property);
int bcm2835aux_enable(struct bcm2835aux *aux);
int bcm2835aux_disable(struct bcm2835aux *aux);

More information about the linux-rpi-kernel mailing list