linux-dev/drivers/ata/Kconfig, branch master

ata: ahci_st: Enable compile test

2022-09-19T23:52:02Z

Enable compiling the ahci_st driver when COMPILE_TEST is enabled. Signed-off-by: Damien Le Moal

ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support

2022-09-16T16:40:31Z

It's almost fully compatible DWC AHCI SATA IP-core derivative except the reference clocks source, which need to be very carefully selected. In particular the DWC AHCI SATA PHY can be clocked either from the pads ref_pad_clk_{m,p} or from the internal wires ref_alt_clk_{m,n}. In the later case the clock signal is generated from the Baikal-T1 CCU SATA PLL. The clocks source is selected by means of the ref_use_pad wire connected to the CCU SATA reference clock CSR. In normal situation it would be much more handy to use the internal reference clock source, but alas we haven't managed to make the AHCI controller working well with it so far. So it's preferable to have the controller clocked from the external clock generator and fallback to the internal clock source only as a last resort. Other than that the controller is full compatible with the DWC AHCI SATA IP-core. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: ahci: Add DWC AHCI SATA controller support

2022-09-16T16:40:15Z

Synopsys AHCI SATA controller can work pretty under with the generic AHCI-platform driver control. But there are vendor-specific peculiarities which can tune the device performance up and which may need to be fixed up for proper device functioning. In addition some DWC AHCI-based controllers may require small platform-specific fixups, so adding them in the generic AHCI driver would have ruined the code simplicity. Shortly speaking in order to keep the generic AHCI-platform code clean and have DWC AHCI SATA-specific features supported we suggest to add a dedicated DWC AHCI SATA device driver. Aside with the standard AHCI-platform resources getting, enabling/disabling and the controller registration the new driver performs the next actions. First of all there is a way to verify whether the HBA/ports capabilities activated in OF are correct. Almost all features availability is reflected in the vendor-specific parameters registers. So the DWC AHCI driver does the capabilities sanity check based on the corresponding fields state. Secondly if either the Command Completion Coalescing or the Device Sleep feature is enabled the DWC AHCI-specific internal 1ms timer must be fixed in accordance with the application clock signal frequency. In particular the timer value must be set to be Fapp * 1000. Normally the SoC designers pre-configure the TIMER1MS register to contain a correct value by default. But the platforms can support the application clock rate change. If that happens the 1ms timer value must be accordingly updated otherwise the dependent features won't work as expected. In the DWC AHCI driver we suggest to rely on the "aclk" reference clock rate to set the timer interval up. That clock source is supposed to be the AHCI SATA application clock in accordance with the DT bindings. Finally DWC AHCI SATA controller AXI/AHB bus DMA-engine can be tuned up to transfer up to 1024 * FIFO words at a time by setting the Tx/Rx transaction size in the DMA control register. The maximum value depends on the DMA data bus and AXI/AHB bus maximum burst length. In most of the cases it's better to set the maximum possible value to reach the best AHCI SATA controller performance. But sometimes in order to improve the system interconnect responsiveness, transferring in smaller data chunks may be more preferable. For such cases and for the case when the default value doesn't provide the best DMA bus performance we suggest to use the new HBA-port specific DT-properties "snps,{tx,rx}-ts-max" to tune the DMA transactions size up. After all the settings denoted above are handled the DWC AHCI SATA driver proceeds further with the standard AHCI-platform host initializations. Note since DWC AHCI controller is now have a dedicated driver we can discard the corresponding compatible string from the ahci-platform.c module. The same concerns "snps,spear-ahci" compatible string, which is also based on the DWC AHCI IP-core. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: make PATA_PLATFORM selectable only for suitable architectures

2022-09-16T14:24:06Z

It is currently possible to select "Generic platform device PATA support" in two situations: - architecture allows the generic platform device PATA support and indicates that with "select HAVE_PATA_PLATFORM". - if the user claims to be an EXPERT by setting CONFIG_EXPERT to yes However, there is no use case to have Generic platform device PATA support in a kernel build if the architecture definition, i.e., the selection of configs by an architecture, does not support it. If the architecture definition is wrong, i.e., it just misses a 'select HAVE_PATA_PLATFORM', then even an expert that configures the kernel build should not just fix that by overruling the claimed support by an architecture. If the architecture definition is wrong, the expert should just provide a patch to correct the architecture definition instead---in the end, if the user is an expert, sending a quick one-line patch should not be an issue. In other words, I do not see the deeper why an expert can overrule the architecture definition in this case, as the expert may not overrule the config selections defined by the architecture in the large majority ---or probably all other (modulo some mistakes)---of similar cases. Signed-off-by: Lukas Bulwahn Reviewed-by: Arnd Bergmann Signed-off-by: Damien Le Moal

ata: clean up how architectures enable PATA_PLATFORM and PATA_OF_PLATFORM

2022-09-16T14:24:06Z

There are two options for platform device PATA support: PATA_PLATFORM: Generic platform device PATA support PATA_OF_PLATFORM: OpenFirmware platform device PATA support If an architecture allows the generic platform device PATA support, it shall select HAVE_PATA_PLATFORM. Then, Generic platform device PATA support is available and can be selected. If an architecture has OpenFirmware support, which it indicates by selecting OF, OpenFirmware platform device PATA support is available and can be selected. If OpenFirmware platform device PATA support is selected, then the functionality (code files) from Generic platform device PATA support needs to be integrated in the kernel build for the OpenFirmware platform device PATA support to work. Select PATA_PLATFORM in PATA_OF_PLATFORM to make sure the needed files are added in the build. So, architectures with OpenFirmware support, do not need to additionally select HAVE_PATA_PLATFORM. It is only needed by architecture that want the non-OF pata-platform module. Reflect this way of intended use of config symbols in the ata Kconfig and adjust all architecture definitions. This follows the suggestion from Arnd Bergmann (see Link). Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/all/4b33bffc-2b6d-46b4-9f1d-d18e55975a5a@www.fastmail.com/ Signed-off-by: Lukas Bulwahn Reviewed-by: Arnd Bergmann Signed-off-by: Damien Le Moal

ata: ahci_brcm: bcmbca: Replace ARCH_BCM_63XX with ARCH_BCMBCA

2022-07-08T21:09:19Z

Prepare for the BCM63138 ARCH_BCM_63XX migration to ARCH_BCMBCA. Make AHCI_BRCM depending on ARCH_BCMBCA. Signed-off-by: William Zhang Acked-by: Damien Le Moal Acked-by: Florian Fainelli Signed-off-by: Florian Fainelli

ata: ahci: Rename CONFIG_SATA_LPM_POLICY configuration item back

2022-04-06T02:08:04Z

CONFIG_SATA_LPM_MOBILE_POLICY was renamed to CONFIG_SATA_LPM_POLICY in commit 4dd4d3deb502 ("ata: ahci: Rename CONFIG_SATA_LPM_MOBILE_POLICY configuration item"). This can potentially cause problems as users would invisibly lose configuration policy defaults when they built the new kernel. To avoid such problems, switch back to the old name (even if it's wrong). Suggested-by: Christoph Hellwig Suggested-by: Damien Le Moal Signed-off-by: Mario Limonciello Signed-off-by: Damien Le Moal

ata: ahci: Rename CONFIG_SATA_LPM_MOBILE_POLICY configuration item

2022-03-01T14:51:20Z

`CONFIG_SATA_LPM_MOBILE_POLICY` reflects a configuration to apply only to mobile chipsets. As some desktop boards may want to use this policy by default as well, rename the configuration item to `SATA_LPM_POLICY`. Reviewed-by: Hans de Goede Reviewed-by: Paul Menzel Signed-off-by: Mario Limonciello Signed-off-by: Damien Le Moal

ata: Kconfig: fix sata gemini compile test condition

2022-02-20T00:06:05Z

When compile testing the sata gemini driver, CONFIG_OF is required to avoid the warning: drivers/ata/sata_gemini.c:421:34: error: ‘gemini_sata_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Damien Le Moal

ata: pata_samsung_cf: add compile test support

2022-01-14T06:17:17Z

Add Kconfig dependendy on COMPILE_TEST to allow compile tests with configs that do not enable SAMSUNG_DEV_IDE. Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke