Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 31 Jul 2023 19:59:12 +0200
From:   Lukas Wunner <lukas@wunner.de>
To:     Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc:     Alistair Francis <alistair23@gmail.com>, bhelgaas@google.com,
        linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
        Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH] PCI/DOE: Expose the DOE protocols via sysfs
Message-ID: <20230731175912.GB19517@wunner.de>
References: <20230725035755.2621507-1-alistair.francis@wdc.com>
 <20230725163046.GA23990@wunner.de>
 <20230727093857.000017aa@Huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230727093857.000017aa@Huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Thu, Jul 27, 2023 at 09:38:57AM +0100, Jonathan Cameron wrote:
> On Tue, 25 Jul 2023 18:30:46 +0200 Lukas Wunner <lukas@wunner.de> wrote:
> > Do have plans for
> > either of that or what's the motivation to use sysfs?
[...]
> I can see it would also be useful for things that will poke from
> userspace because they aren't expected to run in production (and hence
> hopefully don't care about potential races etc). CXL compliance
> comes to mind - I don't think we ever want to carry kernel code for that.

FWIW, USB4/Thunderbolt does have kernel code for DMA testing with a
special dongle (drivers/thunderbolt/dma_test.c) as well as code for
lane margining, so there *is* some precedent for that... :)

  config USB4_DEBUGFS_MARGINING
	bool "Expose receiver lane margining operations under USB4 ports (DANGEROUS)"
	depends on DEBUG_FS
	depends on USB4_DEBUGFS_WRITE
	help
	  Enables hardware and software based receiver lane margining support
	  under each USB4 port. Used for electrical quality and robustness
	  validation during manufacturing. Should not be enabled by distro
	  kernels.

Thanks,

Lukas