From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Grant Grundler <grundler@parisc-linux.org>,
Matthew Wilcox <matthew@wil.cx>,
linux-pci@atrey.karlin.mff.cuni.cz,
linux-pm <linux-pm@lists.osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars
Date: Wed, 6 Jul 2005 08:46:19 +0100 [thread overview]
Message-ID: <20050706084619.A8976@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20050706033454.A706@den.park.msu.ru>; from ink@jurassic.park.msu.ru on Wed, Jul 06, 2005 at 03:34:54AM +0400
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]
On Wed, Jul 06, 2005 at 03:34:54AM +0400, Ivan Kokshaysky wrote:
> On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
> > On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
> > > 64-bit BARs work fine on 64-bit machines. I'm ambivalent whether we
> > > ought to support 64-bit BARs on 32-bit machines.
> >
> > This only occurs because the problematical functions (eg,
> > pci_update_resource) probably aren't called on 64-bit machines - if
> > they were, they'd zero the upper 32-bits. Maybe 64-bit machines are
> > happy with that anyway?
>
> Why problematical? It's just the way how linux has always dealt with
> 64-bit BARs - put everything below 4G in the bus address space, on *any*
> architecture. I'd be quite surprised if some firmware doesn't do the same
> thing - so far I haven't heard any complaints.
If this is so, Grant's concern about programming the top half of 64-bit
resources with zero isn't appropriate. However, he did raise this as
an issue...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matthew Wilcox <matthew@wil.cx>,
Grant Grundler <grundler@parisc-linux.org>,
"John W. Linville" <linville@tuxdriver.com>,
linux-pci@atrey.karlin.mff.cuni.cz,
linux-pm <linux-pm@lists.osdl.org>,
linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>,
Adam Belay <ambx1@neo.rr.com>
Subject: Re: [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars
Date: Wed, 6 Jul 2005 08:46:19 +0100 [thread overview]
Message-ID: <20050706084619.A8976@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20050706033454.A706@den.park.msu.ru>; from ink@jurassic.park.msu.ru on Wed, Jul 06, 2005 at 03:34:54AM +0400
On Wed, Jul 06, 2005 at 03:34:54AM +0400, Ivan Kokshaysky wrote:
> On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
> > On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
> > > 64-bit BARs work fine on 64-bit machines. I'm ambivalent whether we
> > > ought to support 64-bit BARs on 32-bit machines.
> >
> > This only occurs because the problematical functions (eg,
> > pci_update_resource) probably aren't called on 64-bit machines - if
> > they were, they'd zero the upper 32-bits. Maybe 64-bit machines are
> > happy with that anyway?
>
> Why problematical? It's just the way how linux has always dealt with
> 64-bit BARs - put everything below 4G in the bus address space, on *any*
> architecture. I'd be quite surprised if some firmware doesn't do the same
> thing - so far I haven't heard any complaints.
If this is so, Grant's concern about programming the top half of 64-bit
resources with zero isn't appropriate. However, he did raise this as
an issue...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2005-07-06 7:46 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-23 19:14 [RFC] firmware leaves device in D3hot at boot John W. Linville
2005-06-23 19:14 ` John W. Linville
2005-06-24 2:28 ` John W. Linville
2005-06-24 2:28 ` John W. Linville
2005-06-30 17:10 ` Greg KH
2005-06-30 17:10 ` Greg KH
2005-07-01 1:41 ` John W. Linville
2005-07-01 1:41 ` John W. Linville
2005-07-01 2:26 ` [patch 2.6.12] pci: restore BAR values in pci_enable_device John W. Linville
2005-07-01 2:26 ` John W. Linville
2005-07-01 2:26 ` [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars John W. Linville
2005-07-01 2:26 ` John W. Linville
2005-07-02 7:29 ` Grant Grundler
2005-07-02 7:29 ` Grant Grundler
2005-07-02 8:09 ` Russell King
2005-07-02 8:09 ` Russell King
2005-07-05 20:05 ` Matthew Wilcox
2005-07-05 20:05 ` Matthew Wilcox
2005-07-05 21:46 ` Russell King
2005-07-05 21:46 ` Russell King
2005-07-05 23:34 ` Ivan Kokshaysky
2005-07-05 23:34 ` Ivan Kokshaysky
2005-07-06 7:46 ` Russell King [this message]
2005-07-06 7:46 ` Russell King
2005-07-08 0:57 ` John W. Linville
2005-07-08 0:57 ` John W. Linville
2005-07-08 0:59 ` [patch 2.6.13-rc2] pci: restore BAR values in pci_set_power_state for D3hot->D0 John W. Linville
2005-07-08 0:59 ` John W. Linville
2005-07-08 3:43 ` [linux-pm] " david-b
2005-07-08 3:43 ` david-b
2005-07-08 12:37 ` John W. Linville
2005-07-08 12:37 ` [linux-pm] " John W. Linville
2005-07-08 3:11 ` [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars David S. Miller
2005-07-08 3:11 ` David S. Miller
2005-07-08 5:51 ` Ivan Kokshaysky
2005-07-08 5:51 ` Ivan Kokshaysky
2005-07-08 6:35 ` David S. Miller
2005-07-08 6:35 ` David S. Miller
2005-07-08 7:03 ` Ivan Kokshaysky
2005-07-08 7:03 ` Ivan Kokshaysky
2005-07-08 7:33 ` David S. Miller
2005-07-08 7:33 ` David S. Miller
2005-07-08 8:20 ` Ivan Kokshaysky
2005-07-08 8:20 ` Ivan Kokshaysky
2005-07-08 18:34 ` [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0 John W. Linville
2005-07-08 18:34 ` John W. Linville
2005-07-08 19:08 ` David S. Miller
2005-07-08 19:08 ` David S. Miller
2005-07-10 17:53 ` Ivan Kokshaysky
2005-07-10 17:53 ` Ivan Kokshaysky
2005-07-11 12:48 ` Lennert Buytenhek
2005-07-11 12:48 ` Lennert Buytenhek
2005-07-11 13:15 ` John W. Linville
2005-07-11 13:15 ` John W. Linville
2005-07-11 13:19 ` [patch 2.6.13-rc2] PCI: Add symbol exports for pci_restore_bars John W. Linville
2005-07-11 13:19 ` John W. Linville
2005-07-11 17:18 ` Greg KH
2005-07-11 17:36 ` John W. Linville
2005-07-11 17:36 ` John W. Linville
2005-07-11 17:38 ` [patch 2.6.13-rc2] PCI: Add GPL symbol export " John W. Linville
2005-07-11 17:38 ` John W. Linville
2005-07-12 2:28 ` [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0 Adam Belay
2005-07-12 2:28 ` Adam Belay
2005-07-13 17:34 ` John W. Linville
2005-07-13 17:34 ` John W. Linville
2005-07-26 23:49 ` Greg KH
2005-07-26 23:49 ` Greg KH
2005-07-27 1:36 ` John W. Linville
2005-07-27 1:36 ` John W. Linville
2005-07-27 14:12 ` John W. Linville
2005-07-27 14:12 ` John W. Linville
2005-07-27 14:19 ` [patch 2.6.13-rc3] pci: restore BAR values after D3hot->D0 for devices that need it John W. Linville
2005-07-27 14:19 ` John W. Linville
2005-07-31 19:36 ` Ralf Baechle
2005-07-31 19:36 ` Ralf Baechle
2005-08-02 17:31 ` Greg KH
2005-08-02 17:31 ` Greg KH
2005-08-02 16:41 ` Jesse Brandeburg
2005-09-14 13:52 ` [patch 2.6.14-rc1] pci: only call pci_restore_bars at boot John W. Linville
2005-09-14 13:52 ` John W. Linville
2005-09-14 15:08 ` Jeff Garzik
2005-09-14 15:08 ` Jeff Garzik
2005-09-14 16:26 ` David S. Miller
2005-09-14 16:47 ` John W. Linville
2005-09-14 16:47 ` John W. Linville
2005-09-14 18:22 ` Ivan Kokshaysky
2005-09-14 18:22 ` Ivan Kokshaysky
2005-07-05 17:46 ` [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars John W. Linville
2005-07-05 17:46 ` John W. Linville
2005-07-18 12:17 ` Grant Grundler
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=20050706084619.A8976@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=grundler@parisc-linux.org \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linux-pm@lists.osdl.org \
--cc=matthew@wil.cx \
/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.