Hello Ard,
On Fri, Sep 12, 2014 at 09:42:29AM +0200, Ard Biesheuvel wrote:
> On 12 September 2014 00:04, Uwe Kleine-König
> <u.kleine-koe...@pengutronix.de> wrote:
> > Hello,
> >
> > On Thu, Sep 11, 2014 at 11:04:31PM +0200, Uwe Kleine-König wrote:
> >> /* Mux parent lists. */
> >> -static const char *fin_pll_p[] __initconst = {
> >> +static const char *fin_pll_p[] __initdata = {
> >> "xxti",
> >> "xusbxti"
> >> };
> > As discussed with Tomasz on irc: The sad thing here is that for this
> > array only 8 bytes are freed when .init.rodata is thrown away (that is
> > two pointers). The actual data---5 + 8 bytes + maybe aligning---isn't
> > freed though.
> >
> > We wondered if there is a nice and easy way to throw away the
> > characters, too.
> >
> > The only way I currently see is:
> >
> > const char xxti[] __initconst = "xxti";
> > ...
> >
> > static const char *fin_pll_p[] __initdata = {
> > xxti,
> > ...
> > };
> >
> > but this definitively doesn't qualify as "nice and easy". Is there an
> > alternative?
> >
>
> What about doing
>
> static const char fin_pll_p[][8] __initconst = {
> "xxti",
> "xusbxti"
> };
This results in the strings being moved to .init.rodata and so they are
discarded. But it also results in:
drivers/clk/samsung/clk-s5pv210.c:412:2: warning: initialization from
incompatible pointer type [enabled by default]
MUX_F(FIN_PLL, "fin_pll", fin_pll_p, OM_STAT, 0, 1,
^
drivers/clk/samsung/clk-s5pv210.c:412:2: warning: (near initialization
for 'early_mux_clks[0].parent_names') [enabled by default]
That's because early_mux_clks[0].parent_names is of type const char **
while fin_pll_p as suggested doesn't provide an array of pointers to the
start of the contained strings.
I don't see a way to fix that unless we fix the maximal clock name
length globally and so waste much memory.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
