linux-kernel - Re: [PATCH v10 3/4] fpga: dfl: add basic support for DFHv1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Jan 2023 12:21:35 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     matthew.gerlach@...ux.intel.com
Cc:     hao.wu@...el.com, yilun.xu@...el.com, russell.h.weight@...el.com,
        basheer.ahmed.muddebihal@...el.com, trix@...hat.com,
        mdf@...nel.org, linux-fpga@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        tianfei.zhang@...el.com, corbet@....net,
        gregkh@...uxfoundation.org, linux-serial@...r.kernel.org,
        jirislaby@...nel.org, geert+renesas@...der.be,
        niklas.soderlund+renesas@...natech.se, macro@...am.me.uk,
        johan@...nel.org, lukas@...ner.de, ilpo.jarvinen@...ux.intel.com,
        marpagan@...hat.com, bagasdotme@...il.com
Subject: Re: [PATCH v10 3/4] fpga: dfl: add basic support for DFHv1

On Mon, Jan 09, 2023 at 04:30:28PM -0800, matthew.gerlach@...ux.intel.com wrote:
> From: Matthew Gerlach <matthew.gerlach@...ux.intel.com>
> 
> Version 1 of the Device Feature Header (DFH) definition adds
> functionality to the Device Feature List (DFL) bus.
> 
> A DFHv1 header may have one or more parameter blocks that
> further describes the HW to SW. Add support to the DFL bus
> to parse the MSI-X parameter.
> 
> The location of a feature's register set is explicitly
> described in DFHv1 and can be relative to the base of the DFHv1
> or an absolute address. Parse the location and pass the information
> to DFL driver.

...

> v10: change dfh_find_param to return size of parameter data in bytes

The problem that might occur with this approach is byte ordering.
When we have u64 items, we know that they all are placed in CPU
ordering by the bottom layer. What's the contract now? Can it be
a problematic? Please double check this (always keep in mind BE32
as most interesting case for u64/unsigned long representation and
other possible byte ordering outcomes).

-- 
With Best Regards,
Andy Shevchenko