public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	Frank.Li@nxp.com, dlemoal@kernel.org,
	"Koichiro Den" <den@valinux.co.jp>,
	linux-pci@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] PCI: endpoint: pci-epf-test: Allow overriding default BAR sizes
Date: Wed, 28 Jan 2026 19:59:27 +0100	[thread overview]
Message-ID: <aXpcj8MfxsbrKl4O@ryzen> (raw)
In-Reply-To: <aXo6w4AM-UgoyICd@ryzen>

On Wed, Jan 28, 2026 at 05:35:15PM +0100, Niklas Cassel wrote:
> On Wed, Jan 28, 2026 at 01:47:45PM +0530, Manivannan Sadhasivam wrote:

(snip)

> But I am slightly worried of the complexity it brings...
> Because we already have an .epc_init callback in an EPF driver.
> If we also bring add a ".pre_start_link" callback in an EPF driver,
> how should an EPF driver developer know what to put in each callback?
> 
> I guess in that case we would want to remove the .epc_init callback?
> 
> (Because calling .set_bar() etc. should work to be called in a
> .pre_start_link for both those driver relying on external refclock and
> for those that don't.
> 
> If you do
> # echo 1 > controllers/a40000000.pcie-ep/start
> on a platform that requires an external reflock, before the external
> refclock is available, that is your own fault.
> 
> I guess we could detect that and give a nice error.)

pci_epf_test_alloc_space() is called by pci_epf_test_bind().

pci_epc_set_bar() is called by pci_epf_test_epc_init().

On platforms that do not require an external reference clock to do
register writes to their own config space, i.e. all drivers except
(pcie-qcom and pcie-tegra194), a single configfs link command will cause
both both of these callback to be called directly after each other:

# ln -s functions/pci_epf_test/func1 controllers/a40000000.pcie-ep/
[  578.073152] pci_epf_test_bind
[  578.075614] pci_epf_test_epc_init


So, unless we want to change the design of pci-epf-test to:
1) Move the allocation of BARs from .bind() to a new
   .pre_start_link() callback.
2) Move the call to pci_epc_set_bar() from epc_init() to a new
   .pre_start_link() callback.
3) Remove the now unused .epc_init() callback.

...and for consistency, we would also need to do these steps for all
the other existing EPF drivers...

I am not convinced that it is worth reworking the EPF callbacks for this
(test driver) feature, which will only used for PCI endpoint developers,
especially given the complexity it would require.

For platforms drivers that require external reference clock, is it possible
to call
echo 1 > start

before we get refclock?

If so the design would probably need to be changed even more drastically...



When we introduce .epc_init, one of the reasons why we decided to have
alloc_space() and set_bar() in two different callbacks, was if a host driver
toggled PERST, the EPF driver would not need to call free() on the backing
memory it has allocated, e.g. I can see that pci_epf_test_epc_deinit() calls
clear_bar(), but the only place that actually frees the memory backing the
BARs is pci_epf_test_unbind().


What if the user wants to do:

# echo 1024 > functions/pci_epf_test/func1/pci_epf_test.0/bar1_size
# echo 0 > controllers/a40000000.pcie-ep/start
# echo 2048 > functions/pci_epf_test/func1/pci_epf_test.0/bar1_size
# echo 1 > controllers/a40000000.pcie-ep/start

Do we want to make the allocation each time we echo 1 > start... ?

If someone stops the link.. is it really wrong to free the memory?

I'm not against this design, but with the complexity that we want
.epc_init() to only call set_bar(), and we probably want .pre_start_link()
to call alloc_space()...

I don't think that the small feature in this patch is enough
justification to modify how all EPF driver to their backing memory
allocations just for this...

Instead I will just send a new version such that if the user get -EINVAL
if trying to change bar*_size in configfs AFTER the EPF has been bound to
an EPC (i.e. it can only be done before binding to an EPC.), as that seems
like the most pragmatic compromise that will avoid (another) redesign of
the EPF callbacks.


Kind regards,
Niklas

      reply	other threads:[~2026-01-28 18:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 18:07 [PATCH] PCI: endpoint: pci-epf-test: Allow overriding default BAR sizes Niklas Cassel
2026-01-26 18:20 ` Frank Li
2026-01-27  3:44 ` Koichiro Den
2026-01-27  9:47   ` Niklas Cassel
2026-01-28  5:21     ` Koichiro Den
2026-01-28  8:17 ` Manivannan Sadhasivam
2026-01-28 16:35   ` Niklas Cassel
2026-01-28 18:59     ` Niklas Cassel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aXpcj8MfxsbrKl4O@ryzen \
    --to=cassel@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=den@valinux.co.jp \
    --cc=dlemoal@kernel.org \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox