netdev - Re: [PATCH] sfp: sfp_read: split-up request when hw rx buffer is too small.

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:   Fri, 25 Jan 2019 23:43:17 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     René van Dorst <opensource@...rst.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] sfp: sfp_read: split-up request when hw rx buffer is too
 small.

> My point still stands, we have an abstraction layer through the i2c core
> which sits between clients and adapters.
> 
> If you have a simple read into a buffer transaction (like what we have
> here), then you can provide a safe accessor function that takes care of
> looking at the max_read_len quirk and splitting things into the
> appropriate number of transaction. Then we can also eliminate the "msg
> too long" annoying message since we are now using an appropriate function.
> 
> The fact that there are multiple drivers that need to be patched to
> split i2c transaction is an indication that this is not IMHO addressed
> at the right level, especially if what they do is as simple as an
> i2c_transfer() into a single buffer and require no quirky transaction.
> 
> Andrew, Heiner and Russell might have a different view on this.

Hi Florian

I suspect the issue is, only the driver knows if the device supports
splitting a read into multiple reads without having to do something in
between. Some device might require you do an address setup between
each read, for example.

However, the core could offer an i2c_transfer_segmentable(), which
does the segmentation as required here, and the driver can then elect
to use that, not i2c_transfer().

   Andrew