[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4601452-061f-203e-6c05-3e03977eb7f9@arm.com>
Date: Thu, 14 Sep 2023 23:15:09 +0100
From: Robin Murphy <robin.murphy@....com>
To: Stefan Wahren <wahrenst@....net>,
Umang Jain <umang.jain@...asonboard.com>,
linux-staging@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
linux-rpi-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: Stefan Wahren <stefan.wahren@...e.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Florian Fainelli <f.fainelli@...il.com>,
Adrien Thierry <athierry@...hat.com>,
Dan Carpenter <error27@...il.com>,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH v11 1/5] staging: vc04_services: vchiq_arm: Add new bus
type and device type
On 2023-09-13 21:58, Stefan Wahren wrote:
> Hi Umang,
>
> Am 13.09.23 um 21:53 schrieb Umang Jain:
>> The devices that the vchiq interface registers (bcm2835-audio,
>> bcm2835-camera) are implemented and exposed by the VC04 firmware.
>> The device tree describes the VC04 itself with the resources required
>> to communicate with it through a mailbox interface. However, the
>> vchiq interface registers these devices as platform devices. This
>> also means the specific drivers for these devices are getting
>> registered as platform drivers. This is not correct and a blatant
>> abuse of platform device/driver.
>>
>> Add a new bus type, vchiq_bus_type and device type (struct vchiq_device)
>> which will be used to migrate child devices that the vchiq interfaces
>> creates/registers from the platform device/driver.
>>
>> Signed-off-by: Umang Jain <umang.jain@...asonboard.com>
>> ---
>> drivers/staging/vc04_services/Makefile | 1 +
>> .../interface/vchiq_arm/vchiq_device.c | 111 ++++++++++++++++++
>> .../interface/vchiq_arm/vchiq_device.h | 54 +++++++++
>> 3 files changed, 166 insertions(+)
>> create mode 100644
>> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
>> create mode 100644
>> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.h
>>
>> diff --git a/drivers/staging/vc04_services/Makefile
>> b/drivers/staging/vc04_services/Makefile
>> index 44794bdf6173..2d071e55e175 100644
>> --- a/drivers/staging/vc04_services/Makefile
>> +++ b/drivers/staging/vc04_services/Makefile
>> @@ -5,6 +5,7 @@ vchiq-objs := \
>> interface/vchiq_arm/vchiq_core.o \
>> interface/vchiq_arm/vchiq_arm.o \
>> interface/vchiq_arm/vchiq_debugfs.o \
>> + interface/vchiq_arm/vchiq_device.o \
>> interface/vchiq_arm/vchiq_connected.o \
>>
>> ifdef CONFIG_VCHIQ_CDEV
>> diff --git
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
>> new file mode 100644
>> index 000000000000..aad55c461905
>> --- /dev/null
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
>> @@ -0,0 +1,111 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * vchiq_device.c - VCHIQ generic device and bus-type
>> + *
>> + * Copyright (c) 2023 Ideas On Board Oy
>> + */
>> +
>> +#include <linux/device/bus.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/of_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/string.h>
>> +
>> +#include "vchiq_device.h"
>> +
>> +static int vchiq_bus_type_match(struct device *dev, struct
>> device_driver *drv)
>> +{
>> + if (dev->bus == &vchiq_bus_type &&
>> + strcmp(dev_name(dev), drv->name) == 0)
>> + return 1;
>> +
>> + return 0;
>> +}
>> +
>> +static int vchiq_bus_uevent(const struct device *dev, struct
>> kobj_uevent_env *env)
>> +{
>> + const struct vchiq_device *device = container_of_const(dev,
>> struct vchiq_device, dev);
>> +
>> + return add_uevent_var(env, "MODALIAS=%s", dev_name(&device->dev));
>> +}
>> +
>> +static int vchiq_bus_probe(struct device *dev)
>> +{
>> + struct vchiq_device *device = to_vchiq_device(dev);
>> + struct vchiq_driver *driver = to_vchiq_driver(dev->driver);
>> + int ret;
>> +
>> + ret = driver->probe(device);
>> + if (ret == 0)
>> + return 0;
>> +
>> + return ret;
>> +}
>> +
>> +struct bus_type vchiq_bus_type = {
>> + .name = "vchiq-bus",
>> + .match = vchiq_bus_type_match,
>> + .uevent = vchiq_bus_uevent,
>> + .probe = vchiq_bus_probe,
>> +};
>> +
>> +static void vchiq_device_release(struct device *dev)
>> +{
>> + struct vchiq_device *device = to_vchiq_device(dev);
>> +
>> + kfree(device);
>> +}
>> +
>> +struct vchiq_device *
>> +vchiq_device_register(struct device *parent, const char *name)
>> +{
>> + struct vchiq_device *device;
>> + int ret;
>> +
>> + device = kzalloc(sizeof(*device), GFP_KERNEL);
>> + if (!device) {
>> + dev_err(parent, "Cannot register %s: Insufficient memory\n",
>> + name);
> AFAIK kzalloc already logs an error in case of insufficient memory, so
> there is no need for this.
>> + return NULL;
>> + }
>> +
>> + device->dev.init_name = name;
>> + device->dev.parent = parent;
>> + device->dev.bus = &vchiq_bus_type;
>> + device->dev.release = vchiq_device_release;
>> +
>> + of_dma_configure(&device->dev, parent->of_node, true);
>> + ret = dma_set_mask_and_coherent(&device->dev, DMA_BIT_MASK(32));
> From my understand Robin suggested to drop dma_set_mask_and_coherent()
> here, too. In case this cause a regression until patch 3 & 4 are
> applied. The DMA mask parts should be applied separately before this patch.
Indeed, here we should have "device->dev.dma_mask =
&device->dev.dma_coherent_mask;", unconditionally, before
of_dma_configure() is called, and we should *not* be calling
dma_set_mask_and_coherent() at all. That will then be equivalent to what
the platform bus code was previously doing for these devices.
The vchiq_device drivers can then call dma_set_mask_and_coherent() if
they need to (AFAICS I'm not sure if they're actually using DMA at the
moment?) and should not touch dev->dma_mask directly. That does not need
to be done in any particular order relative to this patch, since the
truth is that of_dma_configure() will still initialise the masks to 32
bits by default anyway (as it currently does for the platform devices),
however it is still correct to add explicit calls (and handle their
potential failure if DMA is entirely unusable), and not simply assume
that the default masks are OK.
Hope that's clear.
Thanks,
Robin.
>> + if (ret) {
>> + dev_err(&device->dev, "32-bit DMA enable failed\n");
>> + return NULL;
>> + }
>> +
>> + ret = device_register(&device->dev);
>> + if (ret) {
>> + dev_err(parent, "Cannot register %s: %d\n", name, ret);
>> + put_device(&device->dev);
> Also Robin pointed out that there is a memory leak in the error path,
> because the "device" get lost.
>
> Thanks Stefan
>> + return NULL;
>> + }
>> +
>> + return device;
>> +}
>> +
>> +void vchiq_device_unregister(struct vchiq_device *vchiq_dev)
>> +{
>> + device_unregister(&vchiq_dev->dev);
>> +}
>> +
>> +int vchiq_driver_register(struct vchiq_driver *vchiq_drv)
>> +{
>> + vchiq_drv->driver.bus = &vchiq_bus_type;
>> +
>> + return driver_register(&vchiq_drv->driver);
>> +}
>> +EXPORT_SYMBOL_GPL(vchiq_driver_register);
>> +
>> +void vchiq_driver_unregister(struct vchiq_driver *vchiq_drv)
>> +{
>> + driver_unregister(&vchiq_drv->driver);
>> +}
>> +EXPORT_SYMBOL_GPL(vchiq_driver_unregister);
>> diff --git
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.h
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.h
>> new file mode 100644
>> index 000000000000..7eaaf9a91cda
>> --- /dev/null
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.h
>> @@ -0,0 +1,54 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2023 Ideas On Board Oy
>> + */
>> +
>> +#ifndef _VCHIQ_DEVICE_H
>> +#define _VCHIQ_DEVICE_H
>> +
>> +#include <linux/device.h>
>> +
>> +struct vchiq_device {
>> + struct device dev;
>> +};
>> +
>> +struct vchiq_driver {
>> + int (*probe)(struct vchiq_device *device);
>> + void (*remove)(struct vchiq_device *device);
>> + int (*resume)(struct vchiq_device *device);
>> + int (*suspend)(struct vchiq_device *device,
>> + pm_message_t state);
>> + struct device_driver driver;
>> +};
>> +
>> +static inline struct vchiq_device *to_vchiq_device(struct device *d)
>> +{
>> + return container_of(d, struct vchiq_device, dev);
>> +}
>> +
>> +static inline struct vchiq_driver *to_vchiq_driver(struct
>> device_driver *d)
>> +{
>> + return container_of(d, struct vchiq_driver, driver);
>> +}
>> +
>> +extern struct bus_type vchiq_bus_type;
>> +
>> +struct vchiq_device *
>> +vchiq_device_register(struct device *parent, const char *name);
>> +void vchiq_device_unregister(struct vchiq_device *dev);
>> +
>> +int vchiq_driver_register(struct vchiq_driver *vchiq_drv);
>> +void vchiq_driver_unregister(struct vchiq_driver *vchiq_drv);
>> +
>> +/**
>> + * module_vchiq_driver() - Helper macro for registering a vchiq driver
>> + * @__vchiq_driver: vchiq driver struct
>> + *
>> + * Helper macro for vchiq drivers which do not do anything special in
>> + * module init/exit. This eliminates a lot of boilerplate. Each
>> module may only
>> + * use this macro once, and calling it replaces module_init() and
>> module_exit()
>> + */
>> +#define module_vchiq_driver(__vchiq_driver) \
>> + module_driver(__vchiq_driver, vchiq_driver_register,
>> vchiq_driver_unregister)
>> +
>> +#endif /* _VCHIQ_DEVICE_H */
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Powered by blists - more mailing lists