1. 21 Sep, 2022 2 commits
  2. 19 Sep, 2022 2 commits
  3. 16 Sep, 2022 29 commits
    • Serge Semin's avatar
      MAINTAINERS: Add maintainers for DWC AHCI SATA driver · e7840a9a
      Serge Semin authored
      Add myself as a maintainer of the new DWC AHCI SATA driver and
      its DT-bindings schema.
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      e7840a9a
    • Serge Semin's avatar
      ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support · 9628711a
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      9628711a
    • Serge Semin's avatar
      ata: ahci-dwc: Add platform-specific quirks support · bc7af910
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      bc7af910
    • Serge Semin's avatar
      dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema · 064f14e9
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      064f14e9
    • Serge Semin's avatar
      ata: ahci: Add DWC AHCI SATA controller support · 33629d35
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      33629d35
    • Serge Semin's avatar
      ata: libahci_platform: Add function returning a clock-handle by id · 6ce73f3a
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      6ce73f3a
    • Serge Semin's avatar
      dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema · 5c640bec
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      5c640bec
    • Serge Semin's avatar
      ata: ahci: Introduce firmware-specific caps initialization · 18ee7c49
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      18ee7c49
    • Serge Semin's avatar
      ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments · 7cbbfbe0
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      7cbbfbe0
    • Serge Semin's avatar
      ata: libahci: Don't read AHCI version twice in the save-config method · fad64dc0
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      fad64dc0
    • Serge Semin's avatar
      ata: libahci: Discard redundant force_port_map parameter · 88589772
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      88589772
    • Serge Semin's avatar
      ata: libahci: Extend port-cmd flags set with port capabilities · eb7cae0b
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      eb7cae0b
    • Serge Semin's avatar
      dt-bindings: ata: ahci: Add platform capability properties · 03f1076f
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      03f1076f
    • Serge Semin's avatar
      ata: libahci_platform: Introduce reset assertion/deassertion methods · f67f12ff
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      f67f12ff
    • Serge Semin's avatar
      ata: libahci_platform: Parse ports-implemented property in resources getter · 3f74cd04
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      3f74cd04
    • Serge Semin's avatar
      ata: libahci_platform: Sanity check the DT child nodes number · 3c132ea6
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      3c132ea6
    • Serge Semin's avatar
      ata: libahci_platform: Convert to using devm bulk clocks API · e28b3abf
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      e28b3abf
    • Serge Semin's avatar
      ata: libahci_platform: Convert to using platform devm-ioremap methods · 82d437e6
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      82d437e6
    • Serge Semin's avatar
      dt-bindings: ata: sata-brcm: Apply common AHCI schema · 2ea4d52a
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      2ea4d52a
    • Serge Semin's avatar
      dt-bindings: ata: sata: Extend number of SATA ports · 388f08ec
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      388f08ec
    • Serge Semin's avatar
      dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints · 9bd24070
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      9bd24070
    • Serge Semin's avatar
      dt-bindings: ata: ahci-platform: Detach common AHCI bindings · 0f3680ed
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      0f3680ed
    • Serge Semin's avatar
      dt-bindings: ata: ahci-platform: Move dma-coherent to sata-common.yaml · 6f997d4b
      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: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      6f997d4b
    • Lukas Bulwahn's avatar
      ata: make PATA_PLATFORM selectable only for suitable architectures · d3243965
      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: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      d3243965
    • Lukas Bulwahn's avatar
      ata: clean up how architectures enable PATA_PLATFORM and PATA_OF_PLATFORM · 3ebe59a5
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/all/4b33bffc-2b6d-46b4-9f1d-d18e55975a5a@www.fastmail.com/Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      3ebe59a5
    • Li Zhong's avatar
      ata: libata-core: Check errors in sata_print_link_status() · 55d5ba55
      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: default avatarLi Zhong <floridsleeves@gmail.com>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      55d5ba55
    • Shaomin Deng's avatar
      ata: libata-sff: Fix double word in comments · 03070458
      Shaomin Deng authored
      Remove the repeated word "Transfer" in comments.
      Signed-off-by: default avatarShaomin Deng <dengshaomin@cdjrlc.com>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      03070458
    • Shaomin Deng's avatar
      ata: pata_macio: Remove unneeded word in comments · 0b2436d3
      Shaomin Deng authored
      There is unneeded word "to" in line 669, so remove it.
      Signed-off-by: default avatarShaomin Deng <dengshaomin@cdjrlc.com>
      Reviewed-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      0b2436d3
    • Damien Le Moal's avatar
      ata: libata-core: Simplify ata_dev_set_xfermode() · 024811a2
      Damien Le Moal authored
      The err_mask variable is not useful. Remove it.
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      024811a2
  4. 25 Aug, 2022 4 commits
  5. 17 Aug, 2022 2 commits
  6. 14 Aug, 2022 1 commit