mbox series

[v3,0/3] ata: ahci_brcm: Follow-up changes for BCM7216

Message ID 20200107183022.26224-1-f.fainelli@gmail.com
Headers show
Series ata: ahci_brcm: Follow-up changes for BCM7216 | expand

Message

Florian Fainelli Jan. 7, 2020, 6:30 p.m. UTC
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(-)

Comments

Hans de Goede Jan. 7, 2020, 6:47 p.m. UTC | #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 <hdegoede@redhat.com>

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(-)
>
Philipp Zabel Jan. 8, 2020, 9:25 a.m. UTC | #2
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 <p.zabel@pengutronix.de>

regards
Philipp
Florian Fainelli Jan. 17, 2020, 4:44 a.m. UTC | #3
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 <p.zabel@pengutronix.de>

Thanks! Jens is that good for you?
Jens Axboe Jan. 17, 2020, 4:51 a.m. UTC | #4
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 <p.zabel@pengutronix.de>
> 
> Thanks! Jens is that good for you?

Can you re-send against the current branch and include the reviewed-bys
from here as well?