On Mon, 2024-10-14 at 10:15 +0200, Bartosz Golaszewski wrote:
> On Mon, Oct 14, 2024 at 10:08 AM Philipp Stanner
> <pstanner@xxxxxxxxxx> wrote:
> >
> > On Mon, 2024-10-14 at 09:59 +0200, Bartosz Golaszewski wrote:
> > > On Mon, Oct 14, 2024 at 9:53 AM Philipp Stanner
> > > <pstanner@xxxxxxxxxx>
> > > wrote:
> > > >
> > > > pcim_iomap_regions() and pcim_iomap_table() have been
> > > > deprecated by
> > > > the
> > > > PCI subsystem in commit e354bb84a4c1 ("PCI: Deprecate
> > > > pcim_iomap_table(), pcim_iomap_regions_request_all()").
> > > >
> > > > Replace those functions with calls to pcim_iomap_region().
> > > >
> > > > Signed-off-by: Philipp Stanner <pstanner@xxxxxxxxxx>
> > > > Reviewed-by: Andy Shevchenko <andy@xxxxxxxxxx>
> > > > Acked-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > > > ---
> > >
> > > This is part of a larger series so I acked it previously but at
> > > second
> > > glance it doesn't look like it depends on anything that comes
> > > before?
> > > Should it have been sent separately to the GPIO tree? Should I
> > > pick
> > > it
> > > up independently?
> >
> > Thx for the offer, but it depends on pcim_iounmap_region(), which
> > only
> > becomes a public symbol through patch No.1 of this series :)
> >
>
> Then a hint: to make it more obvious to maintainers, I'd change the
> commit title for patch 1 to say explicitly it makes this function
> public. In fact: I'd split it and the deprecation into two separate
> patches.
Yeah, good idea. The maintainer could squash then if two atomic patches
are deemed undesirable.
Noted.
Thank you!
P.
>
> Bart
>
