Message ID | 20200107183022.26224-1-f.fainelli@gmail.com |
---|---|
Headers | show |
Series | ata: ahci_brcm: Follow-up changes for BCM7216 | expand |
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(-) >
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
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?
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?