[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZvVq_sBK3T5wHZd4@smile.fi.intel.com>
Date: Thu, 26 Sep 2024 17:09:02 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Michael Wu <Michael.Wu@...ron.us>,
Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Jan Dabros <jsd@...ihalf.com>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
Andi Shyti <andi.shyti@...nel.org>,
morgan chang <morgan.chang@...ron.us>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] i2c: designware: determine HS tHIGH and tLOW based
on HW paramters
On Thu, Sep 26, 2024 at 03:50:07PM +0200, Krzysztof Kozlowski wrote:
> On 26/09/2024 14:18, Andy Shevchenko wrote:
> > On Thu, Sep 26, 2024 at 08:45:47AM +0000, Michael Wu wrote:
> >>> On Wed, Sep 25, 2024 at 12:16:10PM +0300, Andy Shevchenko wrote:
> >>>> On Wed, Sep 25, 2024 at 04:04:30PM +0800, Michael Wu wrote:
...
> >>>>> + * @bus_loading: for high speed mode, the bus loading affects the high
> >>> and low
> >>>>> + * pulse width of SCL
> >>>>
> >>>> This is bad naming, better is bus_capacitance.
> >>>
> >>> Even more specific bus_capacitance_pf as we usually add physical units to the
> >>> variable names, so we immediately understand from the code the order of
> >>> numbers and their physical meanings.
> >>
> >> Sounds good. However, I think the length of "bus_capacitance_pf" is a bit
> >> long, we may often encounter the limit of more than 80 characters in a
> >> line when coding. I'll rename it to "bus_cap_pf".
> >
> > Limit had been relaxed to 100. I still think we may use temporary variables,
>
> Just to be clear, because you encourage reformatting it to 100:
>
> You mix coding style with checkpatch. Checkpatch does not define coding
> style. Coding style doc defines it. Limit is 80, unless growing to 100
> improves readability.
Somebody can still use land line rotary phones, while others are
on mobile ones, indeed. :-)
Jokes aside, the second part of my remark was in regard to how to make
the lines shorter in case somebody is so picky about 80 limit.
> > if needed, in order to make code neater. That said, I slightly prefer
> > bus_capacitance_pf over the shortened variant.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists