[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23a785fd-3874-b71a-c0f5-d117a9058abf@xilinx.com>
Date: Fri, 6 Mar 2020 15:55:46 -0800
From: Jolly Shah <jolly.shah@...inx.com>
To: "'Greg KH'" <gregkh@...uxfoundation.org>,
Jolly Shah <jolly.shah@...inx.com>
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,
> ------Original Message------
> From: 'Greg Kh' <gregkh@...uxfoundation.org>
> Sent: Friday, February 14, 2020 4:52PM
> To: Jolly Shah <jolly.shah@...inx.com>
> 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
>
> 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 :)
>
>>> 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.
Submitted v3 with required changes. Please review.
Thanks,
Jolly Shah
>
> thanks,
>
> greg k-h
>
Powered by blists - more mailing lists