linux-kernel - RE: [PATCH v5 01/26] cxl/acpi: Probe RCRB later during RCH downstream port creation

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Jun 2023 18:11:54 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        Terry Bowman <terry.bowman@....com>,
        <alison.schofield@...el.com>, <vishal.l.verma@...el.com>,
        <ira.weiny@...el.com>, <bwidawsk@...nel.org>,
        <dave.jiang@...el.com>, <Jonathan.Cameron@...wei.com>,
        <linux-cxl@...r.kernel.org>
CC:     <terry.bowman@....com>, <rrichter@....com>,
        <linux-kernel@...r.kernel.org>, <bhelgaas@...gle.com>
Subject: RE: [PATCH v5 01/26] cxl/acpi: Probe RCRB later during RCH
 downstream port creation

Dan Williams wrote:
> Terry Bowman wrote:
> > From: Robert Richter <rrichter@....com>
> > 
> > The RCRB is extracted already during ACPI CEDT table parsing while the
> > data of this is needed not earlier than dport creation. This
> > implementation comes with drawbacks: During ACPI table scan there is
> > already MMIO access including mapping and unmapping, but only ACPI
> > data should be collected here. The collected data must be transferred
> > through a couple of interfaces until it is finally consumed when
> > creating the dport. This causes complex data structures and function
> > interfaces. Additionally, RCRB parsing will be extended to also
> > extract AER data, it would be much easier do this at a later point
> > during port and dport creation when the data structures are available
> > to hold that data.
> > 
> > To simplify all that, probe the RCRB at a later point during RCH
> > downstream port creation. Change ACPI table parser to only extract the
> > base address of either the component registers or the RCRB. Parse and
> > extract the RCRB in devm_cxl_add_rch_dport().
> > 
> > This is in preparation to centralize all RCRB scanning.
> 
> I really like the approach of this patch, the cleanups just make sense,
> the changelog is great...
[..]
> To be clear, I feel this is my maintenance burden to bear, I don't fault
> you for not using cxl_test, but I am invested in keeping it operational.

On to patch2... 

$ stg push
Pushing patch "cxl-rch-prepare-for-caching" ... done (conflict)
Error: 8 merge conflict(s)
       CONFLICT (content): Merge conflict in tools/testing/cxl/test/mock.h
       CONFLICT (content): Merge conflict in tools/testing/cxl/test/mock.c
       CONFLICT (content): Merge conflict in tools/testing/cxl/test/cxl.c
       CONFLICT (content): Merge conflict in tools/testing/cxl/Kbuild
       CONFLICT (content): Merge conflict in drivers/cxl/mem.c
       CONFLICT (content): Merge conflict in drivers/cxl/cxl.h
       CONFLICT (content): Merge conflict in drivers/cxl/core/regs.c
       CONFLICT (content): Merge conflict in drivers/cxl/core/port.c
Now at patch "cxl-rch-prepare-for-caching"

...oh, looks like you are trying to keep cxl_test going. I had stopped
at patch1 because that one already raised a circular dependency build
error:

depmod: ERROR: Cycle detected: cxl_mock -> cxl_core -> cxl_mock

Let me see what's going on here...