Hi Boris,
On Mon, 18 Jun 2018 09:46:36 +0200, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> On Mon, 18 Jun 2018 09:09:02 +0200
> Richard Weinberger <rich...@nod.at> wrote:
>
> > Am Freitag, 15. Juni 2018, 03:18:50 CEST schrieb Masahiro Yamada:
> > > According to the Denali User's Guide, this IP needs three clocks:
> > >
> > > - clk: controller core clock
> > >
> > > - clk_x: bus interface clock
> > >
> > > - ecc_clk: clock at which ECC circuitry is run
> > >
> > > Currently, denali_dt.c requires a single anonymous clock and its
> > > frequency. However, the driver needs to get the frequency of "clk_x"
> > > not "clk". This is confusing because people tend to assume the
> > > anonymous clock means the core clock. In fact, I got a report of
> > > SOCFPGA breakage because the timing parameters are calculated based
> > > on a wrong frequency.
> > >
> > > Instead of the cheesy implementation, the clocks in the real hardware
> > > should be represented in the driver and the DT-binding.
> > >
> > > However, adding new clocks would break the existing platforms. For the
> > > backward compatibility, the driver still accepts a single clock just as
> > > before. If clk_x is missing, clk_x_rate is set to a hardcoded value.
> > > This is fine for existing DT of Socionext UniPhier, and also fixes the
> > > issue of Altera (Intel) SOCFPGA because both platforms use 200 MHz for
> > > the bus interface clock.
> > >
> > > Fixes: 1bb88666775e ("mtd: nand: denali: handle timing parameters by
> > > setup_data_interface()")
> > > Cc: linux-stable <sta...@vger.kernel.org> #4.14+
> > > Reported-by: Richard Weinberger <rich...@nod.at>
> > > Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> >
> > Reviewed-by: Richard Weinberger <rich...@nod.at>
>
> Maybe a
>
> Tested-by: Richard Weinberger <rich...@nod.at>
>
> ?
>
> > Reported-by: Philipp Rosenberger <p.rosenber...@linutronix.de>
>
> Should I replace your Reported-by by this one or simply add it?
>
> Miquel, I'll take this patch in mtd/fixes, and let you take the 2
> others in nand/next. That means you'll have to back merge v4.18-rc2
> into the nand/next tree, or base your tree on v4.18-rc2 instead of
> v4.18-rc1.
Sure.
Miquèl
