linux-kernel - Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0CEC3CE6-E1B4-4E53-A8A7-3FBF86E76E90@xilinx.com>
Date:   Wed, 19 Feb 2020 22:50:08 +0000
From:   Jolly Shah <JOLLYS@...inx.com>
To:     'Greg KH' <gregkh@...uxfoundation.org>
CC:     Rajan Vaja <RAJANV@...inx.com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "matt@...eblueprint.co.uk" <matt@...eblueprint.co.uk>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>,
        Michal Simek <michals@...inx.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] firmware: xilinx: Add sysfs interface

Hi Greg,

On 2/14/20, 4:58 PM, "linux-kernel-owner@...r.kernel.org on behalf of 'Greg KH'" <linux-kernel-owner@...r.kernel.org on behalf of gregkh@...uxfoundation.org> wrote:

    On Fri, Feb 14, 2020 at 04:37:16PM -0800, Jolly Shah wrote:
    > > Just make the direct call to the firmware driver, no need to muck around
    > > with tables of function pointers.  In fact, with the spectre changes,
    > > you just made things slower than needed, and you can get back a bunch of
    > > throughput by removing that whole middle layer.
    > > 
    > 
    > arm,scpi is doing the same way and we thought this approach will be more
    > acceptable than direct function calls but happy to change as suggested.
    
    Just because one random tiny thing does it the wrong way does not mean
    to focus on that design pattern and ignore the thousands of other
    apis/interfaces in the kernel that do not do it that way :)
    
Sure. Will change in next version.

    > > So go do that first please, before adding any new stuff.
    > > 
    > > Now for the ioctl, yeah, that's not a "normal" pattern either.  But
    > > right now you only have 2 "different" ioctls that you call.  So why not
    > > just turn those 2 into real function calls as well that then makes the
    > > "ioctl" call to the hardware?  That makes things a lot more obvious on
    > > the kernel driver side exactly what is going on.
    > > 
    > 
    > Sure as i understand firmware driver will provide real function calls to be
    > used by user drivers and underneath it will call ioctl for desired
    > operation. Please correct if I misunderstood.
    
    You do not misunderstand.

Thanks for confirmation.

Thanks,
Jolly Shah
    
    thanks,
    
    greg k-h