[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZU0qYBfFzsF3e8S9@slm.duckdns.org>
Date: Thu, 9 Nov 2023 08:52:16 -1000
From: Tejun Heo <tj@...nel.org>
To: Philipp Stanner <pstanner@...hat.com>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
Tejun Heo <htejun@...il.com>, dakr@...hat.com,
Bjorn Helgaas <bhelgaas@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ben Dooks <ben.dooks@...ethink.co.uk>, jeff@...zik.org,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Implementation details of PCI Managed (devres) Functions
Hello, Philipp.
On Wed, Nov 08, 2023 at 10:02:29PM +0100, Philipp Stanner wrote:
...
> That struct keeps track of the requested BARs. That's why there can
> only be one mapping per BAR, because that table is statically allocated
> and is indexed with the bar-number.
> pcim_iomap_table() now only ever returns the table with the pointers to
> the BARs. Adding tables to that struct that keep track of which
> mappings exist in which bars would be a bit tricky and require probably
> an API change for everyone who currently uses pcim_iomap_table(), and
> that's more than 100 C-files.
>
> So, it seems that a concern back in 2007 was to keep things simple and
> skip the more complex data structures necessary for keeping track of
> the various mappings within a bar.
It was so long ago that I don't remember much but I do remember taking a
shortcut there for convenience / simplicity. I'm sure it's already clear but
there's no deeper reason, so if you wanna put in the work to make it
consistent, that'd be great.
Thanks.
--
tejun
Powered by blists - more mailing lists