On Tue, Nov 23, 2021 at 11:54:03PM -0800, Dan Williams wrote: > On Tue, Nov 23, 2021 at 11:33 PM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Nov 24, 2021 at 08:28:24AM +0100, Christoph Hellwig wrote: > > > On Tue, Nov 23, 2021 at 11:17:55PM -0800, Dan Williams wrote: > > > > I am missing the counter proposal in both Bjorn's and your distaste > > > > for aux bus and PCIe portdrv? > > > > > > Given that I've only brought in in the last mail I have no idea what > > > the original proposal even is. > > > > Neither do I :( > > To be clear I am also trying to get to the root of Bjorn's concern. > > The proposal in $SUBJECT is to build on / treat a CXL topology as a > Linux device topology on /sys/bus/cxl that references devices on > /sys/bus/platform (CXL ACPI topology root and Host Bridges) and > /sys/bus/pci (CXL Switches and Endpoints). Wait, I am confused. A bus lists devices that are on that bus. It does not list devices that are on other busses. Now a device in a bus list can have a parent be on different types of busses, as the parent device does not matter, but the device itself can not be of different types. So I do not understand what you are describing here at all. Do you have an example output of sysfs that shows this situation? > This CXL port device topology has already been shipping for a few > kernel cycles. So it's always been broken? :) > What is on > the table now is a driver for CXL port devices (a logical Linux > construct). The driver handles discovery of "component registers" > either by ACPI table or PCI DVSEC and offers services to proxision CXL > regions. So a normal bus controller device that creates new devices of a bus type, right? What is special about that? > CXL 'regions' are also proposed as Linux devices that > represent an active CXL memory range which can interleave multiple > endpoints across multiple switches and host bridges. As long as these 'devices' have drivers and do not mess with the resources of any other device in the system, I do not understand the problem here. Or is the issue that you are again trying to carve up "real" devices into tiny devices that then somehow need to be aware of the resources being touched by different drivers at the same time? I'm still confused, sorry. greg k-h
