lkml.org 
[lkml]   [2017]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v9 1/5] firmware: add extensible driver data params
    On Mon, Jun 19, 2017 at 05:51:08PM -0500, Li, Yi wrote:
    > Hi Greg,
    >
    > On 6/17/2017 2:38 PM, Greg KH wrote:
    > >On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
    > >>On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
    > >>>On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
    > >
    > >>What you have to ask yourself really is if this makes it *less complex* and
    > >>helps *clean things up* in a much better way than it was before. Also does it
    > >>allow us to *pave the way for new functionality easily*, without creating
    > >>further mess?
    > >
    > >I agree, that's what I'm saying here. I just do not see that happening
    > >with your patch set at all. It's adding more code, a more complex way
    > >to interact with the subsystem, and not making driver writer lives any
    > >easier at all that I can see.
    > >
    > >Again, the code is now bigger, does more, with not even any real benefit
    > >for existing users.
    >
    > I am still new to the upstreaming world, pardon me if my understanding is
    > naive. :) My take with Luis's driver data API is that it adds a wrapper on
    > top of the old request_firmware APIs, so the new features can be
    > added/disabled by the parameters structures instead of adding/changing API
    > functions. Agree that there is not much new for existing users. It adds more
    > codes (not necessary more complex) but create a consistent way for extension
    > IMO.

    Most of code of my feature, firmware signing, is implemented in common
    place between old and new APIs, while only new API has a parameter,
    DRIVER_DATA_REQ_NO_SIG_CHECK, which allow users to enable/disable
    this feature per-driver-datum. Simple enough.

    So what matters is adding yet another variant of request_firmware_xx()
    vs. adding a mere parameter?

    Thanks,
    -Takahiro AKASHI

    > Below are 3 examples I tried to add streaming support to load large firmware
    > files.
    > Adding streaming with driver data API:
    > https://patchwork.kernel.org/patch/9738503 . This patch series depends on
    > non-cache patch series https://patchwork.kernel.org/patch/9793825 , which is
    > bigger than it should be since it added some codes to test firmware caching.
    > and pre-allocate buffer patch series
    > https://patchwork.kernel.org/patch/9738487/
    >
    > By comparison, here is my old streaming RFC with original firmware class:
    > https://lkml.org/lkml/2017/3/9/872
    > Do you think this is the better way?
    >
    > Thanks,
    > Yi

    \
     
     \ /
      Last update: 2017-06-20 03:49    [W:5.410 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site