Hi Jens, Philipp,
These three patches are a follow-up to my previous series titled: ata:
ahci_brcm: Fixes and new device support.
After submitting the BCM7216 RESCAL reset driver, Philipp the reset
controller maintained indicated that the reset line should be self
de-asserting and so reset_control_reset() should be used instead.
These three patches update the driver in that regard. It would be great if
you could apply those and get them queued up for 5.6 since they are
directly related to the previous series.
Changes in v3:
- introduced a preliminary patch making use of the proper reset control
API in order to manage the optional reset controller line
- updated patches after introducing that preliminary patch
Changes in v2:
- updated error path after moving the reset line control
Thanks!
Florian Fainelli (3):
ata: ahci_brcm: Correct reset control API usage
ata: ahci_brcm: Perform reset after obtaining resources
ata: ahci_brcm: BCM7216 reset is self de-asserting
drivers/ata/ahci_brcm.c | 42 +++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
--
2.17.1
Resources such as clocks, PHYs, regulators are likely to get a probe
deferral return code, which could lead to the AHCI controller being
reset a few times until it gets successfully probed. Since this is
typically the most time consuming operation, move it after the resources
have been acquired.
Signed-off-by: Florian Fainelli <[email protected]>
---
drivers/ata/ahci_brcm.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
index 718516fe6997..c229fea39a47 100644
--- a/drivers/ata/ahci_brcm.c
+++ b/drivers/ata/ahci_brcm.c
@@ -456,15 +456,9 @@ static int brcm_ahci_probe(struct platform_device *pdev)
if (IS_ERR(priv->rcdev))
return PTR_ERR(priv->rcdev);
- ret = reset_control_deassert(priv->rcdev);
- if (ret)
- return ret;
-
hpriv = ahci_platform_get_resources(pdev, 0);
- if (IS_ERR(hpriv)) {
- ret = PTR_ERR(hpriv);
- goto out_reset;
- }
+ if (IS_ERR(hpriv))
+ return PTR_ERR(hpriv);
hpriv->plat_data = priv;
hpriv->flags = AHCI_HFLAG_WAKE_BEFORE_STOP | AHCI_HFLAG_NO_WRITE_TO_RO;
@@ -481,6 +475,10 @@ static int brcm_ahci_probe(struct platform_device *pdev)
break;
}
+ ret = reset_control_deassert(priv->rcdev);
+ if (ret)
+ return ret;
+
ret = ahci_platform_enable_clks(hpriv);
if (ret)
goto out_reset;
--
2.17.1
The BCM7216 reset controller line is self-deasserting, unlike other
platforms, so make use of reset_control_reset() instead of
reset_control_deassert().
Signed-off-by: Florian Fainelli <[email protected]>
---
drivers/ata/ahci_brcm.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
index c229fea39a47..62c948e56beb 100644
--- a/drivers/ata/ahci_brcm.c
+++ b/drivers/ata/ahci_brcm.c
@@ -352,7 +352,10 @@ static int brcm_ahci_suspend(struct device *dev)
if (ret)
return ret;
- return reset_control_assert(priv->rcdev);
+ if (priv->version != BRCM_SATA_BCM7216)
+ ret = reset_control_assert(priv->rcdev);
+
+ return ret;
}
static int brcm_ahci_resume(struct device *dev)
@@ -362,7 +365,10 @@ static int brcm_ahci_resume(struct device *dev)
struct brcm_ahci_priv *priv = hpriv->plat_data;
int ret = 0;
- ret = reset_control_deassert(priv->rcdev);
+ if (priv->version == BRCM_SATA_BCM7216)
+ ret = reset_control_reset(priv->rcdev);
+ else
+ ret = reset_control_deassert(priv->rcdev);
if (ret)
return ret;
@@ -475,7 +481,10 @@ static int brcm_ahci_probe(struct platform_device *pdev)
break;
}
- ret = reset_control_deassert(priv->rcdev);
+ if (priv->version == BRCM_SATA_BCM7216)
+ ret = reset_control_reset(priv->rcdev);
+ else
+ ret = reset_control_deassert(priv->rcdev);
if (ret)
return ret;
@@ -520,7 +529,8 @@ static int brcm_ahci_probe(struct platform_device *pdev)
out_disable_clks:
ahci_platform_disable_clks(hpriv);
out_reset:
- reset_control_assert(priv->rcdev);
+ if (priv->version != BRCM_SATA_BCM7216)
+ reset_control_assert(priv->rcdev);
return ret;
}
--
2.17.1
Hi,
On 07-01-2020 19:30, Florian Fainelli wrote:
> Hi Jens, Philipp,
>
> These three patches are a follow-up to my previous series titled: ata:
> ahci_brcm: Fixes and new device support.
>
> After submitting the BCM7216 RESCAL reset driver, Philipp the reset
> controller maintained indicated that the reset line should be self
> de-asserting and so reset_control_reset() should be used instead.
>
> These three patches update the driver in that regard. It would be great if
> you could apply those and get them queued up for 5.6 since they are
> directly related to the previous series.
>
> Changes in v3:
> - introduced a preliminary patch making use of the proper reset control
> API in order to manage the optional reset controller line
> - updated patches after introducing that preliminary patch
>
> Changes in v2:
> - updated error path after moving the reset line control
Series looks good to me:
Reviewed-by: Hans de Goede <[email protected]>
Regards,
Hans
>
> Thanks!
>
> Florian Fainelli (3):
> ata: ahci_brcm: Correct reset control API usage
> ata: ahci_brcm: Perform reset after obtaining resources
> ata: ahci_brcm: BCM7216 reset is self de-asserting
>
> drivers/ata/ahci_brcm.c | 42 +++++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
Hi Florian,
On Tue, 2020-01-07 at 10:30 -0800, Florian Fainelli wrote:
> Hi Jens, Philipp,
>
> These three patches are a follow-up to my previous series titled: ata:
> ahci_brcm: Fixes and new device support.
>
> After submitting the BCM7216 RESCAL reset driver, Philipp the reset
> controller maintained indicated that the reset line should be self
> de-asserting and so reset_control_reset() should be used instead.
>
> These three patches update the driver in that regard. It would be great if
> you could apply those and get them queued up for 5.6 since they are
> directly related to the previous series.
>
> Changes in v3:
> - introduced a preliminary patch making use of the proper reset control
> API in order to manage the optional reset controller line
> - updated patches after introducing that preliminary patch
The third patch could be simplified by storing the rescal reset control
in a separate struct member and relying on the optional reset control
API more. This is just a suggestion though, the series looks fine as-is.
Reviewed-by: Philipp Zabel <[email protected]>
regards
Philipp
On 1/8/2020 1:25 AM, Philipp Zabel wrote:
> Hi Florian,
>
> On Tue, 2020-01-07 at 10:30 -0800, Florian Fainelli wrote:
>> Hi Jens, Philipp,
>>
>> These three patches are a follow-up to my previous series titled: ata:
>> ahci_brcm: Fixes and new device support.
>>
>> After submitting the BCM7216 RESCAL reset driver, Philipp the reset
>> controller maintained indicated that the reset line should be self
>> de-asserting and so reset_control_reset() should be used instead.
>>
>> These three patches update the driver in that regard. It would be great if
>> you could apply those and get them queued up for 5.6 since they are
>> directly related to the previous series.
>>
>> Changes in v3:
>> - introduced a preliminary patch making use of the proper reset control
>> API in order to manage the optional reset controller line
>> - updated patches after introducing that preliminary patch
>
> The third patch could be simplified by storing the rescal reset control
> in a separate struct member and relying on the optional reset control
> API more. This is just a suggestion though, the series looks fine as-is.
>
> Reviewed-by: Philipp Zabel <[email protected]>
Thanks! Jens is that good for you?
--
Florian
On 1/16/20 9:44 PM, Florian Fainelli wrote:
>
>
> On 1/8/2020 1:25 AM, Philipp Zabel wrote:
>> Hi Florian,
>>
>> On Tue, 2020-01-07 at 10:30 -0800, Florian Fainelli wrote:
>>> Hi Jens, Philipp,
>>>
>>> These three patches are a follow-up to my previous series titled: ata:
>>> ahci_brcm: Fixes and new device support.
>>>
>>> After submitting the BCM7216 RESCAL reset driver, Philipp the reset
>>> controller maintained indicated that the reset line should be self
>>> de-asserting and so reset_control_reset() should be used instead.
>>>
>>> These three patches update the driver in that regard. It would be great if
>>> you could apply those and get them queued up for 5.6 since they are
>>> directly related to the previous series.
>>>
>>> Changes in v3:
>>> - introduced a preliminary patch making use of the proper reset control
>>> API in order to manage the optional reset controller line
>>> - updated patches after introducing that preliminary patch
>>
>> The third patch could be simplified by storing the rescal reset control
>> in a separate struct member and relying on the optional reset control
>> API more. This is just a suggestion though, the series looks fine as-is.
>>
>> Reviewed-by: Philipp Zabel <[email protected]>
>
> Thanks! Jens is that good for you?
Can you re-send against the current branch and include the reviewed-bys
from here as well?
--
Jens Axboe