From: "Henz, Patrick" <patrick.henz@hpe.com>
To: Laszlo Ersek <lersek@redhat.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"mike.maslenkin@gmail.com" <mike.maslenkin@gmail.com>
Cc: "hao.a.wu@intel.com" <hao.a.wu@intel.com>,
"ray.ni@intel.com" <ray.ni@intel.com>
Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks
Date: Thu, 2 Nov 2023 23:01:34 +0000 [thread overview]
Message-ID: <PH0PR84MB1478A5634F2DCDA763E4EE5E89A6A@PH0PR84MB1478.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <04b7b3de-8038-c9ac-36b7-2cbcbbd6d104@redhat.com>
Thank you, Laszlo. I'll make sure to do that moving forward!
Patrick Henz
-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Thursday, November 2, 2023 6:28 AM
To: devel@edk2.groups.io; mike.maslenkin@gmail.com; Henz, Patrick <patrick.henz@hpe.com>
Cc: hao.a.wu@intel.com; ray.ni@intel.com
Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks
On 11/1/23 02:12, Mike Maslenkin wrote:
> On Tue, Oct 31, 2023 at 7:52 PM Henz, Patrick <patrick.henz@hpe.com> wrote:
>>
>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4578
>>
>> The implementation of XhcGetElapsedTicks did not account for non-zero
>> start and stop values for the performance counter timer, potentially
>> resulting in an incorrect elapsed tick count getting returned to the
>> caller. Account for non-zero start and stop values when calculating
>> the elapsed tick count.
>>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Signed-off-by: Patrick Henz <patrick.henz@hpe.com>
>> Reviewed-by:
>> ---
>> MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
>> b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
>> index 7a2e32a9dd..6cb97b7452 100644
>> --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
>> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
>> @@ -2389,7 +2389,7 @@ XhcGetElapsedTicks (
>> // Counter counts upwards, check for an overflow condition
>> //
>> if (*PreviousTick > CurrentTick) {
>> - Delta = (mPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
>> + Delta = (CurrentTick - mPerformanceCounterStartValue) +
>> + (mPerformanceCounterEndValue - *PreviousTick);
>> } else {
>> Delta = CurrentTick - *PreviousTick;
>> }
>> @@ -2398,7 +2398,7 @@ XhcGetElapsedTicks (
>> // Counter counts downwards, check for an underflow condition
>> //
>> if (*PreviousTick < CurrentTick) {
>> - Delta = (mPerformanceCounterStartValue - CurrentTick) + *PreviousTick;
>> + Delta = (mPerformanceCounterStartValue - CurrentTick) +
>> + (*PreviousTick - mPerformanceCounterEndValue);
>> } else {
>> Delta = *PreviousTick - CurrentTick;
>> }
>> --
>> 2.34.1
>>
>>
>>
>> ------------
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#110434):
>> https://edk2.groups.io/g/devel/message/110434
>> Mute This Topic: https://groups.io/mt/102301510/1770412
>> Group Owner: devel+owner@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>> [mike.maslenkin@gmail.com]
>> ------------
>>
>>
> Hello, All
>
> Just curious why this patch was broken by google groups.
>
> Some patches to edk2 and edk2-redfish-client have unintended line
> breaks marked with "=", additional "0D" and additional "3D" to "="
> Web shows https://edk2.groups.io/g/devel/message/110434 exactly as it
> saved by mailer.
> What do sender should setup to avoid this?
I recommend selecting base64 content-transfer-encoding, rather than quode-printable. Base64 will ensure that the embedded CRLFs (which are used in the edk2 source tree) survive intact, and also that "git-am" can cleanly apply the patch (as saved from the mailing list).
Base64 is more robust than 8bit too. (If 8bit survived all mail servers along the way, it would work fine as well.)
... According to my notes, git has always *ignored* the
[sendemail]
transferEncoding = base64
stanza in my git config file. Which is why I have an alias around git-send-email that open-codes
git send-email --transfer-encoding=base64 ...
So that's what I recommend.
(BTW, our "BaseTools/Scripts/SetupGit.py" script sets "sendemail.transferEncoding=8bit", but that is problematic for two
reasons: (1) git ignores it anyway, per my records mentioned above, (2) 8bit is inferior to base64 in practice, when it comes to CRLF integrity across all email servers.)
... Side comment: I can apply quoted-printable-encoded patches as well, from the list, but that's only because I manually transcode them to 8bit, before passing them to git-am. I use the following hairy script:
----------------------------
#!/bin/bash
set -e -u -C
TMPD=$(mktemp -d)
trap 'rm -f -r -- "$TMPD"' EXIT
cd "$TMPD"
tee input | dos2unix | csplit -s - '/^$/'
HEAD_LINES=$(wc -l < xx00)
head -n "$HEAD_LINES" input \
| sed -r 's/^(Content-Transfer-Encoding: )quoted-printable/\18bit/'
tail -n +$((HEAD_LINES + 1)) input \
| perl -p -e 'use MIME::QuotedPrint; $_=MIME::QuotedPrint::decode($_);'
| \ unix2dos
----------------------------
(The perl command is from Paolo Bonzini.)
Summary: send your patches with
git send-email --transfer-encoding=base64 ...
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110575): https://edk2.groups.io/g/devel/message/110575
Mute This Topic: https://groups.io/mt/102301510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-11-02 23:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 16:51 [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks Henz, Patrick
2023-10-31 20:51 ` Laszlo Ersek
2023-11-01 1:12 ` Mike Maslenkin
2023-11-02 11:28 ` Laszlo Ersek
2023-11-02 13:06 ` Pedro Falcato
2023-11-03 6:40 ` Laszlo Ersek
2023-11-02 23:01 ` Henz, Patrick [this message]
2023-11-01 2:25 ` Wu, Hao A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH0PR84MB1478A5634F2DCDA763E4EE5E89A6A@PH0PR84MB1478.NAMPRD84.PROD.OUTLOOK.COM \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox