linux-kernel - Re: [PATCH v2 2/2] mfd: intel_quark_i2c

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: <YFtKo4IrOGWoX6O3@smile.fi.intel.com>
Date:   Wed, 24 Mar 2021 16:20:19 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mfd: intel_quark_i2c_gpio: enable MSI interrupt

On Wed, Mar 24, 2021 at 01:07:23PM +0000, Lee Jones wrote:
> On Wed, 24 Mar 2021, Andy Shevchenko wrote:
> 
> > On Wed, Mar 24, 2021 at 11:50:33AM +0000, Lee Jones wrote:
> > > On Wed, 24 Mar 2021, Andy Shevchenko wrote:
> > > 
> > > > On Wed, Mar 24, 2021 at 10:47:29AM +0000, Lee Jones wrote:
> > > > > On Wed, 24 Mar 2021, Andy Shevchenko wrote:
> > > > > > On Wed, Mar 24, 2021 at 10:29:31AM +0000, Lee Jones wrote:
> > > > > > > On Tue, 23 Mar 2021, Andy Shevchenko wrote:
> > > > 
> > > > ...
> > > > 
> > > > > Also, past acceptance does not guarantee ideal/correct usage.
> > > > 
> > > > In this case it's hardly can be misused. But I heard you.
> > > > 
> > > > ...
> > > > 
> > > > > > The semantic is min-max range and having two defines (*) here for these seems
> > > > > > to me as an utter overkill.
> > > > > > 
> > > > > > Of course, if you insist I may do it.
> > > > > > 
> > > > > > *) since value is the same, we might have one definition, but it will be even
> > > > > >    more confusion to have it as a min and max at the same time.
> > > > > 
> > > > > It's just tricky to decypher for people who do not know the API, which
> > > > > is most people, myself included.  For APIs like usleep_range() et al.,
> > > > > obviously this makes no sense at all.
> > > > 
> > > > Seem like you are insisting. Okay, I will define them. What do you prefer one
> > > > or two definitions?
> > > 
> > > Actually I'm not.  I'm just trying to get my head around where the
> > > data comes from and what the values actually mean.
> > > 
> > > > ...
> > > > 
> > > > > What defines a vector?
> > > > 
> > > > The combination is solely of the driver-hardware. Driver explicitly tells that
> > > > how many vectors it may consume (taking into account the range asked) and API
> > > > returns amount given or an error.
> > > 
> > > So, where does the information actually come from?
> > > 
> > > Information that comes from a datasheet is usually defined.
> > > 
> > > Information that comes from the F/W is usually read and popped into a
> > > variable.
> > 
> > It's a two way road:
> > a) driver states that it needs only 1 vector and it's enough to it
> > b) hardware must provide at least 1 vector to be served by this driver.
> > 
> > Look again into grepped output. Most of drivers that define it as an variable
> > may dynamically adapt to the different amount of IRQ vectors. When it's static,
> > usually drivers just hard code those values.
> > 
> > I'm really don't see a point to define them _in this driver_.
> 
> That's fine.  I just felt like I had to ask.
> 
> Would you consider a comment that lets people unfamiliar with the API
> what the values mean?
> 
> Something to the tune of:
> 
>   "This driver requests 1 (and only 1) IRQ vector"


Rather

    "This driver requests only 1 (and it's enough) IRQ vector"

or something like this.

Should I send a patch with the comment included? If so, please suggest if it's
good from English grammar/style perspective.

-- 
With Best Regards,
Andy Shevchenko