| Message ID | 20210219111501.14261-6-arnaud.pouliquen@foss.st.com |
|---|---|
| State | New |
| Headers | show |
| Series | introduce a generic IOCTL interface for RPMsg channels management | expand |
On Fri, Feb 19, 2021 at 12:14:50PM +0100, Arnaud Pouliquen wrote: > The RPMsg control device is a RPMsg device, it is already > referenced in the RPMsg bus. There is only an interest to > reference the ept char devices in the rpmsg class. > This patch prepares the code split of the control and end point > devices in two separate files. > > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> > --- > drivers/rpmsg/rpmsg_char.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c > index 78a6d19fdf82..23e369a00531 100644 > --- a/drivers/rpmsg/rpmsg_char.c > +++ b/drivers/rpmsg/rpmsg_char.c > @@ -485,7 +485,6 @@ static int rpmsg_chrdev_probe(struct rpmsg_device *rpdev) > dev = &ctrldev->dev; > device_initialize(dev); > dev->parent = &rpdev->dev; > - dev->class = rpmsg_class; This may break user space... It has been around for so long that even if the information is redundant we have to keep it. > > cdev_init(&ctrldev->cdev, &rpmsg_ctrldev_fops); > ctrldev->cdev.owner = THIS_MODULE; > -- > 2.17.1 >
On 3/2/21 7:01 PM, Mathieu Poirier wrote: > On Fri, Feb 19, 2021 at 12:14:50PM +0100, Arnaud Pouliquen wrote: >> The RPMsg control device is a RPMsg device, it is already >> referenced in the RPMsg bus. There is only an interest to >> reference the ept char devices in the rpmsg class. >> This patch prepares the code split of the control and end point >> devices in two separate files. >> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> >> --- >> drivers/rpmsg/rpmsg_char.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c >> index 78a6d19fdf82..23e369a00531 100644 >> --- a/drivers/rpmsg/rpmsg_char.c >> +++ b/drivers/rpmsg/rpmsg_char.c >> @@ -485,7 +485,6 @@ static int rpmsg_chrdev_probe(struct rpmsg_device *rpdev) >> dev = &ctrldev->dev; >> device_initialize(dev); >> dev->parent = &rpdev->dev; >> - dev->class = rpmsg_class; > > This may break user space... It has been around for so long that even if the > information is redundant we have to keep it. Yes, this point is part of the grey space of my series... I did it on the assumption that the "rpmsg" class interface is not used for the control part. Indeed, the group associated to the class provides information about the name service, the source address and the destination address of the endpoint.These group is not defined for the control device. That said, to preserve the interface, I can move the class creation in rpmsg control driver, to share it between the both drivers. As consequence I will need to manage the probe ordering of the char and control modules to ensure that the class is created before used. This should be solved by reintroducing patch[1] with a fix for the compilation warning. [1]https://lkml.org/lkml/2021/2/4/197 Thanks, Arnaud > >> >> cdev_init(&ctrldev->cdev, &rpmsg_ctrldev_fops); >> ctrldev->cdev.owner = THIS_MODULE; >> -- >> 2.17.1 >>
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c index 78a6d19fdf82..23e369a00531 100644 --- a/drivers/rpmsg/rpmsg_char.c +++ b/drivers/rpmsg/rpmsg_char.c @@ -485,7 +485,6 @@ static int rpmsg_chrdev_probe(struct rpmsg_device *rpdev) dev = &ctrldev->dev; device_initialize(dev); dev->parent = &rpdev->dev; - dev->class = rpmsg_class; cdev_init(&ctrldev->cdev, &rpmsg_ctrldev_fops); ctrldev->cdev.owner = THIS_MODULE;
The RPMsg control device is a RPMsg device, it is already referenced in the RPMsg bus. There is only an interest to reference the ept char devices in the rpmsg class. This patch prepares the code split of the control and end point devices in two separate files. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> --- drivers/rpmsg/rpmsg_char.c | 1 - 1 file changed, 1 deletion(-)