From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 300999419FA for ; Thu, 2 Nov 2023 13:07:02 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=vs2RwI9dlh8EnIbQU0vOAYMCzQkbQaLVy61rWxydAdQ=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698930420; v=1; b=KWpYDQblcQ2r/8pdkhrC7acoG86qkOtLnQZyzijQEKoqpeh0lbapLslZXCp4n/Hp7jOnxM/E nuzZ7luk3TSLDd+RAQfo4dx+mNH5vts6tCF3Tp/xLtwlaVT8NFVVaiqKddVyoRgyWBLP+jyf6ZL hQkFWIeXv/tgw5UZHFqSpE2M= X-Received: by 127.0.0.2 with SMTP id zPfJYY7687511xXXsJ3IR7YE; Thu, 02 Nov 2023 06:07:00 -0700 X-Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by mx.groups.io with SMTP id smtpd.web11.30168.1698930420246171162 for ; Thu, 02 Nov 2023 06:07:00 -0700 X-Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-7b747c9b067so328486241.3 for ; Thu, 02 Nov 2023 06:07:00 -0700 (PDT) X-Gm-Message-State: 8irxfUt8q9QorXTC1haUItSpx7686176AA= X-Google-Smtp-Source: AGHT+IGVA4Hns646P4UdoOZyG1axXZpsd/AuftAXY0L/uopWMoQoRWoOS0aV2J+jpsJjeDeUS36IiGD8qUg0zLRKf0w= X-Received: by 2002:a1f:a6d2:0:b0:49a:b737:4df7 with SMTP id p201-20020a1fa6d2000000b0049ab7374df7mr14165947vke.5.1698930418889; Thu, 02 Nov 2023 06:06:58 -0700 (PDT) MIME-Version: 1.0 References: <04b7b3de-8038-c9ac-36b7-2cbcbbd6d104@redhat.com> In-Reply-To: <04b7b3de-8038-c9ac-36b7-2cbcbbd6d104@redhat.com> From: "Pedro Falcato" Date: Thu, 2 Nov 2023 13:06:48 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks To: devel@edk2.groups.io, lersek@redhat.com Cc: mike.maslenkin@gmail.com, patrick.henz@hpe.com, hao.a.wu@intel.com, ray.ni@intel.com, Rebecca Cran Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,pedro.falcato@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=KWpYDQbl; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Thu, Nov 2, 2023 at 11:28=E2=80=AFAM Laszlo Ersek wr= ote: > > On 11/1/23 02:12, Mike Maslenkin wrote: > > On Tue, Oct 31, 2023 at 7:52=E2=80=AFPM Henz, Patrick wrote: > >> > >> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D4578 > >> > >> 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 > >> Cc: Ray Ni > >> Signed-off-by: Patrick Henz > >> 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/Pc= i/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 =3D (mPerformanceCounterEndValue - *PreviousTick) + Curre= ntTick; > >> + Delta =3D (CurrentTick - mPerformanceCounterStartValue) + (mPer= formanceCounterEndValue - *PreviousTick); > >> } else { > >> Delta =3D CurrentTick - *PreviousTick; > >> } > >> @@ -2398,7 +2398,7 @@ XhcGetElapsedTicks ( > >> // Counter counts downwards, check for an underflow condition > >> // > >> if (*PreviousTick < CurrentTick) { > >> - Delta =3D (mPerformanceCounterStartValue - CurrentTick) + *Prev= iousTick; > >> + Delta =3D (mPerformanceCounterStartValue - CurrentTick) + (*Pre= viousTick - mPerformanceCounterEndValue); > >> } else { > >> Delta =3D *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/11= 0434 > >> 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@gmai= l.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 "=3D", additional "0D" and additional "3D" to "=3D" > > 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 =3D 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=3Dbase64 ... > > So that's what I recommend. > > (BTW, our "BaseTools/Scripts/SetupGit.py" script sets > "sendemail.transferEncoding=3D8bit", 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=3D$(mktemp -d) > trap 'rm -f -r -- "$TMPD"' EXIT > > cd "$TMPD" > tee input | dos2unix | csplit -s - '/^$/' > HEAD_LINES=3D$(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; $_=3DMIME::QuotedPrint::decode($_);'= \ > | unix2dos > ---------------------------- > > (The perl command is from Paolo Bonzini.) Ooooooh, cool script! > > Summary: send your patches with > > git send-email --transfer-encoding=3Dbase64 ... I've been involved in EDK2 for the last 2.5 years and I still haven't found a consistent way to both send and apply patches :/ I usually use 8bit. FWIW, Rebecca started hosting a lore instance (https://openfw.io/edk2-devel/, although it doesn't seem to be feeling too well atm) and I tried to get b4 to work, to see if most of this process could be nicely automated. Sadly, CRLF problems galore :( --=20 Pedro -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110526): https://edk2.groups.io/g/devel/message/110526 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] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-