All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yijing Wang <wangyijing@huawei.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Huang Ying <ying.huang@intel.com>,
	David Bulkow <David.Bulkow@stratus.com>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jiang Liu <jiang.liu@huawei.com>
Subject: Re: [PATCH] PCI: Remove duplicate pci_disable_device for pcie port
Date: Fri, 26 Apr 2013 17:41:04 +0800	[thread overview]
Message-ID: <517A4BB0.30608@huawei.com> (raw)
In-Reply-To: <CAE9FiQXOQJRxqAW4q8G1OsiHAgFqz8=oD6-f-gvizSL0fR60hQ@mail.gmail.com>

On 2013/4/26 14:20, Yinghai Lu wrote:
> On Thu, Apr 25, 2013 at 9:02 PM, Yijing Wang <wangyijing@huawei.com> wrote:
>> Hi Yinghai,
>>    We should not remove this additional pci_disable_device().
>> Because we enable pcie port device twice before. The first is pci_enable_brides(),
>> in x86, it was called in pci_assign_unassigned_resources(). The second in pcie_port_device_register().
>> So we should call pci_disable_device() twice for pci_dev->enable_cnt balance.
>>
>> But there is still a problem here. If we unbind a pcie port device pcie port driver, we can not
>> use its child devices again, because this pcie port device was disabled absolutely.
>>
>> So I think we should move the second pci_disable_device() to remove.c.
>>
>> I sent this patch to Bjorn and following is Bjorn reply
>> "And it's not clear to me whether unbinding the
>> pcie port driver should disable the bridge at all.  I think one could
>> argue that the bridge should remain functional even if the driver is
>> unloaded, because the PCI core *enables* the bridge even if the driver
>> is never loaded."
>>
>> Yinghai, how do you think about this issue?
> 

Hi Yinghai,
   Thanks for your comment!
We enable_bridges in PCI core code, so I think we should disable device in remove.c(PCI core level),
another reason is call second pci_disable_device() in pci_stop_bus_device() is safe, because all child device
has been stopped(unbind driver already).

> 1. we always enable bridges after assign unassigned resource for boot path
> and hotplug path.
> we should never call disable for that.

I agree "we should never call second disable" unless we stop this sub pci-tree().

Maybe the attached patch last letter is not safe enough, should wait pci bridge complete
to stop itself, then call the second pci_disable_device().

> 
> 2. driver should be keep enable/disable during probe/remove

I agree, use enable/disable balance is better.

> 
> looks like we need to rethink pci enable bridge.
> 
> if we want to enable one pci device, we should go up  to enable all bridges till
> root.

Yes, now we enable pci bridges from root to end. like in pci_assign_unassigned_resources().

> 
> let if we disable one pci device, we need to go up to disable bridge if its all
> pci device children get disabled.

Yes, This is what I think too. It seems like we only can do this in remove.c

> 
> if there is pci driver is bound with bridge device, those
> disable/enable bridge should be skipped.

Hmm, currently system achieve this by checking pci_dev->enable_cnt.

> 
> Thanks
> 
> Yinghai
> 
> .
> 


-- 
Thanks!
Yijing


  reply	other threads:[~2013-04-26  9:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5AA430FFE4486C448003201AC83BC85E01F83F0D@EXHQ.corp.stratus.com>
2013-04-15 18:26 ` USB PCI quirk issue Sarah Sharp
2013-04-15 20:41   ` Yinghai Lu
2013-04-16 20:17     ` Bulkow, David
     [not found]       ` <5AA430FFE4486C448003201AC83BC85E01F83F13@EXHQ.corp.stratus.com>
2013-04-24 17:08         ` Yinghai Lu
2013-04-24 18:32           ` Bulkow, David
2013-04-26  1:47             ` [PATCH] PCI: Remove duplicate pci_disable_device for pcie port Yinghai Lu
2013-04-26  4:02               ` Yijing Wang
2013-04-26  6:20                 ` Yinghai Lu
2013-04-26  9:41                   ` Yijing Wang [this message]
2013-04-26  1:47       ` [PATCH] PCI: move down pci_fixup_final for hotplug path Yinghai Lu
2013-05-07 21:32         ` Bjorn Helgaas
2013-05-07 21:38           ` Bjorn Helgaas
2013-05-07 22:36             ` Yinghai Lu

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=517A4BB0.30608@huawei.com \
    --to=wangyijing@huawei.com \
    --cc=David.Bulkow@stratus.com \
    --cc=bhelgaas@google.com \
    --cc=jiang.liu@huawei.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=ying.huang@intel.com \
    --cc=yinghai@kernel.org \
    /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.