The following error was thrown when compiling `tools/perf` using OpenCSD
v0.11.1. This patch fixes said error.
```
CC util/intel-pt-decoder/intel-pt-log.o
CC util/cs-etm-decoder/cs-etm-decoder.o
util/cs-etm-decoder/cs-etm-decoder.c: In function
‘cs_etm_decoder__buffer_range’:
util/cs-etm-decoder/cs-etm-decoder.c:370:2: error: enumeration value ‘OCSD_INSTR_WFI_WFE’ not handled in switch [-Werror=switch-enum]
switch (elem->last_i_type) {
^~~~~~
CC util/intel-pt-decoder/intel-pt-decoder.o
cc1: all warnings being treated as errors
```
Because `OCSD_INSTR_WFI_WFE` case was added only in v0.11.0, the minimum
required OpenCSD library version for this patch is no longer v0.10.0.
Signed-off-by: Solomon Tan <[email protected]>
---
tools/build/feature/test-libopencsd.c | 4 ++--
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/build/feature/test-libopencsd.c b/tools/build/feature/test-libopencsd.c
index d68eb4fb40cc..2b0e02c38870 100644
--- a/tools/build/feature/test-libopencsd.c
+++ b/tools/build/feature/test-libopencsd.c
@@ -4,9 +4,9 @@
/*
* Check OpenCSD library version is sufficient to provide required features
*/
-#define OCSD_MIN_VER ((0 << 16) | (10 << 8) | (0))
+#define OCSD_MIN_VER ((0 << 16) | (11 << 8) | (0))
#if !defined(OCSD_VER_NUM) || (OCSD_VER_NUM < OCSD_MIN_VER)
-#error "OpenCSD >= 0.10.0 is required"
+#error "OpenCSD >= 0.11.0 is required"
#endif
int main(void)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index ba4c623cd8de..39fe21e1cf93 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -387,6 +387,7 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
break;
case OCSD_INSTR_ISB:
case OCSD_INSTR_DSB_DMB:
+ case OCSD_INSTR_WFI_WFE:
case OCSD_INSTR_OTHER:
default:
packet->last_instr_taken_branch = false;
--
2.19.1
On Thu, Mar 21, 2019 at 01:29:11AM +0000, Solomon Tan wrote:
> The following error was thrown when compiling `tools/perf` using OpenCSD
> v0.11.1. This patch fixes said error.
> ```
> CC util/intel-pt-decoder/intel-pt-log.o
> CC util/cs-etm-decoder/cs-etm-decoder.o
> util/cs-etm-decoder/cs-etm-decoder.c: In function
> ‘cs_etm_decoder__buffer_range’:
> util/cs-etm-decoder/cs-etm-decoder.c:370:2: error: enumeration value ‘OCSD_INSTR_WFI_WFE’ not handled in switch [-Werror=switch-enum]
> switch (elem->last_i_type) {
> ^~~~~~
> CC util/intel-pt-decoder/intel-pt-decoder.o
> cc1: all warnings being treated as errors
> ```
>
> Because `OCSD_INSTR_WFI_WFE` case was added only in v0.11.0, the minimum
> required OpenCSD library version for this patch is no longer v0.10.0.
>
> Signed-off-by: Solomon Tan <[email protected]>
> ---
> tools/build/feature/test-libopencsd.c | 4 ++--
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tools/build/feature/test-libopencsd.c b/tools/build/feature/test-libopencsd.c
> index d68eb4fb40cc..2b0e02c38870 100644
> --- a/tools/build/feature/test-libopencsd.c
> +++ b/tools/build/feature/test-libopencsd.c
> @@ -4,9 +4,9 @@
> /*
> * Check OpenCSD library version is sufficient to provide required features
> */
> -#define OCSD_MIN_VER ((0 << 16) | (10 << 8) | (0))
> +#define OCSD_MIN_VER ((0 << 16) | (11 << 8) | (0))
> #if !defined(OCSD_VER_NUM) || (OCSD_VER_NUM < OCSD_MIN_VER)
> -#error "OpenCSD >= 0.10.0 is required"
> +#error "OpenCSD >= 0.11.0 is required"
> #endif
>
> int main(void)
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index ba4c623cd8de..39fe21e1cf93 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -387,6 +387,7 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
> break;
> case OCSD_INSTR_ISB:
> case OCSD_INSTR_DSB_DMB:
> + case OCSD_INSTR_WFI_WFE:
> case OCSD_INSTR_OTHER:
> default:
> packet->last_instr_taken_branch = false;
> --
> 2.19.1
On my side this patch is no different from V3, i.e it doesn't pass checkpatch
and it doesn't apply on my next tree.
Mathieu
>
pub RSA 2048/C88289A6 2018-05-09 [email protected] <[email protected]>
> sub RSA 2048/7C5E8D6D 2018-05-09
>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 22, 2019 12:27 AM, Mathieu Poirier <[email protected]> wrote:
> On Thu, Mar 21, 2019 at 01:29:11AM +0000, Solomon Tan wrote:
>
> > The following error was thrown when compiling `tools/perf` using OpenCSD
> > v0.11.1. This patch fixes said error.
> >
> > CC util/intel-pt-decoder/intel-pt-log.o
> > CC util/cs-etm-decoder/cs-etm-decoder.o
> > util/cs-etm-decoder/cs-etm-decoder.c: In function
> > ‘cs_etm_decoder__buffer_range’:
> > util/cs-etm-decoder/cs-etm-decoder.c:370:2: error: enumeration value ‘OCSD_INSTR_WFI_WFE’ not handled in switch [-Werror=switch-enum]
> > switch (elem->last_i_type) {
> > ^~~~~~
> > CC util/intel-pt-decoder/intel-pt-decoder.o
> > cc1: all warnings being treated as errors
> >
> >
> > Because `OCSD_INSTR_WFI_WFE` case was added only in v0.11.0, the minimum
> > required OpenCSD library version for this patch is no longer v0.10.0.
> >
> > Signed-off-by: Solomon Tan [email protected]
> >
> > --------------------------------------------------------
> >
> > tools/build/feature/test-libopencsd.c | 4 ++--
> > tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 +
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> > diff --git a/tools/build/feature/test-libopencsd.c b/tools/build/feature/test-libopencsd.c
> > index d68eb4fb40cc..2b0e02c38870 100644
> > --- a/tools/build/feature/test-libopencsd.c
> > +++ b/tools/build/feature/test-libopencsd.c
> > @@ -4,9 +4,9 @@
> > /*
> >
> > - Check OpenCSD library version is sufficient to provide required features
> > */
> > -#define OCSD_MIN_VER ((0 << 16) | (10 << 8) | (0))
> > +#define OCSD_MIN_VER ((0 << 16) | (11 << 8) | (0))
> > #if !defined(OCSD_VER_NUM) || (OCSD_VER_NUM < OCSD_MIN_VER)
> > -#error "OpenCSD >= 0.10.0 is required"
> > +#error "OpenCSD >= 0.11.0 is required"
> > #endif
> >
> >
> > int main(void)
> > diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> > index ba4c623cd8de..39fe21e1cf93 100644
> > --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> > +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> > @@ -387,6 +387,7 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
> > break;
> > case OCSD_INSTR_ISB:
> > case OCSD_INSTR_DSB_DMB:
> >
> > - case OCSD_INSTR_WFI_WFE:
> > case OCSD_INSTR_OTHER:
> > default:
> > packet->last_instr_taken_branch = false;
> >
> >
> >
> > --
> > 2.19.1
>
> On my side this patch is no different from V3, i.e it doesn't pass checkpatch
> and it doesn't apply on my next tree.
>
> Mathieu
>
> >
>
> pub RSA 2048/C88289A6 [email protected] [email protected]
>
> > sub RSA 2048/7C5E8D6D 2018-05-09
I created a new branch from `next` for the patch mentioned above. Should I
have made the patch directly on the `next` branch instead?
I ran the following 2 commands to test the files I edited:
```
perl scripts/checkpatch.pl -f tools/build/feature/test-libopencsd.c
perl scripts/checkpatch.pl -f tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
```
The commands reported that the files "has no obvious style problems and is ready
for submission." For your kind advice please. Thank you.
Solomon Tan
Hi Solomon,
On Fri, Mar 22, 2019 at 12:47:11AM +0000, Solomon Tan wrote:
[...]
> > On my side this patch is no different from V3, i.e it doesn't pass checkpatch
> > and it doesn't apply on my next tree.
> >
> > Mathieu
> >
> > >
> >
> > pub RSA 2048/C88289A6 [email protected] [email protected]
> >
> > > sub RSA 2048/7C5E8D6D 2018-05-09
>
> I created a new branch from `next` for the patch mentioned above. Should I
> have made the patch directly on the `next` branch instead?
>
> I ran the following 2 commands to test the files I edited:
> ```
> perl scripts/checkpatch.pl -f tools/build/feature/test-libopencsd.c
> perl scripts/checkpatch.pl -f tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> ```
> The commands reported that the files "has no obvious style problems and is ready
> for submission." For your kind advice please. Thank you.
Suggest you to use below flow for sending patch:
- git format HEAD~1: generate patch
- ./scripts/checkpatch.pl xxxx.patch: check patch format
- git send-email xxxx.patch: use git to send patch so avoid any
unexpected characters in the mail
P.s. Marc has a good presentation [1] for upstreaming patches, you
could check page 16 for how to use the git tool.
[1] https://elinux.org/images/2/26/Getting-Your-Patches-in-Mainline-Linux-What-Not-To-Do-and-a-Few-Things-You-Could-Try-Instead-Marc-Zyngier-ARM.pdf
Thanks,
Leo Yan
Hi Liu Yan,
On Friday, March 22, 2019 9:59 AM, Leo Yan <[email protected]> wrote:
> Hi Solomon,
>
> On Fri, Mar 22, 2019 at 12:47:11AM +0000, Solomon Tan wrote:
>
> [...]
>
> > > On my side this patch is no different from V3, i.e it doesn't pass checkpatch
> > > and it doesn't apply on my next tree.
> > > Mathieu
> > >
> > > >
> > >
> > > pub RSA 2048/C88289A6 [email protected] [email protected]
> > >
> > > > sub RSA 2048/7C5E8D6D 2018-05-09
> >
> > I created a new branch from `next` for the patch mentioned above. Should I
> > have made the patch directly on the `next` branch instead?
> > I ran the following 2 commands to test the files I edited:
> >
> > perl scripts/checkpatch.pl -f tools/build/feature/test-libopencsd.c
> > perl scripts/checkpatch.pl -f tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> >
> >
> > The commands reported that the files "has no obvious style problems and is ready
> > for submission." For your kind advice please. Thank you.
>
> Suggest you to use below flow for sending patch:
>
> - git format HEAD~1: generate patch
> - ./scripts/checkpatch.pl xxxx.patch: check patch format
> - git send-email xxxx.patch: use git to send patch so avoid any
> unexpected characters in the mail
Thank you for your kind guidance. I realised that Mr Poirier
had trouble with my patch because I copied-and-pasted it
into a GUI web client. I was not aware previously that patch
corruptions can happen that way.
I have amended the patch and tested it with both `checkpatch`
and `git am` before sending it out.
>
> P.s. Marc has a good presentation [1] for upstreaming patches, you
> could check page 16 for how to use the git tool.
>
> [1] https://elinux.org/images/2/26/Getting-Your-Patches-in-Mainline-Linux-What-Not-To-Do-and-a-Few-Things-You-Could-Try-Instead-Marc-Zyngier-ARM.pdf
>
> Thanks,
> Leo Yan
>