- 21 Sep, 2022 2 commits
-
-
Niklas Cassel authored
ACS-5 section 7.13.6.41 Words 85..87, 120: Commands and feature sets supported or enabled states that: If bit 15 of word 86 is set to one, bit 14 of word 119 is set to one, and bit 15 of word 119 is cleared to zero, then word 119 is valid. If bit 15 of word 86 is set to one, bit 14 of word 120 is set to one, and bit 15 of word 120 is cleared to zero, then word 120 is valid. (This text also exists in really old ACS standards, e.g. ACS-3.) Currently, ata_id_sense_reporting_enabled() and ata_id_has_sense_reporting() both check bit 15 of word 86, but neither of them check that bit 14 of word 119 is set to one, or that bit 15 of word 119 is cleared to zero. Additionally, make ata_id_sense_reporting_enabled() return false if !ata_id_has_sense_reporting(), similar to how e.g. ata_id_flush_ext_enabled() returns false if !ata_id_has_flush_ext(). Fixes: e87fd28c ("libata: Implement support for sense data reporting") Signed-off-by:
Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com>
-
ye xingchen authored
Return the value ata_port_abort() directly instead of storing it in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
- 19 Sep, 2022 2 commits
-
-
Damien Le Moal authored
Enable compiling the ahci_st driver when COMPILE_TEST is enabled. Signed-off-by: -
Damien Le Moal authored
Remove the unused variable dev in st_ahci_probe() to avoid compilation warning and build failures where CONFIG_WERROR is enabled. Fixes: 3f74cd04 ("ata: libahci_platform: Parse ports-implemented property in resources getter") Signed-off-by:
-
- 16 Sep, 2022 29 commits
-
-
Serge Semin authored
Add myself as a maintainer of the new DWC AHCI SATA driver and its DT-bindings schema. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by:
-
Serge Semin authored
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:Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Serge Semin authored
Some DWC AHCI SATA IP-core derivatives require to perform small platform or IP-core specific setups. They are too small to be placed in a dedicated driver. It's just much easier to have a set of quirks for them right in the DWC AHCI driver code. Since we are about to add such platform support, as a pre-requisite we introduce a platform-data based DWC AHCI quirks API. The platform data can be used to define the flags passed to the ahci_platform_get_resources() method, additional AHCI host-flags and a set of callbacks to initialize, re-initialize and clear the platform settings. Signed-off-by:
-
Serge Semin authored
Baikal-T1 AHCI controller is based on the DWC AHCI SATA IP-core v4.10a with the next specific settings: two SATA ports, cascaded CSR access based on two clock domains (APB and AXI), selectable source of the reference clock (though stable work is currently available from the external source only), two reset lanes for the application and SATA ports domains. Other than that the device is fully compatible with the generic DWC AHCI SATA bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Serge Semin authored
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 authored
Since all the clocks are retrieved by the method ahci_platform_get_resources() there is no need for the LLD (glue) drivers to be looking for some particular of them in the kernel clocks table again. Instead we suggest to add a simple method returning a device-specific clock with passed connection ID if it is managed to be found. Otherwise the function will return NULL. Thus the glue-drivers won't need to either manually touching the hpriv->clks array or calling clk_get()-friends. The AHCI platform drivers will be able to use the new function right after the ahci_platform_get_resources() method invocation and up to the device removal. Note the method is left unused here, but will be utilized in the framework of the DWC AHCI SATA driver being added in the next commit. Signed-off-by:
-
Serge Semin authored
Synopsys AHCI SATA controller is mainly compatible with the generic AHCI SATA controller except a few peculiarities and the platform environment requirements. In particular it can have at least two reference clocks to feed up its AHB/AXI interface and SATA PHYs domain and at least one reset control for the application clock domain. In addition to that the DMA interface of each port can be tuned up to work with the predefined maximum data chunk size. Note unlike generic AHCI controller DWC AHCI can't have more than 8 ports. All of that is reflected in the new DWC AHCI SATA device DT binding. Note the DWC AHCI SATA controller DT-schema has been created in a way so to be reused for the vendor-specific DT-schemas (see for example the "snps,dwc-ahci" compatible string binding). One of which we are about to introduce. Signed-off-by:
-
Serge Semin authored
There are systems with no BIOS or comprehensive embedded firmware which could be able to properly initialize the SATA AHCI controller platform-specific capabilities. In that case a good alternative to having a clever bootloader is to create a device tree node with the properties well describing all the AHCI-related platform specifics. All the settings which are normally detected and marked as available in the HBA and its ports capabilities fields [1] could be defined in the platform DTB by means of a set of the dedicated properties. Such approach perfectly fits to the DTB-philosophy - to provide hardware/platform description. So here we suggest to extend the SATA AHCI device tree bindings with two additional DT-properties: 1) "hba-cap" - HBA platform generic capabilities like: - SSS - Staggered Spin-up support. - SMPS - Mechanical Presence Switch support. 2) "hba-port-cap" - HBA platform port capabilities like: - HPCP - Hot Plug Capable Port. - MPSP - Mechanical Presence Switch Attached to Port. - CPD - Cold Presence Detection. - ESP - External SATA Port. - FBSCP - FIS-based Switching Capable Port. All of these capabilities require to have a corresponding hardware configuration. Thus it's ok to have them defined in DTB. Even though the driver currently takes into account the state of the ESP and FBSCP flags state only, there is nothing wrong with having all of them supported by the generic AHCI library in order to have a complete OF-based platform-capabilities initialization procedure. These properties will be parsed in the ahci_platform_get_resources() method and their values will be stored in the saved_* fields of the ahci_host_priv structure, which in its turn then will be used to restore the H.CAP, H.PI and P#.CMD capability fields on device init and after HBA reset. Please note this modification concerns the HW-init HBA and its ports flags only, which are by specification [1] are supposed to be initialized by the BIOS/platform firmware/expansion ROM and which are normally declared in the one-time-writable-after-reset register fields. Even though these flags aren't supposed to be cleared after HBA reset some AHCI instances may violate that rule so we still need to perform the fields resetting after each reset. Luckily the corresponding functionality has already been partly implemented in the framework of the ahci_save_initial_config() and ahci_restore_initial_config() methods. [1] Serial ATA AHCI 1.3.1 Specification, p. 103 Signed-off-by:
-
Serge Semin authored
The port base address may be required even before the ata_host instance is initialized and activated, for instance in the ahci_save_initial_config() method which we are about to update (consider this modification as a preparation for that one). Seeing the __ahci_port_base() function isn't used much it's the best candidate to provide the required functionality. So let's convert it to accepting the ahci_host_priv structure pointer. Signed-off-by:
-
Serge Semin authored
There is no point in reading the AHCI version all over in the tail of the ahci_save_initial_config() method. That register is RO and doesn't change its value even after reset. So just reuse the data, which has already been read from there earlier in the head of the function. Signed-off-by:
-
Serge Semin authored
Currently there are four port-map-related fields declared in the ahci_host_priv structure and used to setup the HBA ports mapping. First the ports-mapping is read from the PI register and immediately stored in the saved_port_map field. If forced_port_map is initialized with non-zero value then its value will have greater priority over the value read from PI, thus it will override the saved_port_map field. That value will be then masked by a non-zero mask_port_map field and after some sanity checks it will be stored in the ahci_host_priv.port_map field as a final port mapping. As you can see the logic is a bit too complicated for such a simple task. We can freely get rid from at least one of the fields with no change to the implemented semantic. The force_port_map field can be replaced with taking non-zero saved_port_map value into account. So if saved_port_map is pre-initialized by the low level drivers (platform drivers) then it will have greater priority over the value read from PI register and will be used as actual HBA ports mapping later on. Thus the ports map forcing task will be just transferred from force_port_map to the saved_port_map field. This modification will perfectly fit into the feature of having OF-based initialization of the HW-init HBA CSR fields we are about to introduce in the next commit. Signed-off-by:
-
Serge Semin authored
Currently not all of the Port-specific capabilities listed in the PORT_CMD-enumeration. Let's extend that set with the Cold Presence Detection and Mechanical Presence Switch attached to the Port flags [1] so to closeup the set of the platform-specific port-capabilities flags. Note these flags are supposed to be set by the platform firmware if there is one. Alternatively as we are about to do they can be set by means of the OF properties. While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DMPS and fix the comment there. In accordance with [2] that IRQ flag is supposed to indicate the state of the signal coming from the Mechanical Presence Switch. [1] Serial ATA AHCI 1.3.1 Specification, p.27 [2] Serial ATA AHCI 1.3.1 Specification, p.24, p.88 Signed-off-by:
-
Serge Semin authored
In case if the platform doesn't have BIOS or a comprehensive firmware installed then the HBA capability flags will be left uninitialized. As a good alternative we suggest to define the DT-properties with the AHCI platform capabilities describing all the HW-init flags of the corresponding capability register. Luckily there aren't too many of them. SSS - Staggered Spin-up support and MPS - Mechanical Presence Switch support determine the corresponding feature availability for the whole HBA by means of the "hba-cap" property. Each port can have the "hba-port-cap" property initialized indicating that the port supports some of the next functionalities: HPCP - HotPlug capable port, MPSP - Mechanical Presence Switch attached to a port, CPD - Cold Plug detection, ESP - External SATA Port (eSATA), FBSCP - FIS-based switching capable port. Signed-off-by:
-
Serge Semin authored
Currently the ACHI-platform library supports only the assert and deassert reset signals and ignores the platforms with self-deasserting reset lines. That prone to having the platforms with self-deasserting reset method misbehaviour when it comes to resuming from sleep state after the clocks have been fully disabled. For such cases the controller needs to be fully reset all over after the reference clocks are enabled and stable, otherwise the controller state machine might be in an undetermined state. The best solution would be to auto-detect which reset method is supported by the particular platform and use it implicitly in the framework of the ahci_platform_enable_resources()/ahci_platform_disable_resources() methods. Alas it can't be implemented due to the AHCI-platform library already supporting the shared reset control lines. As [1] says in such case we have to use only one of the next methods: + reset_control_assert()/reset_control_deassert(); + reset_control_reset()/reset_control_rearm(). If the driver had an exclusive control over the reset lines we could have been able to manipulate the lines with no much limitation and just used the combination of the methods above to cover all the possible reset-control cases. Since the shared reset control has already been advertised and couldn't be changed with no risk to breaking the platforms relying on it, we have no choice but to make the platform drivers to determine which reset methods the platform reset system supports. In order to implement both types of reset control support we suggest to introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which when passed to the ahci_platform_get_resources() method together with the AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are self-deasserting thus the reset_control_reset()/reset_control_rearm() will be used to control the reset state. Otherwise the reset_control_deassert()/reset_control_assert() methods will be utilized. [1] Documentation/driver-api/reset.rst Signed-off-by:
-
Serge Semin authored
The ports-implemented property is mainly used on the OF-based platforms with no ports mapping initialized by a bootloader/BIOS firmware. Seeing the same of_property_read_u32()-based pattern has already been implemented in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI drivers let's move the property read procedure to the generic ahci_platform_get_resources() method. Thus we'll have the forced ports mapping feature supported for each OF-based platform which requires that, and stop re-implementing the same pattern in there a bit simplifying the code. Signed-off-by:
-
Serge Semin authored
Having greater than AHCI_MAX_PORTS (32) ports detected isn't that critical from the further AHCI-platform initialization point of view since exceeding the ports upper limit will cause allocating more resources than will be used afterwards. But detecting too many child DT-nodes doesn't seem right since it's very unlikely to have it on an ordinary platform. In accordance with the AHCI specification there can't be more than 32 ports implemented at least due to having the CAP.NP field of 5 bits wide and the PI register of dword size. Thus if such situation is found the DTB must have been corrupted and the data read from it shouldn't be reliable. Let's consider that as an erroneous situation and halt further resources allocation. Note it's logically more correct to have the nports set only after the initialization value is checked for being sane. So while at it let's make sure nports is assigned with a correct value. Signed-off-by:
-
Serge Semin authored
In order to simplify the clock-related code there is a way to convert the current fixed clocks array into using the common bulk clocks kernel API with dynamic set of the clock handlers and device-managed clock-resource tracking. It's a bit tricky due to the complication coming from the requirement to support the platforms (da850, spear13xx) with the non-OF-based clock source, but still doable. Before this modification there are two methods have been used to get the clocks connected to an AHCI device: clk_get() - to get the very first clock in the list and of_clk_get() - to get the rest of them. Basically the platforms with non-OF-based clocks definition could specify only a single reference clock source. The platforms with OF-hw clocks have been luckier and could setup up to AHCI_MAX_CLKS clocks. Such semantic can be retained with using devm_clk_bulk_get_all() to retrieve the clocks defined via the DT firmware and devm_clk_get_optional() otherwise. In both cases using the device-managed version of the methods will cause the automatic resources deallocation on the AHCI device removal event. The only complicated part in the suggested approach is the explicit allocation and initialization of the clk_bulk_data structure instance for the non-OF reference clocks. It's required in order to use the Bulk Clocks API for the both denoted cases of the clocks definition. Note aside with the clock-related code reduction and natural simplification, there are several bonuses the suggested modification provides. First of all the limitation of having no greater than AHCI_MAX_CLKS clocks is now removed, since the devm_clk_bulk_get_all() method will allocate as many reference clocks data descriptors as there are clocks specified for the device. Secondly the clock names are auto-detected. So the LLDD (glue) drivers can make sure that the required clocks are specified just by checking the clock IDs in the clk_bulk_data array. Thirdly using the handy Bulk Clocks kernel API improves the clocks-handling code readability. And the last but not least this modification implements a true optional clocks support to the ahci_platform_get_resources() method. Indeed the previous clocks getting procedure just stopped getting the clocks on any errors (aside from non-critical -EPROBE_DEFER) in a way so the callee wasn't even informed about abnormal loop termination. The new implementation lacks of such problem. The ahci_platform_get_resources() will return an error code if the corresponding clocks getting method ends execution abnormally. Signed-off-by:
-
Serge Semin authored
Currently the IOMEM AHCI registers space is mapped by means of the two functions invocation: platform_get_resource() is used to get the very first memory resource and devm_ioremap_resource() is called to remap that resource. Device-managed kernel API provides a handy wrapper to perform the same in single function call: devm_platform_ioremap_resource(). While at it seeing many AHCI platform drivers rely on having the AHCI CSR space marked with "ahci" name let's first try to find and remap the CSR IO-mem with that name and only if it fails fallback to getting the very first registers space platform resource. Signed-off-by:
-
Serge Semin authored
The Broadcom SATA controller is obviously based on the AHCI standard. The device driver uses the kernel AHCI library to work with it. Therefore we can be have a more thorough DT-bindings evaluation by referring to the AHCI-common schema instead of using the more relaxed SATA-common one. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
-
Serge Semin authored
The denoted in the description upper limit only concerns the Port Multipliers, but not the actual SATA ports. It's an external device attached to a SATA port in order to access more than one SATA-drive. So when it's attached to a SATA port it just extends the port capability while the number of actual SATA ports stays the same. For instance on AHCI controllers the number of actual ports is determined by the CAP.NP field and the PI (Ports Implemented) register. AFAICS in general the maximum number of SATA ports depends on the particular controller implementation. Generic AHCI controller can't have more than 32 ports (since CAP.NP is of 5 bits wide and PI register is 32-bits size), while DWC AHCI SATA controller can't be configured with more than 8 ports activated. So let's discard the SATA ports reg-property restrictions and just make sure that it consists of a single reg-item. Signed-off-by:
-
Serge Semin authored
Indeed in accordance with what is implemented in the AHCI platform driver and the way the AHCI DT nodes are defined in the DT files we can add the next AHCI DT properties constraints: AHCI CSR ID is fixed to 'ahci', PHY name is fixed to 'sata-phy', AHCI controller can't have more than 32 ports by design, AHCI controller can have up to 32 IRQ lines. Signed-off-by:
-
Serge Semin authored
In order to create a more sophisticated AHCI controller DT bindings let's divide the already available generic AHCI platform YAML schema into the platform part and a set of the common AHCI properties. The former part will be used to evaluate the AHCI DT nodes mainly compatible with the generic AHCI controller while the later schema will be used for more thorough AHCI DT nodes description. For instance such YAML schemas design will be useful for our DW AHCI SATA controller derivative with four clock sources, two reset lines, one system controller reference and specific max Rx/Tx DMA xfers size constraints. Note the phys and target-supply property requirement is preserved in the generic AHCI platform bindings because some platforms can lack of the explicitly specified PHYs or target device power regulators. Also note the SATA/AHCI ports properties have been moved to the $defs-paragraph of the schemas. It's done in order to create the extendable properties hierarchy such that particular AHCI-controller could add vendor-specific port properties. Signed-off-by:
-
Serge Semin authored
Seeing doubtfully any SATA device working without embedded DMA engine let's permit the device nodes being equipped with the dma-coherent property in case if the platform is capable of cache-coherent DMAs. As a side-effect we can drop the explicit dma-coherent property definition from the particular device schemas. Currently it concerns the Broadcom SATA AHCI controller only. Signed-off-by:
-
Lukas Bulwahn authored
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 <lukas.bulwahn@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Lukas Bulwahn authored
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:
-
Li Zhong authored
sata_scr_read() could return negative error code on failure. Check the return value when reading the control register. Signed-off-by:
Li Zhong <floridsleeves@gmail.com> Signed-off-by:
-
Shaomin Deng authored
Remove the repeated word "Transfer" in comments. Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
Shaomin Deng authored
There is unneeded word "to" in line 669, so remove it. Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
-
Damien Le Moal authored
The err_mask variable is not useful. Remove it. Signed-off-by:
-
- 25 Aug, 2022 4 commits
-
-
Damien Le Moal authored
Since ata_build_rw_tf() is only called from ata_scsi_rw_xlat() with the tf, dev and tag arguments obtained from the queued command structure, we can simplify the interface of ata_build_rw_tf() by passing directly the qc structure as argument. Furthermore, since ata_scsi_rw_xlat() is never used for internal commands, we can also remove the internal tag check for the NCQ case. Signed-off-by: -
Damien Le Moal authored
Rename ATA_DFLAG_NCQ_PRIO_ENABLE to ATA_DFLAG_NCQ_PRIO_ENABLED to match the fact that this flags indicates if NCQ priority use is enabled by the user. Signed-off-by: -
Jinpeng Cui authored
Return value from ata_exec_internal() directly instead of taking this in another redundant variable. Reported-by:
Jinpeng Cui <cui.jinpeng2@zte.com.cn> Signed-off-by:
-
Rafael J. Wysocki authored
The ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to use low-power S0 idle on the given platform than S3 (provided that the latter is supported) and it doesn't preclude using either of them (which of them will be used depends on the choices made by user space). For this reason, there is no benefit from checking that flag in ahci_update_initial_lpm_policy(). First off, it cannot be a bug to do S3 with policy set to either ATA_LPM_MIN_POWER_WITH_PARTIAL or ATA_LPM_MIN_POWER, because S3 can be used on systems with ACPI_FADT_LOW_POWER_S0 set and it must work if really supported, so the ACPI_FADT_LOW_POWER_S0 check is not needed to protect the S3-capable systems from failing. Second, suspend-to-idle can be carried out on a system with ACPI_FADT_LOW_POWER_S0 unset and it is expected to work, so if setting policy to either ATA_LPM_MIN_POWER_WITH_PARTIAL or ATA_LPM_MIN_POWER is needed to handle that case correctly, it should be done regardless of the ACPI_FADT_LOW_POWER_S0 value. Accordingly, replace the ACPI_FADT_LOW_POWER_S0 check in ahci_update_initial_lpm_policy() with pm_suspend_default_s2idle() which is more general and also takes the user's preference into account and drop the CONFIG_ACPI #ifdef around it that is not necessary any more. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
- 17 Aug, 2022 2 commits
-
-
Niklas Cassel authored
ata_dev_set_feature() is currently used for enabling/disabling any ATA feature, e.g. SETFEATURES_SPINUP and SETFEATURE_SENSE_DATA, i.e. it is not only used to enable/disable SATA specific features. For most features, the enable/disable bit is specified in the subcommand specific field "count". It is only for the specific subcommands "Enable SATA feature" (0x10) and "Disable SATA feature" (0x90) where the field "count" is used to specify a feature instead of enable/disable. The parameter names for this function are thus quite misleading. Rename the parameter names to be more generic and in line with ACS-5, and remove the references to "SATA FEATURES" in the kernel-doc. Signed-off-by:
-
Tomas Henzl authored
Printing the timeout value may help in troubleshooting failures. Signed-off-by:
David Milburn <dmilburn@redhat.com> Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
- 14 Aug, 2022 1 commit
-
-
Linus Torvalds authored
-
