Changes since v8:
 * Added check for closid_init() on monitor only platforms.
 * Moved end-marker into array and added default cases.
 * Additional patches to move prototpyes between header files.
 
Changes otherwise noted on each patch.

---

Patches 20-26 should be squashed together when merged, taking the commit message
of patch 21. They are posted like this to allow folk to re-generate patch 21, then
review the differences on top. Not squashing them together would expose a ftrace
build warning during bisect. (but who does that!)
That would look like this:
git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9_final

This series is based on rc3, and can be retrieved from:
git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9

This series renames functions and moves code around. With the
exception of invalid configurations for the configurable-events, there should
be no changes in behaviour caused by this series. It is now possible for
throttle_mode to report 'undefined', but no known platform will do this.

The driving pattern is to make things like struct rdtgroup private to resctrl.
Features like pseudo-lock aren't going to work on arm64, the ability to disable
it at compile time is added.

After this, I can start posting the MPAM driver to make use of resctrl on arm64.
(What's MPAM? See the cover letter of the first series. [1])

As ever - bugs welcome,
Thanks,

James

[v8] https://lore.kernel.org/all/20250411164229.23413-1-james.morse@arm.com
[v7] https://lore.kernel.org/all/20250228195913.24895-1-james.morse@arm.com/
[v6] https://lore.kernel.org/lkml/20250207181823.6378-1-james.morse@arm.com/
[v5] https://lore.kernel.org/r/20241004180347.19985-1-james.morse@arm.com
[v4] https://lore.kernel.org/all/20240802172853.22529-1-james.morse@arm.com/
[v3] https://lore.kernel.org/r/20240614150033.10454-1-james.morse@arm.com
[v2] https://lore.kernel.org/r/20240426150537.8094-1-Dave.Martin@arm.com
[v1] https://lore.kernel.org/r/20240321165106.31602-1-james.morse@arm.com
[1] https://lore.kernel.org/lkml/20201030161120.227225-1-james.morse@arm.com/



Amit Singh Tomar (1):
  x86/resctrl: Remove the limit on the number of CLOSID

Dave Martin (3):
  x86/resctrl: Squelch whitespace anomalies in resctrl core code
  x86/resctrl: Prefer alloc(sizeof(*foo)) idiom in rdt_init_fs_context()
  x86/resctrl: Relax some asm #includes

James Morse (23):
  x86/resctrl: Rename resctrl_sched_in() to begin with "resctrl_arch_"
  x86/resctrl: Check all domains are offline in resctrl_exit()
  x86/resctrl: resctrl_exit() teardown resctrl but leave the mount point
  x86/resctrl: Drop __init/__exit on assorted symbols
  x86/resctrl: Move is_mba_sc() out of core.c
  x86/resctrl: Add end-marker to the resctrl_event_id enum
  x86/resctrl: Expand the width of domid by replacing mon_data_bits
  x86/resctrl: Split trace.h
  x86/resctrl: Add 'resctrl' to the title of the resctrl documentation
  fs/resctrl: Add boiler plate for external resctrl code
  x86/resctrl: Move the filesystem bits to headers visible to fs/resctrl
  x86/resctrl: Move enum resctrl_event_id to resctrl.h
  x86/resctrl: Fix types in resctrl_arch_mon_ctx_alloc() and free stubs
  x86/resctrl: Move pseudo lock prototypes to include/linux/resctrl.h
  x86/resctrl: Always initialise rid field in rdt_resources_all[]
  x86/resctrl: Remove a newline to avoid confusing the code move script
  x86/resctrl: Add python script to move resctrl code to /fs/resctrl
  x86,fs/resctrl: Move the resctrl filesystem code to live in
    /fs/resctrl
  x86,fs/resctrl: Remove duplicated trace header files
  fs/resctrl: Remove unnecessary includes
  fs/resctrl: Change internal.h's header guard macros
  x86,fs/resctrl: Move resctrl.rst to live under
    Documentation/filesystems
  MAINTAINERS: Add reviewers for fs/resctrl

 Documentation/arch/x86/index.rst              |    1 -
 Documentation/filesystems/index.rst           |    1 +
 .../{arch/x86 => filesystems}/resctrl.rst     |    6 +-
 MAINTAINERS                                   |    5 +-
 arch/Kconfig                                  |    8 +
 arch/x86/Kconfig                              |   11 +-
 arch/x86/include/asm/resctrl.h                |   15 +-
 arch/x86/kernel/cpu/resctrl/Makefile          |    2 +
 arch/x86/kernel/cpu/resctrl/core.c            |   31 +-
 arch/x86/kernel/cpu/resctrl/ctrlmondata.c     |  635 ---
 arch/x86/kernel/cpu/resctrl/internal.h        |  399 +-
 arch/x86/kernel/cpu/resctrl/monitor.c         |  918 +---
 arch/x86/kernel/cpu/resctrl/pseudo_lock.c     | 1092 +----
 .../resctrl/{trace.h => pseudo_lock_trace.h}  |   26 +-
 arch/x86/kernel/cpu/resctrl/rdtgroup.c        | 4164 +---------------
 arch/x86/kernel/process_32.c                  |    2 +-
 arch/x86/kernel/process_64.c                  |    2 +-
 fs/Kconfig                                    |    1 +
 fs/Makefile                                   |    1 +
 fs/resctrl/Kconfig                            |   39 +
 fs/resctrl/Makefile                           |    6 +
 fs/resctrl/ctrlmondata.c                      |  660 +++
 fs/resctrl/internal.h                         |  440 ++
 fs/resctrl/monitor.c                          |  929 ++++
 fs/resctrl/monitor_trace.h                    |   33 +
 fs/resctrl/pseudo_lock.c                      | 1105 +++++
 fs/resctrl/rdtgroup.c                         | 4344 +++++++++++++++++
 include/linux/resctrl.h                       |   36 +-
 include/linux/resctrl_types.h                 |   16 +-
 resctrl_copy_pasta.py                         |  823 ++++
 30 files changed, 8490 insertions(+), 7261 deletions(-)
 rename Documentation/{arch/x86 => filesystems}/resctrl.rst (99%)
 rename arch/x86/kernel/cpu/resctrl/{trace.h => pseudo_lock_trace.h} (56%)
 create mode 100644 fs/resctrl/Kconfig
 create mode 100644 fs/resctrl/Makefile
 create mode 100644 fs/resctrl/ctrlmondata.c
 create mode 100644 fs/resctrl/internal.h
 create mode 100644 fs/resctrl/monitor.c
 create mode 100644 fs/resctrl/monitor_trace.h
 create mode 100644 fs/resctrl/pseudo_lock.c
 create mode 100644 fs/resctrl/rdtgroup.c
 create mode 100644 resctrl_copy_pasta.py

-- 
2.39.5

Hi James,

On 4/25/25 10:37 AM, James Morse wrote:
> Changes since v8:
>  * Added check for closid_init() on monitor only platforms.
>  * Moved end-marker into array and added default cases.
>  * Additional patches to move prototpyes between header files.
>  
> Changes otherwise noted on each patch.
> 
> ---
> 
> Patches 20-26 should be squashed together when merged, taking the commit message

To make things as simple as possible this needs to be as detailed as possible. For
example, drop patch 21, *then* squash patches 20, 22 - 26. Having your repo as
reference is a great help.  

> of patch 21. They are posted like this to allow folk to re-generate patch 21, then

"patch 21" -> "patch 22"

> review the differences on top. Not squashing them together would expose a ftrace
> build warning during bisect. (but who does that!)
> That would look like this:
> git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9_final
> 
> This series is based on rc3, and can be retrieved from:
> git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9
> 
> This series renames functions and moves code around. With the

This series evolved to do more than this ;)

Reinette

Hi Reinette,

On 01/05/2025 18:51, Reinette Chatre wrote:
> On 4/25/25 10:37 AM, James Morse wrote:
>> Changes since v8:
>>  * Added check for closid_init() on monitor only platforms.
>>  * Moved end-marker into array and added default cases.
>>  * Additional patches to move prototpyes between header files.
>>  
>> Changes otherwise noted on each patch.
>>
>> ---
>>
>> Patches 20-26 should be squashed together when merged, taking the commit message
> 
> To make things as simple as possible this needs to be as detailed as possible. For
> example, drop patch 21, *then* squash patches 20, 22 - 26. Having your repo as
> reference is a great help.  

Ah - I thought I'd deleted the python script from the version posted!
I'll tighten up that wording, it should really say which commit message to keep too.

If there is unlikely to be further review for those last patches, the other option is to
do this for v9 - but point people at the earlier version if they want to see the changes
broken out. This saves some work for the tip folk.


>> of patch 21. They are posted like this to allow folk to re-generate patch 21, then
> 
> "patch 21" -> "patch 22"
> 
>> review the differences on top. Not squashing them together would expose a ftrace
>> build warning during bisect. (but who does that!)
>> That would look like this:
>> git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9_final
>>
>> This series is based on rc3, and can be retrieved from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9
>>
>> This series renames functions and moves code around. With the
> 
> This series evolved to do more than this ;)

Good point!


Thanks,

James

Hi James,

On 5/7/25 9:49 AM, James Morse wrote:
> Hi Reinette,
> 
> On 01/05/2025 18:51, Reinette Chatre wrote:
>> On 4/25/25 10:37 AM, James Morse wrote:
>>> Changes since v8:
>>>  * Added check for closid_init() on monitor only platforms.
>>>  * Moved end-marker into array and added default cases.
>>>  * Additional patches to move prototpyes between header files.
>>>  
>>> Changes otherwise noted on each patch.
>>>
>>> ---
>>>
>>> Patches 20-26 should be squashed together when merged, taking the commit message
>>
>> To make things as simple as possible this needs to be as detailed as possible. For
>> example, drop patch 21, *then* squash patches 20, 22 - 26. Having your repo as
>> reference is a great help.  
> 
> Ah - I thought I'd deleted the python script from the version posted!
> I'll tighten up that wording, it should really say which commit message to keep too.
> 
> If there is unlikely to be further review for those last patches, the other option is to
> do this for v9 - but point people at the earlier version if they want to see the changes
> broken out. This saves some work for the tip folk.

(v9 -> v10)

I do not know how much tip folk have been following this work. I also believe that 
any version should make things as simple and straightforward as possible. To that end
I am concerned about requiring folks to compare versions in order to understand a posting.
To me it sounds simpler to keep changes broken out. Personally I think squashing
clear broken out patches is simpler than trying to understand a bigger change by comparing
it to a different version of a series. Of course, this is my opinion with caveat that I
am not the one that will be doing this.

Reinette

Hi James, Reinette,


On 4/25/25 12:37, James Morse wrote:
> Changes since v8:
>  * Added check for closid_init() on monitor only platforms.
>  * Moved end-marker into array and added default cases.
>  * Additional patches to move prototpyes between header files.
>  
> Changes otherwise noted on each patch.
> 
> ---
> 
> Patches 20-26 should be squashed together when merged, taking the commit message
> of patch 21. They are posted like this to allow folk to re-generate patch 21, then
> review the differences on top. Not squashing them together would expose a ftrace
> build warning during bisect. (but who does that!)
> That would look like this:
> git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9_final
> 
> This series is based on rc3, and can be retrieved from:
> git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v9
> 
> This series renames functions and moves code around. With the
> exception of invalid configurations for the configurable-events, there should
> be no changes in behaviour caused by this series. It is now possible for
> throttle_mode to report 'undefined', but no known platform will do this.
> 
> The driving pattern is to make things like struct rdtgroup private to resctrl.
> Features like pseudo-lock aren't going to work on arm64, the ability to disable
> it at compile time is added.
> 
> After this, I can start posting the MPAM driver to make use of resctrl on arm64.
> (What's MPAM? See the cover letter of the first series. [1])
> 
> As ever - bugs welcome,
> Thanks,
> 
> James
> 
> [v8] https://lore.kernel.org/all/20250411164229.23413-1-james.morse@arm.com
> [v7] https://lore.kernel.org/all/20250228195913.24895-1-james.morse@arm.com/
> [v6] https://lore.kernel.org/lkml/20250207181823.6378-1-james.morse@arm.com/
> [v5] https://lore.kernel.org/r/20241004180347.19985-1-james.morse@arm.com
> [v4] https://lore.kernel.org/all/20240802172853.22529-1-james.morse@arm.com/
> [v3] https://lore.kernel.org/r/20240614150033.10454-1-james.morse@arm.com
> [v2] https://lore.kernel.org/r/20240426150537.8094-1-Dave.Martin@arm.com
> [v1] https://lore.kernel.org/r/20240321165106.31602-1-james.morse@arm.com
> [1] https://lore.kernel.org/lkml/20201030161120.227225-1-james.morse@arm.com/
> 
> 
> 
> Amit Singh Tomar (1):
>   x86/resctrl: Remove the limit on the number of CLOSID
> 
> Dave Martin (3):
>   x86/resctrl: Squelch whitespace anomalies in resctrl core code
>   x86/resctrl: Prefer alloc(sizeof(*foo)) idiom in rdt_init_fs_context()
>   x86/resctrl: Relax some asm #includes
> 
> James Morse (23):
>   x86/resctrl: Rename resctrl_sched_in() to begin with "resctrl_arch_"
>   x86/resctrl: Check all domains are offline in resctrl_exit()
>   x86/resctrl: resctrl_exit() teardown resctrl but leave the mount point
>   x86/resctrl: Drop __init/__exit on assorted symbols
>   x86/resctrl: Move is_mba_sc() out of core.c
>   x86/resctrl: Add end-marker to the resctrl_event_id enum
>   x86/resctrl: Expand the width of domid by replacing mon_data_bits
>   x86/resctrl: Split trace.h
>   x86/resctrl: Add 'resctrl' to the title of the resctrl documentation
>   fs/resctrl: Add boiler plate for external resctrl code
>   x86/resctrl: Move the filesystem bits to headers visible to fs/resctrl
>   x86/resctrl: Move enum resctrl_event_id to resctrl.h
>   x86/resctrl: Fix types in resctrl_arch_mon_ctx_alloc() and free stubs
>   x86/resctrl: Move pseudo lock prototypes to include/linux/resctrl.h
>   x86/resctrl: Always initialise rid field in rdt_resources_all[]
>   x86/resctrl: Remove a newline to avoid confusing the code move script
>   x86/resctrl: Add python script to move resctrl code to /fs/resctrl
>   x86,fs/resctrl: Move the resctrl filesystem code to live in
>     /fs/resctrl
>   x86,fs/resctrl: Remove duplicated trace header files
>   fs/resctrl: Remove unnecessary includes
>   fs/resctrl: Change internal.h's header guard macros
>   x86,fs/resctrl: Move resctrl.rst to live under
>     Documentation/filesystems
>   MAINTAINERS: Add reviewers for fs/resctrl
> 
>  Documentation/arch/x86/index.rst              |    1 -
>  Documentation/filesystems/index.rst           |    1 +
>  .../{arch/x86 => filesystems}/resctrl.rst     |    6 +-
>  MAINTAINERS                                   |    5 +-
>  arch/Kconfig                                  |    8 +
>  arch/x86/Kconfig                              |   11 +-
>  arch/x86/include/asm/resctrl.h                |   15 +-
>  arch/x86/kernel/cpu/resctrl/Makefile          |    2 +
>  arch/x86/kernel/cpu/resctrl/core.c            |   31 +-
>  arch/x86/kernel/cpu/resctrl/ctrlmondata.c     |  635 ---
>  arch/x86/kernel/cpu/resctrl/internal.h        |  399 +-
>  arch/x86/kernel/cpu/resctrl/monitor.c         |  918 +---
>  arch/x86/kernel/cpu/resctrl/pseudo_lock.c     | 1092 +----
>  .../resctrl/{trace.h => pseudo_lock_trace.h}  |   26 +-
>  arch/x86/kernel/cpu/resctrl/rdtgroup.c        | 4164 +---------------
>  arch/x86/kernel/process_32.c                  |    2 +-
>  arch/x86/kernel/process_64.c                  |    2 +-
>  fs/Kconfig                                    |    1 +
>  fs/Makefile                                   |    1 +
>  fs/resctrl/Kconfig                            |   39 +
>  fs/resctrl/Makefile                           |    6 +
>  fs/resctrl/ctrlmondata.c                      |  660 +++
>  fs/resctrl/internal.h                         |  440 ++
>  fs/resctrl/monitor.c                          |  929 ++++
>  fs/resctrl/monitor_trace.h                    |   33 +
>  fs/resctrl/pseudo_lock.c                      | 1105 +++++
>  fs/resctrl/rdtgroup.c                         | 4344 +++++++++++++++++
>  include/linux/resctrl.h                       |   36 +-
>  include/linux/resctrl_types.h                 |   16 +-
>  resctrl_copy_pasta.py                         |  823 ++++
>  30 files changed, 8490 insertions(+), 7261 deletions(-)
>  rename Documentation/{arch/x86 => filesystems}/resctrl.rst (99%)
>  rename arch/x86/kernel/cpu/resctrl/{trace.h => pseudo_lock_trace.h} (56%)
>  create mode 100644 fs/resctrl/Kconfig
>  create mode 100644 fs/resctrl/Makefile
>  create mode 100644 fs/resctrl/ctrlmondata.c
>  create mode 100644 fs/resctrl/internal.h
>  create mode 100644 fs/resctrl/monitor.c
>  create mode 100644 fs/resctrl/monitor_trace.h
>  create mode 100644 fs/resctrl/pseudo_lock.c
>  create mode 100644 fs/resctrl/rdtgroup.c
>  create mode 100644 resctrl_copy_pasta.py
> 

I retested the patches on a couple of AMD systems, and everything looks good.

Tested-by: Babu Moger babu.moger@amd.com

It's very likely that these patches will be merged before my ABMC series [1].

I'm currently working on v13 of the ABMC series and considering rebasing
it on top of James' v9. That could potentially eliminate one review cycle
during the merge process.

What are your thoughts on this approach?

1. https://lore.kernel.org/lkml/cover.1743725907.git.babu.moger@amd.com/
-- 
Thanks
Babu Moger

Hi Babu,

On 5/2/25 9:04 AM, Moger, Babu wrote:
> 
> I retested the patches on a couple of AMD systems, and everything looks good.
> 
> Tested-by: Babu Moger babu.moger@amd.com

Thank you very much.

> 
> It's very likely that these patches will be merged before my ABMC series [1].
> 
> I'm currently working on v13 of the ABMC series and considering rebasing
> it on top of James' v9. That could potentially eliminate one review cycle
> during the merge process.
> 
> What are your thoughts on this approach?

Thanks for considering this. From my viewpoint this sounds like a good plan.
I do not have insight into James's schedule to support this but from what I
can tell this work is close to being ready for inclusion.

Reinette

> 
> 1. https://lore.kernel.org/lkml/cover.1743725907.git.babu.moger@amd.com/

Hi Reinette,

On 5/2/25 11:30, Reinette Chatre wrote:
> Hi Babu,
> 
> On 5/2/25 9:04 AM, Moger, Babu wrote:
>>
>> I retested the patches on a couple of AMD systems, and everything looks good.
>>
>> Tested-by: Babu Moger babu.moger@amd.com

Correction:

Tested-by: Babu Moger <babu.moger@amd.com>

> 
> Thank you very much.
> 
>>
>> It's very likely that these patches will be merged before my ABMC series [1].
>>
>> I'm currently working on v13 of the ABMC series and considering rebasing
>> it on top of James' v9. That could potentially eliminate one review cycle
>> during the merge process.
>>
>> What are your thoughts on this approach?
> 
> Thanks for considering this. From my viewpoint this sounds like a good plan.

Welcome.

> I do not have insight into James's schedule to support this but from what I
> can tell this work is close to being ready for inclusion.

Sure. Lets wait for James or Martin's response.

-- 
Thanks
Babu Moger

Hi Babu, Reinette,

On 02/05/2025 17:45, Moger, Babu wrote:
> On 5/2/25 11:30, Reinette Chatre wrote:
>> On 5/2/25 9:04 AM, Moger, Babu wrote:
>>>
>>> I retested the patches on a couple of AMD systems, and everything looks good.
>>>
>>> Tested-by: Babu Moger babu.moger@amd.com
> 
> Correction:
> 
> Tested-by: Babu Moger <babu.moger@amd.com>

Thanks for re-testing it!


>> Thank you very much.
>>
>>>
>>> It's very likely that these patches will be merged before my ABMC series [1].
>>>
>>> I'm currently working on v13 of the ABMC series and considering rebasing
>>> it on top of James' v9. That could potentially eliminate one review cycle
>>> during the merge process.
>>>
>>> What are your thoughts on this approach?
>>
>> Thanks for considering this. From my viewpoint this sounds like a good plan.
> 
> Welcome.
> 
>> I do not have insight into James's schedule to support this but from what I
>> can tell this work is close to being ready for inclusion.
> 
> Sure. Lets wait for James or Martin's response.

I've got a v9 to post, rebased on top of the cpumask changes. My only question is whether
to post it with the tail end of patches squashed together - to save Boris having to do it.


Thanks,

James

Hi James,

On 5/7/25 11:49, James Morse wrote:
> Hi Babu, Reinette,
> 
> On 02/05/2025 17:45, Moger, Babu wrote:
>> On 5/2/25 11:30, Reinette Chatre wrote:
>>> On 5/2/25 9:04 AM, Moger, Babu wrote:
>>>>
>>>> I retested the patches on a couple of AMD systems, and everything looks good.
>>>>
>>>> Tested-by: Babu Moger babu.moger@amd.com
>>
>> Correction:
>>
>> Tested-by: Babu Moger <babu.moger@amd.com>
> 
> Thanks for re-testing it!
> 
> 
>>> Thank you very much.
>>>
>>>>
>>>> It's very likely that these patches will be merged before my ABMC series [1].
>>>>
>>>> I'm currently working on v13 of the ABMC series and considering rebasing
>>>> it on top of James' v9. That could potentially eliminate one review cycle
>>>> during the merge process.
>>>>
>>>> What are your thoughts on this approach?
>>>
>>> Thanks for considering this. From my viewpoint this sounds like a good plan.
>>
>> Welcome.
>>
>>> I do not have insight into James's schedule to support this but from what I
>>> can tell this work is close to being ready for inclusion.
>>
>> Sure. Lets wait for James or Martin's response.
> 
> I've got a v9 to post, rebased on top of the cpumask changes. My only question is whether
> to post it with the tail end of patches squashed together - to save Boris having to do it.

You have few comments to address in v9. I would say post v10 with all the
comments addressed without squashing. Give the clear instructions about
squashing.

Let the maintainer decide how they want to handle it. Pretty sure they
have seen these cases already. Worst case you may have to spin another
version. My 02 cents.
-- 
Thanks
Babu Moger

On 5/7/25 1:27 PM, Moger, Babu wrote:
> On 5/7/25 11:49, James Morse wrote:
>> On 02/05/2025 17:45, Moger, Babu wrote:
>>> On 5/2/25 11:30, Reinette Chatre wrote:
>>>> On 5/2/25 9:04 AM, Moger, Babu wrote:
>>>>>
>>>>> I retested the patches on a couple of AMD systems, and everything looks good.
>>>>>
>>>>> Tested-by: Babu Moger babu.moger@amd.com
>>>
>>> Correction:
>>>
>>> Tested-by: Babu Moger <babu.moger@amd.com>
>>
>> Thanks for re-testing it!
>>
>>
>>>> Thank you very much.
>>>>
>>>>>
>>>>> It's very likely that these patches will be merged before my ABMC series [1].
>>>>>
>>>>> I'm currently working on v13 of the ABMC series and considering rebasing
>>>>> it on top of James' v9. That could potentially eliminate one review cycle
>>>>> during the merge process.
>>>>>
>>>>> What are your thoughts on this approach?
>>>>
>>>> Thanks for considering this. From my viewpoint this sounds like a good plan.
>>>
>>> Welcome.
>>>
>>>> I do not have insight into James's schedule to support this but from what I
>>>> can tell this work is close to being ready for inclusion.
>>>
>>> Sure. Lets wait for James or Martin's response.
>>
>> I've got a v9 to post, rebased on top of the cpumask changes. My only question is whether
>> to post it with the tail end of patches squashed together - to save Boris having to do it.
> 
> You have few comments to address in v9. I would say post v10 with all the
> comments addressed without squashing. Give the clear instructions about
> squashing.
> 
> Let the maintainer decide how they want to handle it. Pretty sure they
> have seen these cases already. Worst case you may have to spin another
> version. My 02 cents.


I agree. I also responded to same question with 
https://lore.kernel.org/lkml/b3e31246-52d7-42b8-97f7-35925c85ddb6@intel.com/

Reinette