On 07/20/2016 04:25 AM, Mark Brown wrote: > On Tue, Jul 19, 2016 at 03:15:49PM -0700, Florian Fainelli wrote: >> On 07/13/2016 03:36 PM, Mark Brown wrote: > >>> If it was unconditionally in the perhipheral it'd be fairly normal and >>> standard but it's not, it's a completely separate and optional register >>> block with a bunch of separate code in a driver which already has above >>> average complexity even for the bits that belong in it. > >> It is not separate nor optional, the fact that the register range seems >> discontiguous is just an integration choice here, but it contains bits >> that are relevant exclusively to the SPI controller. > > Some versions of the block have it, some versions of the block don't > have it. That suggests that it's optional. It is a completely separate > register map, that suggests that it is an external block. Mark, would you oppose to a driver structure that looks like the Broadcom NAND driver under drivers/mtd/nand/brcmnand/, where we have something like this: - the core driver only deals with individual interrupt lines which are available in the original version of the IP block as integrated on Set-top-box/Cable Modem chips - the core driver allows for callbacks to perform additional interupt work when that is required for the iProc (Northstar, Northstar Plus, Northstar 2) and DSL SoCs where we have additional logic to enable/disable/acknowledge interrupt lines We came up with this design for the NAND controller driver pretty much for the same reasons that the NAND controller originally came from the STB/CM group and was later adopted by the iProc SoCs and integrated in a way that made the number of layout of interrupts and control register different... Thanks -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html