Hi Shijie,
>
> > Hello Huang,
> >
> > >> In what way does the controller driver depend on those changes?
> > > This driver needs the spi nor command to fill the LUT register, such as
> > > OPCODE_WREN(0x06), so the patch 1 moves the spi nor command to a
> seprate
> > > header spi-nor.h, and this driver includes this new header.
> > >
> > Then some questions come up:
> > - Why does the spi controller need to know this?
> The hardware works in this way.
> > - What is this LUT register at all?
> Please see the patch 1.
> > - What happens if something different that a flash is connected and
> > the data starts with one of these opcodes?
> Submit a new patch to fix it.
>
This is not the correct approach, because for every NOR flash device
user needs to submit a patch to populate these LUT with CMD, OPERAND
and DUMMY values specific to that NOR device into these header files.
As the supported NOR device list grows, the header file would become
unmanageable and cluttered.
I would rather suggest to get these values from DT bindings specific to
your fsl-qspi-controller. This way you would provide scalability without
affecting other framework. This should also help you to keep your
MTD driver independent of QSPI-controller driver.
With regards, pekon
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
