netdev - Re: [patch net-next 0/9] mlxsw: Support firmware flash

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]

Date:   Wed, 31 May 2017 14:18:44 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     gerlitz.or@...il.com
Cc:     yotamg@...lanox.com, Yuval.Mintz@...ium.com, jiri@...nulli.us,
        netdev@...r.kernel.org, idosch@...lanox.com, mlxsw@...lanox.com,
        bhutchings@...arflare.com
Subject: Re: [patch net-next 0/9] mlxsw: Support firmware flash

From: Or Gerlitz <gerlitz.or@...il.com>
Date: Tue, 30 May 2017 23:32:22 +0300

> On Sun, May 28, 2017 at 10:26 AM, Yotam Gigi <yotamg@...lanox.com> wrote:
>> On 05/23/2017 06:38 PM, David Miller wrote:
>>> From: Yotam Gigi <yotamg@...lanox.com>
>>> Date: Tue, 23 May 2017 18:14:15 +0300
> 
>>>> Sorry, I am not sure I understand. You think that drivers should not implement
>>>> ethtool's flash_device callback anymore? do you have an alternative for
>>>> firmware flash?
> 
>>> As stated, export an MTD device.
> 
>> So, after we have been going over MTD, it seems like it does not fit our needs
>> at all.
> 
>> MTD device provides (erasable-)block access to a flash storage, where in our
>> case the firmware burn process is just pouring a binary BLOB into the device.
>> The driver is not aware of the internal storage used for storing the firmware as
>> it is not defined in our driver-hardware API.
>>
>> Needless to say that block access has no meaning in our case, so any solution
>> that will involve MTD device to burn our firmware (if there is a solution at
>> all) will be a workaround and will not fit MTD purpose.
>>
>> Apart for boot time firmware flash, which we have already pushed we would really
>> like to allow the user to ask for a specific firmware version. Do you have any
>> other solution for us apart from "ethtool -f"?
>>
>> This problem is even more relevant in the Mellanox HCA driver team, which would
>> like to use that code in order to burn the HCA firmware, but not intend to
>> trigger it on boot time, which means that must have a way for the user to
>> trigger it.
> 
> 
> Hi Dave,
> 
> We had few more emails on this thread with Jakub, and he's now happy
> with our replies, so where do we go from here? could you comment on
> Yotam's note.

Ok, use ethtool -f if you must.