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����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f