Re: [PATCH v5 05/16] rpmsg: char: dissociate the control device from the rpmsg class

[Arnaud POULIQUEN]

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@xxxxxxxxxxx>
>> ---
>>  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
>>