From: Arnd Bergmann <arnd@arndb.de>
To: Gabriel Fernandez <gabriel.fernandez@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Gabriel FERNANDEZ <gabriel.fernandez@st.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Srinivas Kandagatla <srinivas.kandagatla@gmail.com>,
Maxime Coquelin <maxime.coquelin@st.com>,
Patrice Chotard <patrice.chotard@st.com>,
Russell King <linux@arm.linux.org.uk>,
Bjorn Helgaas <bhelgaas@google.com>,
Mohit Kumar <mohit.kumar@st.com>,
Jingoo Han <jg1.han@samsung.com>,
Grant Likely <grant.likely@linaro.org>,
Fabrice Gasnier <fabrice.gasnier@st.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Thierry Reding <treding@nvidia.com>,
Minghuan Lian <Minghuan.Lian@freescale.com>,
Magnus Damm <damm@opensource.se>,
Will Deacon <will.deacon@arm.com>,
Tanmay Inamdar <tinamdar@apm.com>,
Murali Karicheri <m-karicheri2@ti.com>,
Kishon Vijay Abraham I <kishon@ti.com>,
Pratyush Anand <pratyush.anand@st.com>,
Sachin Kamat <sachin.kamat@samsung.com>,
Andrew Lunn <andrew@lunn.ch>, Liviu Dudau <Liviu.Dudau@arm.com>,
Srikanth Thokala <sthokal@xilinx.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"kernel@stlinux.com" <kernel@stlinux.com>,
linux-pci@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 3/5] PCI: st: Provide support for the sti PCIe controller
Date: Wed, 21 Jan 2015 20:35:41 +0100 [thread overview]
Message-ID: <6574269.bTBzFhcnBx@wuerfel> (raw)
In-Reply-To: <CAG374jCRByNZuuYxi5+-mKvV7p5-tCf2G+8mTYfzU4rRV4yfYQ@mail.gmail.com>
On Wednesday 21 January 2015 16:47:36 Gabriel Fernandez wrote:
> On 19 January 2015 at 14:49, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 19 January 2015 13:37:33 Gabriel Fernandez wrote:
> >> On 17 December 2014 at 23:14, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Wednesday 17 December 2014 11:34:44 Gabriel FERNANDEZ wrote:
> >> > > +/*
> >> > > + * On ARM platforms, we actually get a bus error returned when the PCIe
> >> > IP
> >> > > + * returns a UR or CRS instead of an OK.
> >> > > + */
> >> > > +static int st_pcie_abort_
> >> >
> >> > handler(unsigned long addr, unsigned int fsr,
> >> > > + struct pt_regs *regs)
> >> > > +{
> >> > > + return 0;
> >> > > +}
> >> >
> >> > You should check that it's actually PCI that caused the abort. Don't
> >> > just ignore a hard error condition.
> >> >
> >> > Usually there are registers in the PCI core that let you identify what
> >> > happened.
> >> >
> >>
> >>
> >> We return 0 because abort handler is not activated during boot.
> >>
> >
> > Can you just remove the handler then? We should never have exception
> > handlers that unconditionally return 0.
> >
>
> Ah sorry, we need the handler because we can received aborts from
> user-land after the boot.
>
> I have 2 solutions, the first to simplify we can only return 0.
> The second is to manage handler during boot. Then i need for that a
> new patch from Fabrice
> https://lkml.org/lkml/2014/2/7/631
I still don't get it. What is causing the abort? Is that something
user space does, or is it just a condition that gets stuck the pcie
device after probing that gets delivered once as soon as the aborts
are enabled?
> >>
> >> msi_data is a virtual address, it's obtained through a __get_free_pages()
> >> function in dw_pcie_msi_init() procedure.
> >
> > I guess you need dma_map_single() then, or use dma_alloc_coherent instead
> > of __get_free_pages(). There is no guarantee that the page you allocate
> > there is actually visible to the PCI host at the same address that the CPU
> > uses, so you need to map from a CPU address to a DMA address that the PCI
> > host bridge uses.
> >
> > Arnd
>
> This is only to check the msi magic address given to ip, we never read
> or write in this area.
> this code is only a check
But doesn't the hardware access the pointer?
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] PCI: st: Provide support for the sti PCIe controller
Date: Wed, 21 Jan 2015 20:35:41 +0100 [thread overview]
Message-ID: <6574269.bTBzFhcnBx@wuerfel> (raw)
In-Reply-To: <CAG374jCRByNZuuYxi5+-mKvV7p5-tCf2G+8mTYfzU4rRV4yfYQ@mail.gmail.com>
On Wednesday 21 January 2015 16:47:36 Gabriel Fernandez wrote:
> On 19 January 2015 at 14:49, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 19 January 2015 13:37:33 Gabriel Fernandez wrote:
> >> On 17 December 2014 at 23:14, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Wednesday 17 December 2014 11:34:44 Gabriel FERNANDEZ wrote:
> >> > > +/*
> >> > > + * On ARM platforms, we actually get a bus error returned when the PCIe
> >> > IP
> >> > > + * returns a UR or CRS instead of an OK.
> >> > > + */
> >> > > +static int st_pcie_abort_
> >> >
> >> > handler(unsigned long addr, unsigned int fsr,
> >> > > + struct pt_regs *regs)
> >> > > +{
> >> > > + return 0;
> >> > > +}
> >> >
> >> > You should check that it's actually PCI that caused the abort. Don't
> >> > just ignore a hard error condition.
> >> >
> >> > Usually there are registers in the PCI core that let you identify what
> >> > happened.
> >> >
> >>
> >>
> >> We return 0 because abort handler is not activated during boot.
> >>
> >
> > Can you just remove the handler then? We should never have exception
> > handlers that unconditionally return 0.
> >
>
> Ah sorry, we need the handler because we can received aborts from
> user-land after the boot.
>
> I have 2 solutions, the first to simplify we can only return 0.
> The second is to manage handler during boot. Then i need for that a
> new patch from Fabrice
> https://lkml.org/lkml/2014/2/7/631
I still don't get it. What is causing the abort? Is that something
user space does, or is it just a condition that gets stuck the pcie
device after probing that gets delivered once as soon as the aborts
are enabled?
> >>
> >> msi_data is a virtual address, it's obtained through a __get_free_pages()
> >> function in dw_pcie_msi_init() procedure.
> >
> > I guess you need dma_map_single() then, or use dma_alloc_coherent instead
> > of __get_free_pages(). There is no guarantee that the page you allocate
> > there is actually visible to the PCI host at the same address that the CPU
> > uses, so you need to map from a CPU address to a DMA address that the PCI
> > host bridge uses.
> >
> > Arnd
>
> This is only to check the msi magic address given to ip, we never read
> or write in this area.
> this code is only a check
But doesn't the hardware access the pointer?
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Gabriel Fernandez
<gabriel.fernandez-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Gabriel FERNANDEZ
<gabriel.fernandez-qxv4g6HH51o@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Srinivas Kandagatla
<srinivas.kandagatla-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Maxime Coquelin <maxime.coquelin-qxv4g6HH51o@public.gmane.org>,
Patrice Chotard <patrice.chotard-qxv4g6HH51o@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Mohit Kumar <mohit.kumar-qxv4g6HH51o@public.gmane.org>,
Jingoo Han <jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>,
Viresh Kumar
<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Minghuan Lian
<Minghuan.Lian-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Magnus Damm <damm-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Tanmay
Subject: Re: [PATCH 3/5] PCI: st: Provide support for the sti PCIe controller
Date: Wed, 21 Jan 2015 20:35:41 +0100 [thread overview]
Message-ID: <6574269.bTBzFhcnBx@wuerfel> (raw)
In-Reply-To: <CAG374jCRByNZuuYxi5+-mKvV7p5-tCf2G+8mTYfzU4rRV4yfYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wednesday 21 January 2015 16:47:36 Gabriel Fernandez wrote:
> On 19 January 2015 at 14:49, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Monday 19 January 2015 13:37:33 Gabriel Fernandez wrote:
> >> On 17 December 2014 at 23:14, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >> > On Wednesday 17 December 2014 11:34:44 Gabriel FERNANDEZ wrote:
> >> > > +/*
> >> > > + * On ARM platforms, we actually get a bus error returned when the PCIe
> >> > IP
> >> > > + * returns a UR or CRS instead of an OK.
> >> > > + */
> >> > > +static int st_pcie_abort_
> >> >
> >> > handler(unsigned long addr, unsigned int fsr,
> >> > > + struct pt_regs *regs)
> >> > > +{
> >> > > + return 0;
> >> > > +}
> >> >
> >> > You should check that it's actually PCI that caused the abort. Don't
> >> > just ignore a hard error condition.
> >> >
> >> > Usually there are registers in the PCI core that let you identify what
> >> > happened.
> >> >
> >>
> >>
> >> We return 0 because abort handler is not activated during boot.
> >>
> >
> > Can you just remove the handler then? We should never have exception
> > handlers that unconditionally return 0.
> >
>
> Ah sorry, we need the handler because we can received aborts from
> user-land after the boot.
>
> I have 2 solutions, the first to simplify we can only return 0.
> The second is to manage handler during boot. Then i need for that a
> new patch from Fabrice
> https://lkml.org/lkml/2014/2/7/631
I still don't get it. What is causing the abort? Is that something
user space does, or is it just a condition that gets stuck the pcie
device after probing that gets delivered once as soon as the aborts
are enabled?
> >>
> >> msi_data is a virtual address, it's obtained through a __get_free_pages()
> >> function in dw_pcie_msi_init() procedure.
> >
> > I guess you need dma_map_single() then, or use dma_alloc_coherent instead
> > of __get_free_pages(). There is no guarantee that the page you allocate
> > there is actually visible to the PCI host at the same address that the CPU
> > uses, so you need to map from a CPU address to a DMA address that the PCI
> > host bridge uses.
> >
> > Arnd
>
> This is only to check the msi magic address given to ip, we never read
> or write in this area.
> this code is only a check
But doesn't the hardware access the pointer?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-01-21 19:36 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 10:34 [PATCH 0/5] PCI: st: provide support for dw pcie Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` [PATCH 1/5] ARM: STi: Kconfig update for PCIe support Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` [PATCH 2/5] PCI: st: Add Device Tree bindings for sti pcie Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 22:01 ` Arnd Bergmann
2014-12-17 22:01 ` Arnd Bergmann
2014-12-17 22:01 ` Arnd Bergmann
2015-01-19 12:36 ` Gabriel Fernandez
2015-01-19 13:04 ` Gabriel Fernandez
2015-01-19 13:04 ` Gabriel Fernandez
2015-01-19 13:04 ` Gabriel Fernandez
2014-12-22 4:45 ` Pratyush Anand
2014-12-22 4:45 ` Pratyush Anand
2014-12-22 4:45 ` Pratyush Anand
2014-12-17 10:34 ` [PATCH 3/5] PCI: st: Provide support for the sti PCIe controller Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 22:14 ` Arnd Bergmann
2014-12-17 22:14 ` Arnd Bergmann
2014-12-17 22:14 ` Arnd Bergmann
2015-01-19 12:37 ` Gabriel Fernandez
2015-01-19 13:49 ` Arnd Bergmann
2015-01-19 13:49 ` Arnd Bergmann
2015-01-19 13:49 ` Arnd Bergmann
2015-01-21 15:47 ` Gabriel Fernandez
2015-01-21 15:47 ` Gabriel Fernandez
2015-01-21 15:47 ` Gabriel Fernandez
2015-01-21 19:35 ` Arnd Bergmann [this message]
2015-01-21 19:35 ` Arnd Bergmann
2015-01-21 19:35 ` Arnd Bergmann
2015-01-21 19:59 ` Lucas Stach
2015-01-21 19:59 ` Lucas Stach
2015-01-21 19:59 ` Lucas Stach
2015-01-19 13:08 ` Gabriel Fernandez
2015-01-19 13:08 ` Gabriel Fernandez
2015-01-19 13:08 ` Gabriel Fernandez
2014-12-18 6:03 ` Jingoo Han
2014-12-18 6:03 ` Jingoo Han
2014-12-18 6:03 ` Jingoo Han
2015-01-19 12:38 ` Gabriel Fernandez
2015-01-19 13:06 ` Gabriel Fernandez
2015-01-19 13:06 ` Gabriel Fernandez
2015-01-19 13:06 ` Gabriel Fernandez
2014-12-22 5:12 ` Pratyush Anand
2014-12-22 5:12 ` Pratyush Anand
2014-12-22 5:12 ` Pratyush Anand
2015-01-12 18:43 ` Bjorn Helgaas
2015-01-12 18:43 ` Bjorn Helgaas
2015-01-12 18:43 ` Bjorn Helgaas
2015-01-21 15:32 ` Gabriel Fernandez
2015-01-21 15:32 ` Gabriel Fernandez
2015-01-21 15:32 ` Gabriel Fernandez
2014-12-17 10:34 ` [PATCH 4/5] PCI: designware: Add setup bus-related to pcie_host_ops Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 22:16 ` Arnd Bergmann
2014-12-17 22:16 ` Arnd Bergmann
2014-12-17 22:16 ` Arnd Bergmann
2014-12-18 4:58 ` Jingoo Han
2014-12-18 4:58 ` Jingoo Han
2014-12-18 4:58 ` Jingoo Han
2015-01-19 12:38 ` Gabriel Fernandez
2015-01-19 13:54 ` Arnd Bergmann
2015-01-19 13:54 ` Arnd Bergmann
2015-01-19 13:54 ` Arnd Bergmann
2015-01-19 15:46 ` Lorenzo Pieralisi
2015-01-19 15:46 ` Lorenzo Pieralisi
2015-01-19 15:46 ` Lorenzo Pieralisi
2015-01-19 13:09 ` Gabriel Fernandez
2015-01-19 13:09 ` Gabriel Fernandez
2015-01-19 13:09 ` Gabriel Fernandez
2014-12-17 10:34 ` [PATCH 5/5] PCI: st: disable IO support Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 10:34 ` Gabriel FERNANDEZ
2014-12-17 14:01 ` One Thousand Gnomes
2014-12-17 14:01 ` One Thousand Gnomes
2014-12-17 14:01 ` One Thousand Gnomes
2015-01-21 15:49 ` Gabriel Fernandez
2015-01-21 15:49 ` Gabriel Fernandez
2015-01-21 15:49 ` Gabriel Fernandez
-- strict thread matches above, loose matches on Subject: below --
2015-04-10 7:38 [PATCH 0/5] PCI: st: provide support for dw pcie Gabriel FERNANDEZ
2015-04-10 7:38 ` [PATCH 3/5] PCI: st: Provide support for the sti PCIe controller Gabriel FERNANDEZ
2015-04-10 7:38 ` Gabriel FERNANDEZ
2015-04-10 7:38 ` Gabriel FERNANDEZ
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=6574269.bTBzFhcnBx@wuerfel \
--to=arnd@arndb.de \
--cc=Liviu.Dudau@arm.com \
--cc=Minghuan.Lian@freescale.com \
--cc=andrew@lunn.ch \
--cc=bhelgaas@google.com \
--cc=damm@opensource.se \
--cc=devicetree@vger.kernel.org \
--cc=fabrice.gasnier@st.com \
--cc=gabriel.fernandez@linaro.org \
--cc=gabriel.fernandez@st.com \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jg1.han@samsung.com \
--cc=kernel@stlinux.com \
--cc=kishon@ti.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m-karicheri2@ti.com \
--cc=mark.rutland@arm.com \
--cc=maxime.coquelin@st.com \
--cc=mohit.kumar@st.com \
--cc=patrice.chotard@st.com \
--cc=pawel.moll@arm.com \
--cc=pratyush.anand@st.com \
--cc=robh+dt@kernel.org \
--cc=sachin.kamat@samsung.com \
--cc=srinivas.kandagatla@gmail.com \
--cc=sthokal@xilinx.com \
--cc=tinamdar@apm.com \
--cc=treding@nvidia.com \
--cc=viresh.kumar@linaro.org \
--cc=will.deacon@arm.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.