On 16.02.16 11:50:44, Tirumalesh Chalamarla wrote: > > > On 02/16/2016 11:38 AM, David Daney wrote: > >On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote: > >> > >> > >>On 02/16/2016 06:42 AM, Robert Richter wrote: > >>>On 15.02.16 13:30:41, Tejun Heo wrote: > >>>>On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote: > >>>>>There is no need for special Driver, AHCI is sufficient for > >>>>>ThunderX, the > >>>>>file only contains this interrupt handler, > >>>>>is it preferable if this interrupt handler in libahci.c with others, > >>>>>instead > >>>>>of separate file? > >>>> > >>>>Yeap, just fold it in ahci.c with surrounding #ifdef guard. > >>> > >>>Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a > >>>kconfig entry for this to arch/arm64/Kconfig. > >>> > >>Are you sure, this is not a workaround that is based on alternative > >>framework rather on pci device and vendor > >> > >>do you think CONFIG_ARCH_THUNDER a good alternative? > > > >No. CONFIG_ARCH_THUNDER should be removed all together. > > > >Grouping a bunch of unrelated features under a single config variable > >creates a very brittle system. What are you going to do when a new > >hardware revision is released? Create CONFIG_ARCH_THUNDER2? Which one > >of these two would you select if building a kernel? It is a choice that > >we don't want to force users (kernel builders) to have to waste mental > >energy on. > > > >Instead, let's try to make things work out of the box without having to > >set a bunch of random config variables. > > > >If a generic arm64 kernel won't get too bloated, I would suggest just > >enabling the compilation of the code unconditionally (at least for > >arm64). The use of the code would still be gated by the PCI version > >probe that is part of the patch. > > > > exactly, that is my initial choice with v1, and only depends on vendor and > device id. > > but it seems a config is needed. how about ARCH_ARM64 then? CONFIG_CAVIUM_ERRATUM_22536 is exactly that you need. It is not only used for core interrupts, e.g. also for gicv3 devices (and now also for ahci). Non-core errata (e.g. CONFIG_CAVIUM_ERRATUM_23144) are not enabled in the arm64 cpu errata framework (not handled in arch/arm64/kernel/cpu_errata.c). Thus, #ifdef CONFIG_CAVIUM_ERRATUM_22536 if (pdev->vendor == 0x177d && pdev->device == 0xa01c) ahci_thunderx_init(&pdev->dev, hpriv); #endif is the correct enablement of the workaround by device id. And, CAVIUM_ERRATUM_* is very easy to handle, enable and document. -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html