linux-kernel - Re: [PATCH] drivers: remoteproc: constify rproc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 1 Jan 2017 11:53:37 +0530
From:   Bhumika Goyal <bhumirks@...il.com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Julia Lawall <julia.lawall@...6.fr>,
        Ohad Ben-Cohen <ohad@...ery.com>, patrice.chotard@...com,
        linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, kernel@...inux.com
Subject: Re: [PATCH] drivers: remoteproc: constify rproc_ops structures

On Sat, Dec 31, 2016 at 11:24 PM, Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
> On Sat 31 Dec 02:43 PST 2016, Bhumika Goyal wrote:
>
>> On Fri, Dec 30, 2016 at 5:36 PM, Bjorn Andersson
>> <bjorn.andersson@...aro.org> wrote:
>> > On Sat 17 Dec 03:29 PST 2016, Bhumika Goyal wrote:
>> >
>> >> Declare rproc_ops structures as const as they are only passed as an
>> >> argument to the function rproc_alloc. This argument is of type const, so
>> >> rproc_ops structures having this property can be declared const too.
>> >> Done using Coccinelle:
>> >>
>> >> @r1 disable optional_qualifier @
>> >> identifier i;
>> >> position p;
>> >> @@
>> >> static struct rproc_ops i@p = {...};
>> >>
>> >> @ok1@
>> >> identifier r1.i;
>> >> position p;
>> >> @@
>> >> rproc_alloc(...,&i@p,...)
>> >>
>> >> @bad@
>> >> position p!={r1.p,ok1.p};
>> >> identifier r1.i;
>> >> @@
>> >> i@p
>> >>
>> >> @depends on !bad disable optional_qualifier@
>> >> identifier r1.i;
>> >> @@
>> >> +const
>> >> struct rproc_ops i;
>> >>
>> >> File sizes before:
>> >>    text          data     bss     dec     hex filename
>> >>    1258           416       0    1674     68a remoteproc/omap_remoteproc.o
>> >>    2402           240       0    2642     a52 remoteproc/st_remoteproc.o
>> >>    2064           272       0    2336     920 remoteproc/st_slim_rproc.o
>> >>    2160           240       0    2400     960 remoteproc/wkup_m3_rproc.o
>> >>
>> >> File sizes after:
>> >>    text          data     bss     dec     hex filename
>> >>    1297           368       0    1665     681 remoteproc/omap_remoteproc.o
>> >>    2434           192       0    2626     a42 remoteproc/st_remoteproc.o
>> >>    2112           240       0    2352     930 remoteproc/st_slim_rproc.o
>> >>    2200           192       0    2392     958 remoteproc/wkup_m3_rproc.o
>> >>
>> >> Signed-off-by: Bhumika Goyal <bhumirks@...il.com>
>> >
>> > Thanks Bhumika, this looks good.
>> >
>> > But as Suman already asked. Is there any reason why da8xx_remoteproc.c
>> > did not get updated? It looks like the same change would apply there.
>> >
>> >
>>
>> The reason I did not sent a patch for that driver is because the .o
>> file is not obtained. This is output I get when I try to compile the
>> da8xx_remoteproc.o file.
>>
>> drivers/remoteproc/da8xx_remoteproc.c:22:72: fatal error:
>> mach/clock.h: No such file or directory
>>  #include <mach/clock.h>   /* for davinci_clk_reset_assert/deassert() */
>>                                                                         ^
>> compilation terminated.
>> make[1]: *** [drivers/remoteproc/da8xx_remoteproc.o] Error 1
>> make: *** [drivers/remoteproc/da8xx_remoteproc.o] Error 2
>>
>> I also tried running the commands  make.cross ARCH=arm allyesconfig;
>> make.cross ARCH=arm drivers/remoteproc/da8xx_remoteproc.o but still
>> the error remains the same.
>>
>> Could you please suggest me what to do in this case?
>>
>
> By using davinci_all_defconfig and then selecting
> CONFIG_DA8XX_REMOTEPROC I managed to compile it, not sure what differs.
>

Yes, it compiled. Thanks for the input. Now I will include this driver
as well and send a v2.

Thanks,
Bhumika

> If you can't get it working please include the da8xx_remoteproc change
> as well and just note that you didn't manage to test it.
>
> Regards,
> Bjorn