Increasing the maximum message size

Increasing the maximum message size

[Konrad Dybcio]

Hi,

when sending new clock drivers for Qualcomm SoCs I've been repeatedly
getting a bounce with a reason of "too long (>100000 characters)". The
drivers are pretty big for one email, for example gcc-sc8280xp.c has
201071 chars, but it only makes sense to add them big-as-they-are,
because there are simply so many clocks, each of which needs to be
defined as a struct with its properties set correctly.

Would it be possible to increase the limit for linux-arm-msm and
linux-clk to something like 250000 so that they get to appear on
there?

Konrad

Re: Increasing the maximum message size

[Stephen Boyd]

Quoting Konrad Dybcio (2022-07-23 04:44:32)
> Hi,
> 
> when sending new clock drivers for Qualcomm SoCs I've been repeatedly
> getting a bounce with a reason of "too long (>100000 characters)". The
> drivers are pretty big for one email, for example gcc-sc8280xp.c has
> 201071 chars, but it only makes sense to add them big-as-they-are,
> because there are simply so many clocks, each of which needs to be
> defined as a struct with its properties set correctly.

Maybe it's time to collapse the structs into macro definitions.
Probably a decade ago I expanded the macros that we had because we kept
modifying the struct members while settling on something that described
the clks. Now it doesn't seem very useful to do that because the structs
almost never change. Certainly the struct members aren't changing
rapidly. I'd start with a macro for branches, rcgs, and plls and see how
small it can become. Hopefully there aren't many parameters to the macro
so that it is still somewhat readable.

Re: Increasing the maximum message size

[Abel Vesa]

On 22-07-23 23:43:09, Stephen Boyd wrote:
> Quoting Konrad Dybcio (2022-07-23 04:44:32)
> > Hi,
> >
> > when sending new clock drivers for Qualcomm SoCs I've been repeatedly
> > getting a bounce with a reason of "too long (>100000 characters)". The
> > drivers are pretty big for one email, for example gcc-sc8280xp.c has
> > 201071 chars, but it only makes sense to add them big-as-they-are,
> > because there are simply so many clocks, each of which needs to be
> > defined as a struct with its properties set correctly.
>
> Maybe it's time to collapse the structs into macro definitions.
> Probably a decade ago I expanded the macros that we had because we kept
> modifying the struct members while settling on something that described
> the clks. Now it doesn't seem very useful to do that because the structs
> almost never change. Certainly the struct members aren't changing
> rapidly. I'd start with a macro for branches, rcgs, and plls and see how
> small it can become. Hopefully there aren't many parameters to the macro
> so that it is still somewhat readable.

Actually, I was working on this and have something ready to be sent. I
started with sdm845 couple of weeks ago. I'll send it today as RFC. We
can continue with other platforms once that has been accepted, if that
is OK for everyone.