Thread (24 messages) 24 messages, 3 authors, 2017-03-13

[RESEND PATCH v3 4/7] PCI: dwc: all: Modify dbi accessors to take dbi_base as argument

From: Niklas Cassel <hidden>
Date: 2017-03-10 15:47:27
Also in: linux-omap, linux-pci, lkml


On 03/10/2017 01:56 PM, Kishon Vijay Abraham I wrote:
Hi Niklas,

On Friday 10 March 2017 06:01 PM, Niklas Cassel wrote:
quoted
On 03/10/2017 12:36 PM, Kishon Vijay Abraham I wrote:
quoted
Hi,

On Thursday 09 March 2017 08:35 PM, Niklas Cassel wrote:
quoted
On 03/09/2017 03:48 PM, Niklas Cassel wrote:
quoted
On 03/09/2017 07:39 AM, Kishon Vijay Abraham I wrote:
quoted
dwc has 2 dbi address space labeled dbics and dbics2. The existing
helper to access dbi address space can access only dbics. However
dbics2 has to be accessed for programming the BAR registers in the
case of EP mode. This is in preparation for adding EP mode support
to dwc driver.
Hello Kishon

I don't really like the idea of adding an extra argument to every existing read/write.
Will not a read/write using dbi2 be quite uncommon compared to a read/write
using dbi?

How about something like this:

void __dw_pcie_writel(struct dw_pcie *pci, void __iomem *base, u32 reg, u32 val)
{
    if (pci->ops->writel_dbi)
        pci->ops->writel_dbi(pci, base, reg, val);
    else
        writel(val, base + reg);
}

#define dw_pcie_writel_dbi(pci, reg, val) __dw_pcie_writel(pci, pci->dbi_base, reg, val)
#define dw_pcie_writel_dbi2(pci, reg, val) __dw_pcie_writel(pci, pci->dbi_base2, reg, val)
Perhaps make dw_pcie_writel_dbi2 a function rather than a define,
so we can return an error if pci->dbi_base2 == NULL.
Should we return an error? We don't return error for dbi_base either. I think
it should be sufficient to return errors while populating dbi_base or
dbi_base2. Otherwise it's a bug and should result in abort. Joao?
Sorry for previous empty email.


What I meant to write:

Right now we do error checking for dbi_base in platform specific code
and in pcie-designware-host.c:dw_pcie_host_init.
it's been done in dw_pcie_host_init not as an error checking but since it's
*optional* for certain platforms to populate dbi_base (i.e where dbi_base is
mapped to configuration space), host_init takes care of assigning dbi_base to
configuration space address.
What I'm afraid of is that we might get a NULL ptr dereference
when using dw_pcie_writel_dbi2, if platform specific code has
not populated dbi_base2.

Having a NULL check in generic code is just a fail safe if some
platform specific code failed to NULL check.

The code in dw_pcie_host_init might have been written just
to populate dbi_base when dbi is mapped to config space,
but the end result is that if platform specific code did not
populate dbi_base (and did not populate pp->cfg),
we will return -ENOMEM.
Which means that we can never get a NULL ptr dereference
when using dw_pcie_writel_dbi.

It might be a good idea to have a NULL check in generic code,
just as a fail safe, also for dw_pcie_ep_init.
That way we know that we will not get a NULL ptr dereference
when using dw_pcie_writel_dbi2.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help