[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YFsv6DijMMiv3D10@smile.fi.intel.com>
Date: Wed, 24 Mar 2021 14:26:16 +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 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_.
> It's usual for values (other than things like timings) to be issued
> 'raw' like this. Particularly as an argument of a bespoke API.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists