Hi Wolfram,
On Tue, Sep 26, 2023 at 9:59 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Tue, Sep 26, 2023 at 9:48 AM Wolfram Sang
> <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > > An alternative would be to let cpg_sdh_clk_register() sanitize the
> > > > pre-existing contents of the SD-IFn Clock Frequency Control Register,
> > > > so there would be no need to extend cpg_sdh_div_table[]. An advantage
> > > > of that approach would be that it can handle all invalid combinations,
> > > > not just the few that have been seen in the wild.
> > > > (following the old networking mantra: "be strict when sinding, be
> > > > liberal when receiving').
> > >
> > > That sounds very reasonable to me.
> >
> > Thinking further: Sanitizing a pre-existing value of SDH means also
> > sanitizing the value of SD because only specific combinations of these
> > are recommended (or even "allowed" as I read it). This is getting a bit
> > complicated. What about just applying a default value to SDH and SD
> > which is from the recommended set of parameters? That will also help
> > when probing the clocks. Once SDHI probes, it will modify clocks anyhow.
>
> Sounds fine to me, thanks!
On second thought, on a system where SDHI is assigned to the RT core,
this would interfere with the software running on the RT core. So I
think it would only be safe to overwrite with a default value when
the current register values are invalid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
