All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	hch@infradead.org, nsekhar@ti.com
Subject: Re: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions
Date: Wed, 5 Apr 2017 11:52:54 -0500	[thread overview]
Message-ID: <20170405165254.GA17066@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20170405085243.18123-2-kishon@ti.com>

On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote:
> Introduce a new EP core layer in order to support endpoint functions in
> linux kernel. This comprises the EPC library (Endpoint Controller Library)
> and EPF library (Endpoint Function Library). EPC library implements
> functions specific to an endpoint controller and EPF library implements
> functions specific to an endpoint function.
> ...

> +/**
> + * pci_epf_linkup() - Notify the function driver that EPC device has
> + *		      established a connection with the Root Complex.
> + * @epf: the EPF device bound to the EPC device which has established
> + *	 the connection with the host
> + *
> + * Invoke to notify the function driver that EPC device has established
> + * a connection with the Root Complex.
> + */
> +void pci_epf_linkup(struct pci_epf *epf)
> +{
> +	if (!epf->driver)
> +		dev_WARN(&epf->dev, "epf device not bound to driver\n");
> +
> +	epf->driver->ops->linkup(epf);

I don't understand what's going on here.  We warn if epf->driver is
NULL, but the next thing we do is dereference it.

For NULL pointers that are symptoms of Linux defects, I usually prefer
not to check at all so that a dereference generates an oops and we can
debug the problem.  For NULL pointers caused by user error, we would
generally return an error that percolates up to the user.

I haven't competely wrapped my head around this endpoint support, but
I assume a NULL pointer here would be caused by user error, not
necessarily a Linux defect.  So why would we dereference a NULL
pointer?  And what happens when we do?  Is this just going to oops an
embedded Linux running inside the endpoint?  Is that the correct
behavior?

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: devicetree@vger.kernel.org, Joao Pinto <Joao.Pinto@synopsys.com>,
	linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
	nsekhar@ti.com, linux-kernel@vger.kernel.org, hch@infradead.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions
Date: Wed, 5 Apr 2017 11:52:54 -0500	[thread overview]
Message-ID: <20170405165254.GA17066@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20170405085243.18123-2-kishon@ti.com>

On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote:
> Introduce a new EP core layer in order to support endpoint functions in
> linux kernel. This comprises the EPC library (Endpoint Controller Library)
> and EPF library (Endpoint Function Library). EPC library implements
> functions specific to an endpoint controller and EPF library implements
> functions specific to an endpoint function.
> ...

> +/**
> + * pci_epf_linkup() - Notify the function driver that EPC device has
> + *		      established a connection with the Root Complex.
> + * @epf: the EPF device bound to the EPC device which has established
> + *	 the connection with the host
> + *
> + * Invoke to notify the function driver that EPC device has established
> + * a connection with the Root Complex.
> + */
> +void pci_epf_linkup(struct pci_epf *epf)
> +{
> +	if (!epf->driver)
> +		dev_WARN(&epf->dev, "epf device not bound to driver\n");
> +
> +	epf->driver->ops->linkup(epf);

I don't understand what's going on here.  We warn if epf->driver is
NULL, but the next thing we do is dereference it.

For NULL pointers that are symptoms of Linux defects, I usually prefer
not to check at all so that a dereference generates an oops and we can
debug the problem.  For NULL pointers caused by user error, we would
generally return an error that percolates up to the user.

I haven't competely wrapped my head around this endpoint support, but
I assume a NULL pointer here would be caused by user error, not
necessarily a Linux defect.  So why would we dereference a NULL
pointer?  And what happens when we do?  Is this just going to oops an
embedded Linux running inside the endpoint?  Is that the correct
behavior?

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: devicetree@vger.kernel.org, Joao Pinto <Joao.Pinto@synopsys.com>,
	linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
	nsekhar@ti.com, linux-kernel@vger.kernel.org, hch@infradead.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions
Date: Wed, 5 Apr 2017 11:52:54 -0500	[thread overview]
Message-ID: <20170405165254.GA17066@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20170405085243.18123-2-kishon@ti.com>

On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote:
> Introduce a new EP core layer in order to support endpoint functions in
> linux kernel. This comprises the EPC library (Endpoint Controller Library)
> and EPF library (Endpoint Function Library). EPC library implements
> functions specific to an endpoint controller and EPF library implements
> functions specific to an endpoint function.
> ...

> +/**
> + * pci_epf_linkup() - Notify the function driver that EPC device has
> + *		      established a connection with the Root Complex.
> + * @epf: the EPF device bound to the EPC device which has established
> + *	 the connection with the host
> + *
> + * Invoke to notify the function driver that EPC device has established
> + * a connection with the Root Complex.
> + */
> +void pci_epf_linkup(struct pci_epf *epf)
> +{
> +	if (!epf->driver)
> +		dev_WARN(&epf->dev, "epf device not bound to driver\n");
> +
> +	epf->driver->ops->linkup(epf);

I don't understand what's going on here.  We warn if epf->driver is
NULL, but the next thing we do is dereference it.

For NULL pointers that are symptoms of Linux defects, I usually prefer
not to check at all so that a dereference generates an oops and we can
debug the problem.  For NULL pointers caused by user error, we would
generally return an error that percolates up to the user.

I haven't competely wrapped my head around this endpoint support, but
I assume a NULL pointer here would be caused by user error, not
necessarily a Linux defect.  So why would we dereference a NULL
pointer?  And what happens when we do?  Is this just going to oops an
embedded Linux running inside the endpoint?  Is that the correct
behavior?

Bjorn

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

WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions
Date: Wed, 5 Apr 2017 11:52:54 -0500	[thread overview]
Message-ID: <20170405165254.GA17066@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20170405085243.18123-2-kishon@ti.com>

On Wed, Apr 05, 2017 at 02:22:21PM +0530, Kishon Vijay Abraham I wrote:
> Introduce a new EP core layer in order to support endpoint functions in
> linux kernel. This comprises the EPC library (Endpoint Controller Library)
> and EPF library (Endpoint Function Library). EPC library implements
> functions specific to an endpoint controller and EPF library implements
> functions specific to an endpoint function.
> ...

> +/**
> + * pci_epf_linkup() - Notify the function driver that EPC device has
> + *		      established a connection with the Root Complex.
> + * @epf: the EPF device bound to the EPC device which has established
> + *	 the connection with the host
> + *
> + * Invoke to notify the function driver that EPC device has established
> + * a connection with the Root Complex.
> + */
> +void pci_epf_linkup(struct pci_epf *epf)
> +{
> +	if (!epf->driver)
> +		dev_WARN(&epf->dev, "epf device not bound to driver\n");
> +
> +	epf->driver->ops->linkup(epf);

I don't understand what's going on here.  We warn if epf->driver is
NULL, but the next thing we do is dereference it.

For NULL pointers that are symptoms of Linux defects, I usually prefer
not to check at all so that a dereference generates an oops and we can
debug the problem.  For NULL pointers caused by user error, we would
generally return an error that percolates up to the user.

I haven't competely wrapped my head around this endpoint support, but
I assume a NULL pointer here would be caused by user error, not
necessarily a Linux defect.  So why would we dereference a NULL
pointer?  And what happens when we do?  Is this just going to oops an
embedded Linux running inside the endpoint?  Is that the correct
behavior?

Bjorn

  reply	other threads:[~2017-04-05 16:54 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  8:52 [GIT PULL] PCI: Support for configurable PCI endpoint Kishon Vijay Abraham I
2017-04-05  8:52 ` Kishon Vijay Abraham I
2017-04-05  8:52 ` Kishon Vijay Abraham I
2017-04-05  8:52 ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05 16:52   ` Bjorn Helgaas [this message]
2017-04-05 16:52     ` Bjorn Helgaas
2017-04-05 16:52     ` Bjorn Helgaas
2017-04-05 16:52     ` Bjorn Helgaas
2017-04-06  5:19     ` Kishon Vijay Abraham I
2017-04-06  5:19       ` Kishon Vijay Abraham I
2017-04-06  5:19       ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 02/23] Documentation: PCI: Guide to use PCI Endpoint Core Layer Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 03/23] PCI: endpoint: Introduce configfs entry for configuring EP functions Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 04/23] Documentation: PCI: Guide to use PCI endpoint configfs Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 05/23] PCI: endpoint: Create configfs entry for EPC device and EPF driver Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 06/23] Documentation: PCI: Add specification for the *PCI test* function device Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 07/23] PCI: endpoint: functions: Add an EP function to test PCI Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 08/23] Documentation: PCI: Add binding documentation for pci-test endpoint function Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 09/23] PCI: dwc: designware: Add EP mode support Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 10/23] dt-bindings: PCI: Add DT bindings for PCI designware EP mode Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 11/23] PCI: dwc: dra7xx: Facilitate wrapper and MSI interrupts to be enabled independently Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 12/23] PCI: dwc: dra7xx: Add EP mode support Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 13/23] dt-bindings: PCI: dra7xx: Add DT bindings for PCI dra7xx EP mode Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 14/23] PCI: dwc: dra7xx: Workaround for errata id i870 Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 15/23] dt-bindings: PCI: dra7xx: Add DT bindings to enable unaligned access Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 16/23] PCI: Add device IDs for DRA74x and DRA72x Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 17/23] misc: Add host side PCI driver for PCI test function device Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 18/23] Documentation: misc-devices: Add Documentation for pci-endpoint-test driver Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 19/23] tools: PCI: Add a userspace tool to test PCI endpoint Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 20/23] tools: PCI: Add sample test script to invoke pcitest Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 21/23] Documentation: PCI: Add userguide for PCI endpoint test function Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 22/23] MAINTAINERS: Add PCI Endpoint maintainer Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52 ` [PATCH v6 23/23] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-05  8:52   ` Kishon Vijay Abraham I
2017-04-10 13:55 ` [PATCH v7 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions Kishon Vijay Abraham I
2017-04-10 13:55   ` Kishon Vijay Abraham I
2017-04-10 13:55   ` Kishon Vijay Abraham I
2017-04-10 13:55   ` Kishon Vijay Abraham I
2022-12-13 23:44   ` Bjorn Helgaas
2022-12-13 23:44     ` Bjorn Helgaas
2017-04-10 15:43 ` [GIT PULL] PCI: Support for configurable PCI endpoint Bjorn Helgaas
2017-04-10 15:43   ` Bjorn Helgaas
2017-04-10 15:43   ` Bjorn Helgaas
2017-04-10 15:43   ` Bjorn Helgaas
2017-04-11 19:34   ` Bjorn Helgaas
2017-04-11 19:34     ` Bjorn Helgaas
2017-04-11 19:34     ` Bjorn Helgaas
2017-04-12  5:43     ` Kishon Vijay Abraham I
2017-04-12  5:43       ` Kishon Vijay Abraham I
2017-04-12  5:43       ` Kishon Vijay Abraham I

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=20170405165254.GA17066@bhelgaas-glaptop.roam.corp.google.com \
    --to=helgaas@kernel.org \
    --cc=Joao.Pinto@synopsys.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nsekhar@ti.com \
    /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 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.