From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH] rpmsg: char: Remove useless includes
Date: Wed, 5 May 2021 11:08:04 -0600 [thread overview]
Message-ID: <20210505170804.GC1766375@xps15> (raw)
In-Reply-To: <7170fdd0-00cd-1486-7b4c-41040ecfff6f@foss.st.com>
On Tue, May 04, 2021 at 08:20:25PM +0200, Arnaud POULIQUEN wrote:
>
>
> 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?
Thanks for the clarifications, this is much much better.
Less changes is always preferred, so unless there is a clear guideline or a good
reason to make a change I would prefer to keep things the way they are.
>
> 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@foss.st.com/
> >>
> >> Thanks,
> >> Arnaud
> >>
> >>>
> >>> Thanks,
> >>> Mathieu
> >>>
> >>>>
> >>>> #define RPMSG_DEV_MAX (MINORMASK + 1)
> >>>>
> >>>> --
> >>>> 2.17.1
> >>>>
prev parent reply other threads:[~2021-05-05 17:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 8:06 [PATCH] rpmsg: char: Remove useless includes Arnaud Pouliquen
2021-05-03 17:42 ` Mathieu Poirier
2021-05-04 7:16 ` Arnaud POULIQUEN
2021-05-04 17:05 ` Mathieu Poirier
2021-05-04 18:20 ` Arnaud POULIQUEN
2021-05-05 17:08 ` Mathieu Poirier [this message]
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=20210505170804.GC1766375@xps15 \
--to=mathieu.poirier@linaro.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=ohad@wizery.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.