| 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
| ||
|
Message-ID: <3ca6fb9e-94cf-6483-26a6-ae2682d1f55e@synopsys.com>
Date: Tue, 25 Jan 2022 02:11:23 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Sean Anderson <sean.anderson@...o.com>,
Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
CC: Felipe Balbi <balbi@...nel.org>,
Balaji Prakash J <bjagadee@...eaurora.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Robert Hancock <robert.hancock@...ian.com>,
Baruch Siach <baruch@...s.co.il>
Subject: Re: [PATCH v2 4/7] usb: dwc3: Program GFLADJ
Sean Anderson wrote:
>
>
> On 1/24/22 5:46 PM, Thinh Nguyen wrote:
>> Sean Anderson wrote:
>>> GUCTL.REFCLKPER can only account for clock frequencies with integer
>>> periods. To address this, program REFCLK_FLADJ with the relative error
>>> caused by period truncation. The formula given in the register reference
>>> has been rearranged to allow calculation based on rate (instead of
>>> period), and to allow for fixed-point arithmetic.
>>>
>>> Additionally, calculate a value for 240MHZDECR. This configures a
>>> simulated 240Mhz clock using a counter with one fractional bit (PLS1).
>>>
>>> This register is programmed only for versions >= 2.50a, since this is
>>> the check also used by commit db2be4e9e30c ("usb: dwc3: Add frame length
>>> adjustment quirk").
>>>
>>> Signed-off-by: Sean Anderson <sean.anderson@...o.com>
>>> ---
>>>
>>> Changes in v2:
>>> - Also program GFLADJ.240MHZDECR
>>> - Don't program GFLADJ if the version is < 2.50a
>>>
>>> drivers/usb/dwc3/core.c | 37 +++++++++++++++++++++++++++++++++++--
>>> drivers/usb/dwc3/core.h | 3 +++
>>> 2 files changed, 38 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 5214daceda86..883e119377f0 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -348,7 +348,7 @@ static void dwc3_frame_length_adjustment(struct dwc3 *dwc)
>>> static void dwc3_ref_clk_period(struct dwc3 *dwc)
>>> {
>>> u32 reg;
>>> - unsigned long rate, period;
>>> + unsigned long decr, fladj, rate, period;
>>
>> Minor style nit: Felipe prefers to keep the declaration on separate
>> lines, let's keep it consistent with the rest in this driver.
>
> So
>
> unsigned int decr;
> unsigned int fladj;
> unsigned int rate;
> unsigned int period;
>
> ?
>
> Frankly that seems rather verbose.
A couple of the benefits of having it like this is to help with viewing
git-blame if we introduce new variables and help with backporting fix
patch a bit simpler. Mainly I'm just following Felipe's style and keep
it consistent in this driver, but I don't think it's a big deal.
>
>>>
>>> if (dwc->ref_clk) {
>>> rate = clk_get_rate(dwc->ref_clk);
>>> @@ -357,6 +357,7 @@ static void dwc3_ref_clk_period(struct dwc3 *dwc)
>>> period = NSEC_PER_SEC / rate;
>>> } else if (dwc->ref_clk_per) {
>>> period = dwc->ref_clk_per;
>>> + rate = NSEC_PER_SEC / period;
>>> } else {
>>> return;
>>> }
>>> @@ -365,9 +366,41 @@ static void dwc3_ref_clk_period(struct dwc3 *dwc)
>>> reg &= ~DWC3_GUCTL_REFCLKPER_MASK;
>>> reg |= FIELD_PREP(DWC3_GUCTL_REFCLKPER_MASK, period);
>>> dwc3_writel(dwc->regs, DWC3_GUCTL, reg);
>>> +
>>> + if (DWC3_VER_IS_PRIOR(DWC3, 250A))
>>> + return;
>>> +
>>> + /*
>>> + * The calculation below is
>>> + *
>>> + * 125000 * (NSEC_PER_SEC / (rate * period) - 1)
>>> + *
>>> + * but rearranged for fixed-point arithmetic.
>>> + *
>>> + * Note that rate * period ~= NSEC_PER_SECOND, minus the number of
>>> + * nanoseconds of error caused by the truncation which happened during
>>> + * the division when calculating rate or period (whichever one was
>>> + * derived from the other). We first calculate the relative error, then
>>> + * scale it to units of 0.08%.
>>> + */
>>> + fladj = div64_u64(125000ULL * NSEC_PER_SEC, (u64)rate * period);
>>
>> Can we rearrange the math so we don't have to operate on different data
>> type and deal with conversion/truncation?
>
> I don't understand what data types you are referring to.
>
> The truncation above (in the calculaion for rate/period) is intentional,
> so we can determine the error introduced by representing period using
> only ns.
I was wondering if we rearrange the math so we don't need to cast and
use 64-bit here, but that may not be possible. Just computing/reviewing
in my head while accounting for truncation from 64-bit to 32-bit value
is taxing.
>
>>> + fladj -= 125000;
>>> +
>>> + /*
>>> + * The documented 240MHz constant is scaled by 2 to get PLS1 as well.
>>> + */
>>> + decr = 480000000 / rate;
>>> +
>>> + reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
>>> + reg &= ~DWC3_GFLADJ_REFCLK_FLADJ_MASK
>>> + & ~DWC3_GFLADJ_240MHZDECR
>>> + & ~DWC3_GFLADJ_240MHZDECR_PLS1;
>>> + reg |= FIELD_PREP(DWC3_GFLADJ_REFCLK_FLADJ_MASK, fladj)
>>> + | FIELD_PREP(DWC3_GFLADJ_240MHZDECR, decr >> 1)
>>> + | FIELD_PREP(DWC3_GFLADJ_240MHZDECR_PLS1, decr & 1);
>>
>> Does this pass checkpatch?
>
> Yes.
>
> --Sean
>
>>> + dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
>>> }
>>>
>>> -
>>> /**
>>> * dwc3_free_one_event_buffer - Frees one event buffer
>>> * @dwc: Pointer to our controller context structure
>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>> index 45cfa7d9f27a..eb9c1efced05 100644
>>> --- a/drivers/usb/dwc3/core.h
>>> +++ b/drivers/usb/dwc3/core.h
>>> @@ -388,6 +388,9 @@
>>> /* Global Frame Length Adjustment Register */
>>> #define DWC3_GFLADJ_30MHZ_SDBND_SEL BIT(7)
>>> #define DWC3_GFLADJ_30MHZ_MASK 0x3f
>>> +#define DWC3_GFLADJ_REFCLK_FLADJ_MASK GENMASK(21, 8)
>>> +#define DWC3_GFLADJ_240MHZDECR GENMASK(30, 24)
>>> +#define DWC3_GFLADJ_240MHZDECR_PLS1 BIT(31)
>>>
>>> /* Global User Control Register*/
>>> #define DWC3_GUCTL_REFCLKPER_MASK 0xffc00000
Thanks,
Thinh
Powered by blists - more mailing lists