From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Alex Chiang <achiang@hp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 0/12] pci: update pci bridge resources
Date: Sun, 20 Dec 2009 17:42:51 -0800 [thread overview]
Message-ID: <4B2ED29B.7060108@kernel.org> (raw)
In-Reply-To: <1261352672.26429.41.camel@dc7800.home>
Bjorn Helgaas wrote:
> On Fri, 2009-12-18 at 12:54 -0800, Yinghai Lu wrote:
>> this patche set is trying to update pci bridge BAR when that BAR is big enough.
>>
>> default it is disabled.
>>
>> could use pci=try=2 to enable it.
>
> Thanks for posting this as a nice new series. It was getting hard to
> figure out what went where.
>
> I think you mean "when the BAR is *not* big enough." And strictly
> speaking, I think you're concerned with the bridge *window*, which isn't
> actually a bridge BAR.
in PCI bridge to bridge spec 1.1, page 38, 3.2.5.1 still call them bridge "Base Address Registers"
so should be fine we call them Bridge BAR,
and we still have device BAR...
>
> I don't like the new "pci=try=2" parameter. Linux should be smart
> enough to do the right thing without requiring the user to do something
> special. Using a parameter to enable the new code makes it feel like
> "here's some new functionality, but I'm not sure it's safe enough for
> everybody to use, so try this parameter if you need it."
try to get the code merge at first. those code have been there for a while.
it should be good enable it by default
>
> The result is that the new code will be rarely used and poorly tested,
> yet it remains a burden to all future PCI maintainers, who will have to
> understand it and try not to break it.
>
> Can you please put the "-v2"-type comments about your development
> history in the [0/n] email? They are useful while reviewing the
> different versions, but they don't need to be in the commit logs.
actually it should be -v14.
will put back the history later.
>
> Also, some of the patches in this series have "-v2" in subject, others
> have "-v3", others have nothing. It's easier to follow development of
> the series if the version applies to the series as a whole, not to
> individual patches. The version doesn't need to be on the patch subject
> line, because that will go into the commit log, where it won't be
> relevant. Tools like stgit put it where it will be automatically
> discarded, e.g., "[PATCH -v2 x/n]"
ok. will try that on next time.
YH
next prev parent reply other threads:[~2009-12-21 1:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-18 20:54 [PATCH 0/12] pci: update pci bridge resources Yinghai Lu
2009-12-20 23:44 ` Bjorn Helgaas
2009-12-21 1:42 ` Yinghai Lu [this message]
2009-12-21 4:44 ` Bjorn Helgaas
2009-12-21 20:47 ` 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=4B2ED29B.7060108@kernel.org \
--to=yinghai@kernel.org \
--cc=achiang@hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox