From: Bjorn Helgaas <helgaas@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>,
arnd@arndb.de, will.deacon@arm.com, catalin.marinas@arm.com,
rafael@kernel.org, hanjun.guo@linaro.org, okaya@codeaurora.org,
jchandra@broadcom.com, cov@codeaurora.org, dhdang@apm.com,
ard.biesheuvel@linaro.org, robert.richter@caviumnetworks.com,
mw@semihalf.com, Liviu.Dudau@arm.com, ddaney@caviumnetworks.com,
wangyijing@huawei.com, msalter@redhat.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linaro-acpi@lists.linaro.org, jcm@redhat.com,
andrea.gallo@linaro.org, jeremy.linton@arm.com,
liudongdong3@huawei.com, gabriele.paoloni@huawei.com,
jhugo@codeaurora.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V5 1/5] PCI: Embed pci_ecam_ops in pci_config_window structure
Date: Sun, 4 Sep 2016 21:22:03 -0500 [thread overview]
Message-ID: <20160905022203.GB30488@localhost> (raw)
In-Reply-To: <20160902153845.GA11234@red-moon>
On Fri, Sep 02, 2016 at 04:38:45PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Sep 01, 2016 at 01:23:45PM -0500, Bjorn Helgaas wrote:
> > On Mon, Aug 08, 2016 at 03:05:37PM +0200, Tomasz Nowicki wrote:
> > > pci_config_window keeps pointer to pci_ecam_ops and every time
> > > we want to deallocate pci_config_window (pci_ecam_free()) we need to make
> > > sure to free pci_ecam_ops in case it was dynamically allocated prior to
> > > pci_ecam_create() call.
> >
> > I think this is a theoretical problem, right? All the current callers
> > pass a pointer to a static pci_ecam_ops struct that does not need to
> > be deallocated.
> >
> > I see that the next patch uses a pci_ecam_ops struct on the stack,
>
> I asked Tomasz why we need to have pci_ecam_ops on the stack in the
> first place since I do not think it is needed, or nicer (actually I
> think it is not nice at all, what's the problem in making it static ?).
If it's useful to copy the struct instead of saving the pointer, that's
fine. I just want the changelog to match the diff.
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH V5 1/5] PCI: Embed pci_ecam_ops in pci_config_window structure
Date: Sun, 4 Sep 2016 21:22:03 -0500 [thread overview]
Message-ID: <20160905022203.GB30488@localhost> (raw)
In-Reply-To: <20160902153845.GA11234@red-moon>
On Fri, Sep 02, 2016 at 04:38:45PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Sep 01, 2016 at 01:23:45PM -0500, Bjorn Helgaas wrote:
> > On Mon, Aug 08, 2016 at 03:05:37PM +0200, Tomasz Nowicki wrote:
> > > pci_config_window keeps pointer to pci_ecam_ops and every time
> > > we want to deallocate pci_config_window (pci_ecam_free()) we need to make
> > > sure to free pci_ecam_ops in case it was dynamically allocated prior to
> > > pci_ecam_create() call.
> >
> > I think this is a theoretical problem, right? All the current callers
> > pass a pointer to a static pci_ecam_ops struct that does not need to
> > be deallocated.
> >
> > I see that the next patch uses a pci_ecam_ops struct on the stack,
>
> I asked Tomasz why we need to have pci_ecam_ops on the stack in the
> first place since I do not think it is needed, or nicer (actually I
> think it is not nice at all, what's the problem in making it static ?).
If it's useful to copy the struct instead of saving the pointer, that's
fine. I just want the changelog to match the diff.
Bjorn
next prev parent reply other threads:[~2016-09-05 2:22 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 13:05 [RFC PATCH V5 0/5] ECAM quirks handling for ARM64 platforms Tomasz Nowicki
2016-08-08 13:05 ` Tomasz Nowicki
2016-08-08 13:05 ` [RFC PATCH V5 1/5] PCI: Embed pci_ecam_ops in pci_config_window structure Tomasz Nowicki
2016-08-08 13:05 ` Tomasz Nowicki
2016-09-01 18:23 ` Bjorn Helgaas
2016-09-01 18:23 ` Bjorn Helgaas
2016-09-01 18:23 ` Bjorn Helgaas
2016-09-01 18:23 ` Bjorn Helgaas
2016-09-02 15:38 ` Lorenzo Pieralisi
2016-09-02 15:38 ` Lorenzo Pieralisi
2016-09-05 2:22 ` Bjorn Helgaas [this message]
2016-09-05 2:22 ` Bjorn Helgaas
2016-08-08 13:05 ` [RFC PATCH V5 2/5] PCI/ACPI: Move ACPI ECAM mapping to generic MCFG driver Tomasz Nowicki
2016-08-08 13:05 ` Tomasz Nowicki
2016-09-05 2:22 ` Bjorn Helgaas
2016-09-05 2:22 ` Bjorn Helgaas
2016-09-06 18:04 ` Tomasz Nowicki
2016-09-06 18:04 ` Tomasz Nowicki
2016-08-08 13:05 ` [RFC PATCH V5 3/5] PCI: Check platform specific ECAM quirks Tomasz Nowicki
2016-08-08 13:05 ` Tomasz Nowicki
2016-08-08 15:34 ` Mark Salter
2016-08-08 15:34 ` Mark Salter
2016-08-09 6:10 ` Tomasz Nowicki
2016-08-09 6:10 ` Tomasz Nowicki
2016-09-05 2:25 ` Bjorn Helgaas
2016-09-05 2:25 ` Bjorn Helgaas
2016-09-06 17:49 ` Tomasz Nowicki
2016-09-06 17:49 ` Tomasz Nowicki
2016-09-06 19:14 ` Arnd Bergmann
2016-09-06 19:14 ` Arnd Bergmann
2016-09-05 2:59 ` Bjorn Helgaas
2016-09-05 2:59 ` Bjorn Helgaas
2016-09-05 2:59 ` Bjorn Helgaas
2016-08-08 13:05 ` [RFC PATCH V5 4/5] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller Tomasz Nowicki
2016-08-08 13:05 ` Tomasz Nowicki
2016-09-05 2:27 ` Bjorn Helgaas
2016-09-05 2:27 ` Bjorn Helgaas
2016-08-08 13:05 ` [RFC PATCH V5 5/5] PCI: thunder-pem: Support quirky configuration space access " Tomasz Nowicki
2016-08-08 13:05 ` Tomasz Nowicki
2016-08-09 11:04 ` Robert Richter
2016-08-09 11:04 ` Robert Richter
2016-08-09 11:04 ` Robert Richter
2016-08-09 11:04 ` Robert Richter
2016-09-05 2:34 ` Bjorn Helgaas
2016-09-05 2:34 ` Bjorn Helgaas
2016-09-06 18:01 ` Tomasz Nowicki
2016-09-06 18:01 ` Tomasz Nowicki
2016-08-08 15:13 ` [RFC PATCH V5 0/5] ECAM quirks handling for ARM64 platforms Graeme Gregory
2016-08-08 15:13 ` Graeme Gregory
2016-08-08 19:44 ` Mark Salter
2016-08-08 19:44 ` Mark Salter
2016-08-09 9:20 ` Dongdong Liu
2016-08-09 9:20 ` Dongdong Liu
2016-08-09 9:20 ` Dongdong Liu
2016-08-09 10:29 ` Robert Richter
2016-08-09 10:29 ` Robert Richter
2016-08-09 10:29 ` Robert Richter
2016-08-09 10:29 ` Robert Richter
2016-08-09 14:20 ` Duc Dang
2016-08-09 14:20 ` Duc Dang
2016-08-09 14:20 ` Duc Dang
-- strict thread matches above, loose matches on Subject: below --
2016-08-08 12:56 Tomasz Nowicki
2016-08-08 12:56 ` [RFC PATCH V5 1/5] PCI: Embed pci_ecam_ops in pci_config_window structure Tomasz Nowicki
2016-08-08 12:56 ` Tomasz Nowicki
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=20160905022203.GB30488@localhost \
--to=helgaas@kernel.org \
--cc=Liviu.Dudau@arm.com \
--cc=andrea.gallo@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=cov@codeaurora.org \
--cc=ddaney@caviumnetworks.com \
--cc=dhdang@apm.com \
--cc=gabriele.paoloni@huawei.com \
--cc=hanjun.guo@linaro.org \
--cc=jchandra@broadcom.com \
--cc=jcm@redhat.com \
--cc=jeremy.linton@arm.com \
--cc=jhugo@codeaurora.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liudongdong3@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=msalter@redhat.com \
--cc=mw@semihalf.com \
--cc=okaya@codeaurora.org \
--cc=rafael@kernel.org \
--cc=robert.richter@caviumnetworks.com \
--cc=tn@semihalf.com \
--cc=wangyijing@huawei.com \
--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.