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: <20210324151035.GO2916463@dell>
Date:   Wed, 24 Mar 2021 15:10:35 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mfd: intel_quark_i2c_gpio: enable MSI interrupt

On Wed, 24 Mar 2021, Andy Shevchenko wrote:

> 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"

 "This driver only requires 1 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.
> 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog