All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Andrew Murray" <amurray@thegoodpenguin.co.uk>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Marek Behún" <marek.behun@nic.cz>,
	"Remi Pommarel" <repk@triplefau.lt>,
	"Tomasz Maciej Nowak" <tmn505@gmail.com>,
	Xogium <contact@xogium.me>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] PCI: aardvark: Don't touch PCIe registers if no card connected
Date: Thu, 9 Jul 2020 17:09:59 +0200	[thread overview]
Message-ID: <20200709150959.wq6zfkcy4m6hvvpl@pali> (raw)
In-Reply-To: <20200709144701.GA21760@e121166-lin.cambridge.arm.com>

On Thursday 09 July 2020 15:47:01 Lorenzo Pieralisi wrote:
> On Thu, Jul 09, 2020 at 02:22:08PM +0200, Pali Rohár wrote:
> > On Thursday 09 July 2020 12:35:09 Lorenzo Pieralisi wrote:
> > > On Thu, Jul 02, 2020 at 10:30:36AM +0200, Pali Rohár wrote:
> > > > When there is no PCIe card connected and advk_pcie_rd_conf() or
> > > > advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated
> > > > root bridge, the aardvark driver throws the following error message:
> > > > 
> > > >   advk-pcie d0070000.pcie: config read/write timed out
> > > > 
> > > > Obviously accessing PCIe registers of disconnected card is not possible.
> > > > 
> > > > Extend check in advk_pcie_valid_device() function for validating
> > > > availability of PCIe bus. If PCIe link is down, then the device is marked
> > > > as Not Found and the driver does not try to access these registers.
> > > > 
> > > > This is just an optimization to prevent accessing PCIe registers when card
> > > > is disconnected. Trying to access PCIe registers of disconnected card does
> > > > not cause any crash, kernel just needs to wait for a timeout. So if card
> > > > disappear immediately after checking for PCIe link (before accessing PCIe
> > > > registers), it does not cause any problems.
> > > > 
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > 
> > > > ---
> > > > Changes in V3:
> > > > * Add comment to the code
> > > > Changes in V2:
> > > > * Update commit message, mention that this is optimization
> > > > ---
> > > >  drivers/pci/controller/pci-aardvark.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> > > > index 90ff291c24f0..d18f389b36a1 100644
> > > > --- a/drivers/pci/controller/pci-aardvark.c
> > > > +++ b/drivers/pci/controller/pci-aardvark.c
> > > > @@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
> > > >  	if ((bus->number == pcie->root_bus_nr) && PCI_SLOT(devfn) != 0)
> > > >  		return false;
> > > >  
> > > > +	/*
> > > > +	 * If the link goes down after we check for link-up, nothing bad
> > > > +	 * happens but the config access times out.
> > > > +	 */
> > > > +	if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up(pcie))
> > > > +		return false;
> > > > +
> > > >  	return true;
> > > >  }
> > > 
> > > Question: this basically means that you can only effectively enumerate
> > > bus number == root_bus_nr and AFAICS if at probe the link did not
> > > come up it will never do, will it ?
> > > 
> > > Isn't this equivalent to limiting the bus numbers the bridge is capable
> > > of handling ?
> > > 
> > > Reworded: if in advk_pcie_setup_hw() the link does not come up, what's
> > > the point of trying to enumerate the bus hierarchy below the root bus ?
> > 
> > Hello Lorenzo!
> > 
> > PCIe link can theoretically come up even after boot, but aardvark driver
> > currently does not support link detection at runtime. So it checks and
> > enumerate device only at probe time.
> 
> If the link is not up at probe enumerating devices below the root
> bus is basically useless and that's actually what is causing the
> delays you are fixing. Is this correct ?

Yes, this is one (but not the only one) delay.

> > I do not know if hardware has some mechanism to inform kernel that PCIe
> > link come up (or down) and re-enumeration is required. Or the only
> > option is polling via advk_pcie_link_up().
> > 
> > So if device is not visible at the probe time then it would not appear
> > in system and cannot be used. This is current state.
> > 
> > Just to note that our hardware does not support physical hotplug of
> > mPCIe cards. You need to connect card when board is powered off.
> > 
> > So if at the aardvark probe time PCIe link is not up then trying to
> > enumerate devices under (software) root bridge is not needed. But it is
> > needed to register/enumerate software root bridge device and currently
> > both is done by one (recursive) call pci_host_probe().
> 
> I understand that but the bridge bus resource can be trimmed to just
> contain the root bus because that's the only one where there is a
> chance you can enumerate a device.

It is possible to register only root bridge without endpoint?

> I would like to get Bjorn's opinion on this, I don't like these "link is
> up" checks in config accessors (they are racy and honestly it is a
> run-time check that does not make much sense, either it is always
> true/false or it is inevitably racy)

It is runtime check, but does not have to be always true/false. I have
tested more Compex wifi cards and under certain conditions they
"disappear" from the bus during usage.

So I think it still make sense to do this "fast" check as it is only
optimization.

> I was wondering if we can find an
> alternative solution but I am not sure the one I suggested above is
> better than this patch.

I do not know if it helps in situation when card disappear from bus on
runtime...

WARNING: multiple messages have this Message-ID
From: "Pali Rohár" <pali@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Tomasz Maciej Nowak" <tmn505@gmail.com>,
	linux-pci@vger.kernel.org, Xogium <contact@xogium.me>,
	linux-kernel@vger.kernel.org, "Marek Behún" <marek.behun@nic.cz>,
	"Remi Pommarel" <repk@triplefau.lt>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-arm-kernel@lists.infradead.org,
	"Andrew Murray" <amurray@thegoodpenguin.co.uk>
Subject: Re: [PATCH v3] PCI: aardvark: Don't touch PCIe registers if no card connected
Date: Thu, 9 Jul 2020 17:09:59 +0200	[thread overview]
Message-ID: <20200709150959.wq6zfkcy4m6hvvpl@pali> (raw)
In-Reply-To: <20200709144701.GA21760@e121166-lin.cambridge.arm.com>

On Thursday 09 July 2020 15:47:01 Lorenzo Pieralisi wrote:
> On Thu, Jul 09, 2020 at 02:22:08PM +0200, Pali Rohár wrote:
> > On Thursday 09 July 2020 12:35:09 Lorenzo Pieralisi wrote:
> > > On Thu, Jul 02, 2020 at 10:30:36AM +0200, Pali Rohár wrote:
> > > > When there is no PCIe card connected and advk_pcie_rd_conf() or
> > > > advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated
> > > > root bridge, the aardvark driver throws the following error message:
> > > > 
> > > >   advk-pcie d0070000.pcie: config read/write timed out
> > > > 
> > > > Obviously accessing PCIe registers of disconnected card is not possible.
> > > > 
> > > > Extend check in advk_pcie_valid_device() function for validating
> > > > availability of PCIe bus. If PCIe link is down, then the device is marked
> > > > as Not Found and the driver does not try to access these registers.
> > > > 
> > > > This is just an optimization to prevent accessing PCIe registers when card
> > > > is disconnected. Trying to access PCIe registers of disconnected card does
> > > > not cause any crash, kernel just needs to wait for a timeout. So if card
> > > > disappear immediately after checking for PCIe link (before accessing PCIe
> > > > registers), it does not cause any problems.
> > > > 
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > 
> > > > ---
> > > > Changes in V3:
> > > > * Add comment to the code
> > > > Changes in V2:
> > > > * Update commit message, mention that this is optimization
> > > > ---
> > > >  drivers/pci/controller/pci-aardvark.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> > > > index 90ff291c24f0..d18f389b36a1 100644
> > > > --- a/drivers/pci/controller/pci-aardvark.c
> > > > +++ b/drivers/pci/controller/pci-aardvark.c
> > > > @@ -644,6 +644,13 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
> > > >  	if ((bus->number == pcie->root_bus_nr) && PCI_SLOT(devfn) != 0)
> > > >  		return false;
> > > >  
> > > > +	/*
> > > > +	 * If the link goes down after we check for link-up, nothing bad
> > > > +	 * happens but the config access times out.
> > > > +	 */
> > > > +	if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up(pcie))
> > > > +		return false;
> > > > +
> > > >  	return true;
> > > >  }
> > > 
> > > Question: this basically means that you can only effectively enumerate
> > > bus number == root_bus_nr and AFAICS if at probe the link did not
> > > come up it will never do, will it ?
> > > 
> > > Isn't this equivalent to limiting the bus numbers the bridge is capable
> > > of handling ?
> > > 
> > > Reworded: if in advk_pcie_setup_hw() the link does not come up, what's
> > > the point of trying to enumerate the bus hierarchy below the root bus ?
> > 
> > Hello Lorenzo!
> > 
> > PCIe link can theoretically come up even after boot, but aardvark driver
> > currently does not support link detection at runtime. So it checks and
> > enumerate device only at probe time.
> 
> If the link is not up at probe enumerating devices below the root
> bus is basically useless and that's actually what is causing the
> delays you are fixing. Is this correct ?

Yes, this is one (but not the only one) delay.

> > I do not know if hardware has some mechanism to inform kernel that PCIe
> > link come up (or down) and re-enumeration is required. Or the only
> > option is polling via advk_pcie_link_up().
> > 
> > So if device is not visible at the probe time then it would not appear
> > in system and cannot be used. This is current state.
> > 
> > Just to note that our hardware does not support physical hotplug of
> > mPCIe cards. You need to connect card when board is powered off.
> > 
> > So if at the aardvark probe time PCIe link is not up then trying to
> > enumerate devices under (software) root bridge is not needed. But it is
> > needed to register/enumerate software root bridge device and currently
> > both is done by one (recursive) call pci_host_probe().
> 
> I understand that but the bridge bus resource can be trimmed to just
> contain the root bus because that's the only one where there is a
> chance you can enumerate a device.

It is possible to register only root bridge without endpoint?

> I would like to get Bjorn's opinion on this, I don't like these "link is
> up" checks in config accessors (they are racy and honestly it is a
> run-time check that does not make much sense, either it is always
> true/false or it is inevitably racy)

It is runtime check, but does not have to be always true/false. I have
tested more Compex wifi cards and under certain conditions they
"disappear" from the bus during usage.

So I think it still make sense to do this "fast" check as it is only
optimization.

> I was wondering if we can find an
> alternative solution but I am not sure the one I suggested above is
> better than this patch.

I do not know if it helps in situation when card disappear from bus on
runtime...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-07-09 15:10 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 14:31 [PATCH] " Pali Rohár
2020-05-28 14:31 ` Pali Rohár
2020-05-28 16:26 ` Bjorn Helgaas
2020-05-28 16:26   ` Bjorn Helgaas
2020-05-28 16:38   ` Pali Rohár
2020-05-28 16:38     ` Pali Rohár
2020-05-28 16:49     ` Bjorn Helgaas
2020-05-28 16:49       ` Bjorn Helgaas
2020-05-29  8:30       ` Pali Rohár
2020-05-29  8:30         ` Pali Rohár
2020-06-30 12:31         ` Pali Rohár
2020-06-30 12:31           ` Pali Rohár
2020-06-30 13:51     ` Bjorn Helgaas
2020-06-30 13:51       ` Bjorn Helgaas
2020-06-30 14:04       ` Pali Rohár
2020-06-30 14:04         ` Pali Rohár
2020-06-30 14:58         ` Bjorn Helgaas
2020-06-30 14:58           ` Bjorn Helgaas
2020-07-01  8:08           ` Pali Rohár
2020-07-01  8:08             ` Pali Rohár
2020-07-01  8:20 ` [PATCH v2] " Pali Rohár
2020-07-01  8:20   ` Pali Rohár
2020-07-01 21:34   ` Bjorn Helgaas
2020-07-01 21:34     ` Bjorn Helgaas
2020-07-02  8:23     ` Pali Rohár
2020-07-02  8:23       ` Pali Rohár
2020-07-02  8:30 ` [PATCH v3] " Pali Rohár
2020-07-02  8:30   ` Pali Rohár
2020-07-09 11:35   ` Lorenzo Pieralisi
2020-07-09 11:35     ` Lorenzo Pieralisi
2020-07-09 12:22     ` Pali Rohár
2020-07-09 12:22       ` Pali Rohár
2020-07-09 14:47       ` Lorenzo Pieralisi
2020-07-09 14:47         ` Lorenzo Pieralisi
2020-07-09 15:09         ` Pali Rohár [this message]
2020-07-09 15:09           ` Pali Rohár
2020-07-10  9:18           ` Lorenzo Pieralisi
2020-07-10  9:18             ` Lorenzo Pieralisi
2020-07-10 15:44             ` Pali Rohár
2020-07-10 15:44               ` Pali Rohár
2020-07-10 16:08               ` Bjorn Helgaas
2020-07-10 16:08                 ` Bjorn Helgaas
2020-07-10 19:30                 ` Pali Rohár
2020-07-10 19:30                   ` Pali Rohár
2020-07-10 20:08                   ` Bjorn Helgaas
2020-07-10 20:08                     ` Bjorn Helgaas
2020-07-13  8:27             ` Pali Rohár
2020-07-13  8:27               ` Pali Rohár
2020-07-13 11:23               ` Lorenzo Pieralisi
2020-07-13 11:23                 ` Lorenzo Pieralisi
2020-07-13 14:50                 ` Pali Rohár
2020-07-13 14:50                   ` Pali Rohár
2020-07-13 16:41                   ` Lorenzo Pieralisi
2020-07-13 16:41                     ` Lorenzo Pieralisi
2020-07-14  7:38                     ` Pali Rohár
2020-07-14  7:38                       ` Pali Rohár
2020-07-15 12:17                 ` Pali Rohár
2020-07-15 12:17                   ` Pali Rohár
2020-07-15 16:21                   ` Lorenzo Pieralisi
2020-07-15 16:21                     ` Lorenzo Pieralisi
2020-07-21  8:57                     ` Pali Rohár
2020-07-21  8:57                       ` Pali Rohár
2020-07-21 10:48                       ` Lorenzo Pieralisi
2020-07-21 10:48                         ` Lorenzo Pieralisi

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=20200709150959.wq6zfkcy4m6hvvpl@pali \
    --to=pali@kernel.org \
    --cc=amurray@thegoodpenguin.co.uk \
    --cc=bhelgaas@google.com \
    --cc=contact@xogium.me \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marek.behun@nic.cz \
    --cc=repk@triplefau.lt \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tmn505@gmail.com \
    --subject='Re: [PATCH v3] PCI: aardvark: Don'\''t touch PCIe registers if no card connected' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.