On 5/4/21 7:05 PM, Mathieu Poirier wrote: > Hi Arnaud, > > [...] > >> >> I started by this one and then I got carried away tested the other include... >> You are right, I just don't follow her the first rule of the "submit checklist" >> >> "If you use a facility then #include the file that defines/declares that >> facility. Don’t depend on other header files pulling in ones that you use." >> >> That said I just have a doubt for uapi/linux/rpmsg.h that will be include >> by rpmsg.h[2], as these includes are part of the rpmsg framework API, should we >> keep both, considering the rule as strict? > > I red the last paragraph several times I can't understand what you are > trying to convey. Please rephrase, provide more context or detail exactly where > you think we have a problem. There is no problem, just a question before sending an update. As you mention the #include "rpmsg_internal.h" line can be removed, I plan to send a patch V2 for this. That's said before sending a new version I would like to propose to also remove the #include <uapi/linux/rpmsg.h> line. The rational to remove it is that include/rpmsg.h would already include <uapi/linux/rpmsg.h> in 5.13 [2]. And looking at some frameworks (e.g I2C, TTY) the drivers seem to include only the include/xxx.h and not the uapi/linux/xxx.h in such case. So my question is should I remove #include <uapi/linux/rpmsg.h> line? Or do you prefer that i keep it? Hope it is more clear... else please just forget my proposal, I wouldn't want you to waste too much time for a point of detail. Thanks, Arnaud > > Thanks, > Mathieu > > >> >> [1] https://www.kernel.org/doc/html/latest/process/submit-checklist.html >> [2] >> https://patchwork.kernel.org/project/linux-remoteproc/patch/20210311140413.31725-3-arnaud.pouliquen@xxxxxxxxxxx/ >> >> Thanks, >> Arnaud >> >>> >>> Thanks, >>> Mathieu >>> >>>> >>>> #define RPMSG_DEV_MAX (MINORMASK + 1) >>>> >>>> -- >>>> 2.17.1 >>>>
