All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Umang Jain <umang.jain@ideasonboard.com>
Cc: linux-staging@lists.linux.dev,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	stefan.wahren@i2se.com, f.fainelli@gmail.com,
	athierry@redhat.com, error27@gmail.com,
	dave.stevenson@raspberrypi.com, kieran.bingham@ideasonboard.com,
	laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v8 1/5] staging: vc04_services: vchiq_arm: Add new bus type and device type
Date: Mon, 3 Jul 2023 21:57:29 +0200	[thread overview]
Message-ID: <2023070301-elective-devious-2204@gregkh> (raw)
In-Reply-To: <d84acc1e-e933-b304-b513-f097c79d8a17@ideasonboard.com>

On Mon, Jul 03, 2023 at 06:15:25PM +0200, Umang Jain wrote:
> Hi Greg,
> 
> (resending because it got bounced off a few lists due a line a copied with
> HTML tag..)
> 
> On 7/3/23 3:28 PM, Greg KH wrote:
> > On Tue, Jun 27, 2023 at 10:16:24PM +0200, Umang Jain wrote:
> > > 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@ideasonboard.com>
> > > ---
> > >   drivers/staging/vc04_services/Makefile        |  1 +
> > >   .../interface/vchiq_arm/vchiq_device.c        | 78 +++++++++++++++++++
> > >   .../interface/vchiq_arm/vchiq_device.h        | 43 ++++++++++
> > >   3 files changed, 122 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..dff312e9735c
> > > --- /dev/null
> > > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
> > > @@ -0,0 +1,78 @@
> > > +// 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/slab.h>
> > > +#include <linux/string.h>
> > > +
> > > +#include "vchiq_device.h"
> > > +
> > > +static int vchiq_bus_type_match(struct device *dev, struct device_driver *drv);
> > > +
> > > +struct bus_type vchiq_bus_type = {
> > > +	.name   = "vchiq-bus",
> > > +	.match  = vchiq_bus_type_match,
> > > +};
> > > +
> > > +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 void vchiq_device_release(struct device *dev)
> > > +{
> > > +	struct vchiq_device *device;
> > > +
> > > +	device = container_of(dev, struct vchiq_device, dev);
> > > +	kfree(device);
> > > +}
> > > +
> > > +int vchiq_device_register(struct device *parent, const char *name)
> > > +{
> > > +	struct vchiq_device *device = NULL;
> > No need to set this to NULL.
> > 
> > > +	int ret;
> > > +
> > > +	device = kzalloc(sizeof(*device), GFP_KERNEL);
> > > +	if (!device)
> > > +		return -ENOMEM;
> > > +
> > > +	device->dev.init_name = name;
> > > +	device->dev.parent = parent;
> > > +	device->dev.bus = &vchiq_bus_type;
> > > +	device->dev.release = vchiq_device_release;
> > > +
> > > +	ret = device_register(&device->dev);
> > > +	if (ret) {
> > > +		put_device(&device->dev);
> > > +		return -EINVAL;
> > Why not return the error given to you?
> > 
> > > +	}
> > > +
> > > +	return 0;
> > You create a new device, shouldn't you return it?  How is it going to be
> > looked up again?
> 
> So I haven't come across usage of the device other than unregistered right
> now. If you look at the platform_device static instances of bcm2835_camera,
> bcm2835-audio, they are also just used for unregistering the devices only.

That feels odd, you need to register a device, use it, and then
unregister it when finished.  Otherwise why have it?

> So for unregistering devices on vchiq_bus - I am using the
> 
>     bus_for_each_dev(&vchiq_bus_type, NULL, NULL, vchiq_device_unregister);

Ick, no, that is horrid, unregister the device that was created, that's
how all other busses work.

> So basically I can return the instances right now, but there would be no
> user of those instances.

You should save it :)


> > 
> > > +}
> > > +
> > > +int vchiq_device_unregister(struct device *dev, void *data)
> > You should be passing in a sruct vchiq_device *device here, right?
> > 
> > And why the void pointer you do nothing with?
> 
> ack
> > 
> > 
> > > +{
> > > +	device_unregister(dev);
> > > +	return 0;
> > > +}
> > No need to export this?
> 
> In the previous reviews you mentioned not to export it. The vchiq_bus_type
> is internal to the vchiq_driver to register it's child devices. I don't
> think any other module will be using this bus directly? Maybe I'm mistaken?

Ok, just didn't match up with the register function export.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Umang Jain <umang.jain@ideasonboard.com>
Cc: linux-staging@lists.linux.dev,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	stefan.wahren@i2se.com, f.fainelli@gmail.com,
	athierry@redhat.com, error27@gmail.com,
	dave.stevenson@raspberrypi.com, kieran.bingham@ideasonboard.com,
	laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v8 1/5] staging: vc04_services: vchiq_arm: Add new bus type and device type
Date: Mon, 3 Jul 2023 21:57:29 +0200	[thread overview]
Message-ID: <2023070301-elective-devious-2204@gregkh> (raw)
In-Reply-To: <d84acc1e-e933-b304-b513-f097c79d8a17@ideasonboard.com>

On Mon, Jul 03, 2023 at 06:15:25PM +0200, Umang Jain wrote:
> Hi Greg,
> 
> (resending because it got bounced off a few lists due a line a copied with
> HTML tag..)
> 
> On 7/3/23 3:28 PM, Greg KH wrote:
> > On Tue, Jun 27, 2023 at 10:16:24PM +0200, Umang Jain wrote:
> > > 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@ideasonboard.com>
> > > ---
> > >   drivers/staging/vc04_services/Makefile        |  1 +
> > >   .../interface/vchiq_arm/vchiq_device.c        | 78 +++++++++++++++++++
> > >   .../interface/vchiq_arm/vchiq_device.h        | 43 ++++++++++
> > >   3 files changed, 122 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..dff312e9735c
> > > --- /dev/null
> > > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
> > > @@ -0,0 +1,78 @@
> > > +// 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/slab.h>
> > > +#include <linux/string.h>
> > > +
> > > +#include "vchiq_device.h"
> > > +
> > > +static int vchiq_bus_type_match(struct device *dev, struct device_driver *drv);
> > > +
> > > +struct bus_type vchiq_bus_type = {
> > > +	.name   = "vchiq-bus",
> > > +	.match  = vchiq_bus_type_match,
> > > +};
> > > +
> > > +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 void vchiq_device_release(struct device *dev)
> > > +{
> > > +	struct vchiq_device *device;
> > > +
> > > +	device = container_of(dev, struct vchiq_device, dev);
> > > +	kfree(device);
> > > +}
> > > +
> > > +int vchiq_device_register(struct device *parent, const char *name)
> > > +{
> > > +	struct vchiq_device *device = NULL;
> > No need to set this to NULL.
> > 
> > > +	int ret;
> > > +
> > > +	device = kzalloc(sizeof(*device), GFP_KERNEL);
> > > +	if (!device)
> > > +		return -ENOMEM;
> > > +
> > > +	device->dev.init_name = name;
> > > +	device->dev.parent = parent;
> > > +	device->dev.bus = &vchiq_bus_type;
> > > +	device->dev.release = vchiq_device_release;
> > > +
> > > +	ret = device_register(&device->dev);
> > > +	if (ret) {
> > > +		put_device(&device->dev);
> > > +		return -EINVAL;
> > Why not return the error given to you?
> > 
> > > +	}
> > > +
> > > +	return 0;
> > You create a new device, shouldn't you return it?  How is it going to be
> > looked up again?
> 
> So I haven't come across usage of the device other than unregistered right
> now. If you look at the platform_device static instances of bcm2835_camera,
> bcm2835-audio, they are also just used for unregistering the devices only.

That feels odd, you need to register a device, use it, and then
unregister it when finished.  Otherwise why have it?

> So for unregistering devices on vchiq_bus - I am using the
> 
>     bus_for_each_dev(&vchiq_bus_type, NULL, NULL, vchiq_device_unregister);

Ick, no, that is horrid, unregister the device that was created, that's
how all other busses work.

> So basically I can return the instances right now, but there would be no
> user of those instances.

You should save it :)


> > 
> > > +}
> > > +
> > > +int vchiq_device_unregister(struct device *dev, void *data)
> > You should be passing in a sruct vchiq_device *device here, right?
> > 
> > And why the void pointer you do nothing with?
> 
> ack
> > 
> > 
> > > +{
> > > +	device_unregister(dev);
> > > +	return 0;
> > > +}
> > No need to export this?
> 
> In the previous reviews you mentioned not to export it. The vchiq_bus_type
> is internal to the vchiq_driver to register it's child devices. I don't
> think any other module will be using this bus directly? Maybe I'm mistaken?

Ok, just didn't match up with the register function export.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-07-03 19:57 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 20:16 [PATCH v8 0/5] staging: vc04_services: vchiq: Register devices with a custom bus_type Umang Jain
2023-06-27 20:16 ` Umang Jain
2023-06-27 20:16 ` [PATCH v8 1/5] staging: vc04_services: vchiq_arm: Add new bus type and device type Umang Jain
2023-06-27 20:16   ` Umang Jain
2023-07-03 13:28   ` Greg KH
2023-07-03 13:28     ` Greg KH
2023-07-03 16:15     ` Umang Jain
2023-07-03 16:15       ` Umang Jain
2023-07-03 19:57       ` Greg KH [this message]
2023-07-03 19:57         ` Greg KH
2023-06-27 20:16 ` [PATCH v8 2/5] staging: vc04_services: vchiq_arm: Register vchiq_bus_type Umang Jain
2023-06-27 20:16   ` Umang Jain
2023-06-28 11:21   ` Kieran Bingham
2023-06-28 11:21     ` Kieran Bingham
2023-06-28 21:08     ` Umang Jain
2023-06-28 21:08       ` Umang Jain
2023-06-27 20:16 ` [PATCH v8 3/5] staging: bcm2835-camera: Register bcm2835-camera with vchiq_bus_type Umang Jain
2023-06-27 20:16   ` Umang Jain
2023-06-28 22:44   ` Kieran Bingham
2023-06-28 22:44     ` Kieran Bingham
2023-06-29 11:49     ` Umang Jain
2023-06-29 11:49       ` Umang Jain
2023-06-29 12:19       ` Kieran Bingham
2023-06-29 12:19         ` Kieran Bingham
2023-07-03 13:29   ` Greg KH
2023-07-03 13:29     ` Greg KH
2023-07-03 14:44     ` Umang Jain
2023-07-03 14:44       ` Umang Jain
2023-07-03 14:46       ` Greg KH
2023-07-03 14:46         ` Greg KH
2023-06-27 20:16 ` [PATCH v8 4/5] staging: bcm2835-audio: Register bcm2835-audio " Umang Jain
2023-06-27 20:16   ` Umang Jain
2023-06-28 22:51   ` Kieran Bingham
2023-06-28 22:51     ` Kieran Bingham
2023-06-27 20:16 ` [PATCH v8 5/5] staging: vc04_services: vchiq_arm: Remove vchiq_register_child() Umang Jain
2023-06-27 20:16   ` Umang Jain
2023-06-28 22:46   ` Kieran Bingham
2023-06-28 22:46     ` Kieran Bingham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2023070301-elective-devious-2204@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=athierry@redhat.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=error27@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=stefan.wahren@i2se.com \
    --cc=umang.jain@ideasonboard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.