All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org,
	Wenrui Li <wenrui.li@rock-chips.com>,
	Jeffy Chen <jeffy.chen@rock-chips.com>
Subject: Re: [PATCH 1/3] PCI: rockchip: split out rockchip_cfg_atu
Date: Tue, 22 Nov 2016 18:29:06 -0800	[thread overview]
Message-ID: <20161123022905.GA122654@google.com> (raw)
In-Reply-To: <30d37e0c-73df-5bae-f489-3d9b56cc7b02@rock-chips.com>

On Wed, Nov 23, 2016 at 10:15:16AM +0800, Shawn Lin wrote:
> 在 2016/11/23 9:59, Brian Norris 写道:
> >On Wed, Nov 23, 2016 at 09:19:11AM +0800, Shawn Lin wrote:
> >>diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> >>index b55037a..19399fc 100644
> >>--- a/drivers/pci/host/pcie-rockchip.c
> >>+++ b/drivers/pci/host/pcie-rockchip.c

...

> >>+	rockchip->msg_region = ioremap(rockchip->mem_bus_addr +
> >>+				       ((reg_no - 1) << 20), SZ_1M);
> >
> >(And here.)
> >
> >ioremap() can fail; check for NULL.
> >
> 
> Sure.
> 
> >Also, when you start reusing rockchip_cfg_atu() in patch 3, you'll be
> >leaking virtual address space, as you'll keep remapping this every time.
> 
> How about just check if rockchip->msg_region was already mapped?
> Otherwise we don't remap it again when calling rockchip_cfg_atu.

That'd work, even if it's a little awkward. That's basically one of my
suggestions below.

> >You should straighten that out. Either some kind of check for
> >'if (!rockchip->msg_region)', or just do the map/unmap where it's
> >actually used (in patch 3).
> 
> Should we really need to unmap it? As this driver won't be a module and
> I think it's okay to keep the rockchip->msg_region always.

No, I guess we don't really need to unmap it. I just meant, you could
map/unmap every time you use it, or make sure you just map it once (and
only once).

Also (if it helps), you could use devm_ioremap(), in case you ever do
make it removable.

Brian

  reply	other threads:[~2016-11-23  2:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23  1:19 [PATCH 1/3] PCI: rockchip: split out rockchip_cfg_atu Shawn Lin
2016-11-23  1:19 ` [PATCH 2/3] PCI: rockchip: move the deassert of pm/aclk/pclk after phy_init Shawn Lin
2016-11-23  1:19 ` [PATCH 3/3] PCI: rockchip: Add system PM support Shawn Lin
2016-11-23  2:08   ` Brian Norris
2016-11-23  2:08     ` Brian Norris
2016-11-23  2:39     ` Shawn Lin
2016-11-23  2:45       ` Brian Norris
2016-11-23  2:51         ` Shawn Lin
2016-11-23  4:56           ` Brian Norris
2016-11-23  1:59 ` [PATCH 1/3] PCI: rockchip: split out rockchip_cfg_atu Brian Norris
2016-11-23  2:15   ` Shawn Lin
2016-11-23  2:29     ` Brian Norris [this message]
2016-11-23  2:33       ` Shawn Lin

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=20161123022905.GA122654@google.com \
    --to=briannorris@chromium.org \
    --cc=bhelgaas@google.com \
    --cc=jeffy.chen@rock-chips.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=wenrui.li@rock-chips.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.