Hi Cyrille, Le Wed, 19 Oct 2016 18:42:36 +0200, Cyrille Pitchen <cyrille.pitchen@xxxxxxxxx> a écrit : > Hi Albert, > > +Yunhui > It seems that both Yunhui and you work on the same topic, maybe you can > synchronize? > https://patchwork.ozlabs.org/patch/660356/ I am already preparing a v2 based over Yunhui's series. :) > I don't think it is a good thing to select the relevant "READ" LUT entry > according to the command op code. What if spi-nor.c introduces new op codes? > > Maybe you could index the LUT entries by functions: > - READ_REG: the LUT op code would be dynamically updated by your > .read_reg(nor, opcode, ...) implementation according to opcode. > - WRITE_REG: the same as above with the .write_reg(nor, opcode, ...) hook. > - READ_SLAVE1: read memory from the first SPI-NOR memory. > - WRITE_SLAVE1: write into the first SPI-NOR memory. > - READ_SLAVE2: read memory form the 2nd SPI-NOR memory. > ... > - WRITE_SLAVEN: write into the N-th SPI-NOR memory. Actually, my needs could be met using Han Xu's dynamic LUT entries without the need to introduce 'virtual' opcodes (and without having to 'leak back' those new opcodes into other kernel code portions). The per-slave differences (in my case, bus width essentially) can be managed though DT entries and corresponding per-nor flags in the driver. > Also be aware even for the .read() hook the nor->read_opcode might changes > between calls! Noted -- I'll check that the driver always use the current NOR codes. > I don't know whether those comments fit your actual needs and the Freescale SPI > controller hardware constraints but I'm always worried about the ease to maintain > SPI-NOR controller drivers when they are not "op code agnostic". Understood and agreed. Thanks for yuor feedback! > Best regards, > > Cyrille Cordialement, Albert ARIBAUD 3ADEV -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
