[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180110142505.GA3668920@devbig577.frc2.facebook.com>
Date: Wed, 10 Jan 2018 06:25:05 -0800
From: Tejun Heo <tj@...nel.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: bcm-kernel-feedback-list@...adcom.com,
Kishon Vijay Abraham I <kishon@...com>,
Heiko Stuebner <heiko@...ech.de>,
Srinath Mannam <srinath.mannam@...adcom.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Vivek Gautam <vivek.gautam@...eaurora.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
"open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)"
<linux-ide@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] ata: Allow having a port recovery callback
Hello,
On Tue, Jan 09, 2018 at 03:04:55PM -0800, Florian Fainelli wrote:
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 3c09122bf038..921c2813af07 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -2045,6 +2045,8 @@ int ata_dev_read_id(struct ata_device *dev, unsigned int *p_class,
> if (ata_msg_warn(ap))
> ata_dev_warn(dev, "failed to IDENTIFY (%s, err_mask=0x%x)\n",
> reason, err_mask);
> + if (ap->host->ops->port_recovery)
> + ap->host->ops->port_recovery(ap);
> return rc;
> }
This is a really weird spot to add a callback named port_recovery().
Can't the affected driver simply implement its own
ata_port_operations->read_id() operation which does the recovery if
necessary?
Thanks.
--
tejun
Powered by blists - more mailing lists