| Message ID | 20220922133800.12918-1-rui.zhang@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/topology: Improve CPUID.1F handling | expand |
> Changes since V2: > - changelog improvements based on Peter' feedback > - Remove combined tags I fixed those up and started testing your v2 yesterday. Can you double-check that this: https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpuid1f Looks the same as your v3?
Hi, Dave, On Thu, 2022-09-22 at 09:53 -0700, Dave Hansen wrote: > > Changes since V2: > > - changelog improvements based on Peter' feedback > > - Remove combined tags > > I fixed those up and started testing your v2 yesterday. Thanks for doing this. > Can you > double-check that this: > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpuid1f > > Looks the same as your v3? There is no code difference. Just that I have updated the subject and changelog of patch 1/8 per Peter' suggestion https://lore.kernel.org/lkml/8496afee057d63b83a7ff02ec7f1de8c2d0e97ae.camel@intel.com/ thanks, rui
This series of BUG FIXES needs to be marked for -stable. What testing is it waiting for? I don't see upstream, in linux-next or in tip -- which means that nobody is testing it. Are we supposed to be pulling from the URL below to get the latest??? The latest Intel Hybrid CPUs are sort of a mess without this series. Distros will need to back-port it. thanks, -Len On Fri, Sep 23, 2022 at 10:40 AM Zhang Rui <rui.zhang@intel.com> wrote: > > Hi, Dave, > > On Thu, 2022-09-22 at 09:53 -0700, Dave Hansen wrote: > > > Changes since V2: > > > - changelog improvements based on Peter' feedback > > > - Remove combined tags > > > > I fixed those up and started testing your v2 yesterday. > > Thanks for doing this. > > > Can you > > double-check that this: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpuid1f > > > > Looks the same as your v3? > > There is no code difference. > Just that I have updated the subject and changelog of patch 1/8 per > Peter' suggestion > https://lore.kernel.org/lkml/8496afee057d63b83a7ff02ec7f1de8c2d0e97ae.camel@intel.com/ > > thanks, > rui >
On 10/13/22 03:58, Len Brown wrote:
> This series of BUG FIXES needs to be marked for -stable.
Hi Len,
That would have been great feedback to include with your review when
your provided your acks. It's also not clear where the bug fixes stop
and the "related fixes" begin. Is the entire series bug fixes that need
to be marked for -stable?
Hi, Dave, On Thu, 2022-10-13 at 08:56 -0700, Dave Hansen wrote: > On 10/13/22 03:58, Len Brown wrote: > > This series of BUG FIXES needs to be marked for -stable. > > Hi Len, > > That would have been great feedback to include with your review when > your provided your acks. It's also not clear where the bug fixes > stop > and the "related fixes" begin. Is the entire series bug fixes that > need > to be marked for -stable? Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and 3/8 to avoid possible regressions. So patch 2/8 ~ 5/8 should be stable material. patch 6/8 is also a bugfix, but we have not observed any functionality issues so far. thanks, rui
On 10/13/22 19:06, Zhang Rui wrote: > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and 3/8 to > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > material. > > patch 6/8 is also a bugfix, but we have not observed any functionality > issues so far. If you want to make this really easy on me, you could take the changelog and comment revisions that I made in that testing branch that I shared, integrate them, and send it out again, and *only* include the bugfixes.
On Thu, 2022-10-13 at 20:19 -0700, Dave Hansen wrote: > On 10/13/22 19:06, Zhang Rui wrote: > > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and > > 3/8 to > > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > > material. > > > > patch 6/8 is also a bugfix, but we have not observed any > > functionality > > issues so far. > > If you want to make this really easy on me, you could take the > changelog > and comment revisions that I made in that testing branch that I > shared, > integrate them, and send it out again, and *only* include the > bugfixes. Sure, will do this and resend. thanks, rui
On Thu, Oct 13, 2022 at 08:19:03PM -0700, Dave Hansen wrote: > On 10/13/22 19:06, Zhang Rui wrote: > > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and 3/8 to > > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > > material. > > > > patch 6/8 is also a bugfix, but we have not observed any functionality > > issues so far. > > If you want to make this really easy on me, you could take the changelog > and comment revisions that I made in that testing branch that I shared, > integrate them, and send it out again, and *only* include the bugfixes. It's really simple; if it don't have a Fixes tag, it ain't a fix :-)
On Fri, 2022-10-14 at 10:17 +0200, Peter Zijlstra wrote: > On Thu, Oct 13, 2022 at 08:19:03PM -0700, Dave Hansen wrote: > > On 10/13/22 19:06, Zhang Rui wrote: > > > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and > > > 3/8 to > > > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > > > material. > > > > > > patch 6/8 is also a bugfix, but we have not observed any > > > functionality > > > issues so far. > > > > If you want to make this really easy on me, you could take the > > changelog > > and comment revisions that I made in that testing branch that I > > shared, > > integrate them, and send it out again, and *only* include the > > bugfixes. > > It's really simple; if it don't have a Fixes tag, it ain't a fix :-) Thanks for pointing this out. Patches updated with Fixes tag in V4 series. thanks, rui