lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2e1642d9-825a-317e-8f35-884b8c341a64@gmail.com>
Date:   Wed, 10 Jan 2018 09:53:10 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Tejun Heo <tj@...nel.org>
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

On 01/10/2018 06:25 AM, Tejun Heo wrote:
> 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?

I did not consider that, but this is actually a great idea, thanks for
the suggestion! I will respin with that being done.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ