[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <447f74bb-e1d7-3f6c-9cf8-1db774582803@suse.de>
Date: Thu, 12 May 2022 08:54:41 +0200
From: Hannes Reinecke <hare@...e.de>
To: Serge Semin <Sergey.Semin@...kalelectronics.ru>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Hans de Goede <hdegoede@...hat.com>,
Jens Axboe <axboe@...nel.dk>
Cc: Serge Semin <fancer.lancer@...il.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
Rob Herring <robh+dt@...nel.org>, linux-ide@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 11/23] ata: libahci_platform: Introduce reset
assertion/deassertion methods
On 5/12/22 01:17, Serge Semin wrote:
> 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 <Sergey.Semin@...kalelectronics.ru>
>
> ---
>
> Changelog v2:
> - Convert the ahci_platform_assert_rsts() method to returning int status
> (@Damien).
> - Fix some grammar mistakes in the ahci_platform_deassert_rsts() doc
> (@Damien).
> ---
> drivers/ata/ahci.h | 1 +
> drivers/ata/libahci_platform.c | 50 ++++++++++++++++++++++++++++++----
> include/linux/ahci_platform.h | 5 +++-
> 3 files changed, 50 insertions(+), 6 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@...e.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@...e.de +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
Powered by blists - more mailing lists