diff mbox series

[01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"

Message ID 1612710687-56493-2-git-send-email-bmeng.cn@gmail.com
State Superseded
Delegated to: Priyanka Jain
Headers show
Series ppc: qemu: Convert qemu-ppce500 to driver model | expand

Commit Message

Bin Meng Feb. 7, 2021, 3:11 p.m. UTC
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.

Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
changes 'struct pci_controller'.regions from pre-allocated array of
regions to dynamically allocated, which unfortunately broken lots of
boards that still use the non-DM PCI driver.

We may update every non-DM PCI board codes to do the dynamical
allocation of PCI regions but that's a lot of work (e.g.: almost
all Freescale PowerPC boards are broken now and need to be fixed).
Let's do the easy way.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/pci/pci-uclass.c | 14 ++++++--------
 include/pci.h            |  4 +++-
 2 files changed, 9 insertions(+), 9 deletions(-)

Comments

Simon Glass Feb. 7, 2021, 3:33 p.m. UTC | #1
Hi Bin,

On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>
> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> changes 'struct pci_controller'.regions from pre-allocated array of
> regions to dynamically allocated, which unfortunately broken lots of
> boards that still use the non-DM PCI driver.
>
> We may update every non-DM PCI board codes to do the dynamical
> allocation of PCI regions but that's a lot of work (e.g.: almost
> all Freescale PowerPC boards are broken now and need to be fixed).
> Let's do the easy way.

No one has noticed since July, apparently. I think it would be better
to disable PCI on these boards, until either someone migrates them or
they are removed. The PCI deadline was about 18 months ago.

Tom, do you know the situation here?

>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/pci/pci-uclass.c | 14 ++++++--------
>  include/pci.h            |  4 +++-
>  2 files changed, 9 insertions(+), 9 deletions(-)

Regards,
Simon
Tom Rini Feb. 7, 2021, 7:33 p.m. UTC | #2
On Sun, Feb 07, 2021 at 08:33:50AM -0700, Simon Glass wrote:
> Hi Bin,
> 
> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> >
> > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > changes 'struct pci_controller'.regions from pre-allocated array of
> > regions to dynamically allocated, which unfortunately broken lots of
> > boards that still use the non-DM PCI driver.
> >
> > We may update every non-DM PCI board codes to do the dynamical
> > allocation of PCI regions but that's a lot of work (e.g.: almost
> > all Freescale PowerPC boards are broken now and need to be fixed).
> > Let's do the easy way.
> 
> No one has noticed since July, apparently. I think it would be better
> to disable PCI on these boards, until either someone migrates them or
> they are removed. The PCI deadline was about 18 months ago.
> 
> Tom, do you know the situation here?

I want to hear what Priyanka has to say, as there's been an effort a
few times on NXP's part to remove boards they don't want to maintain
anymore.

Outside of that, I do keep meaning to, but not quite finding the time
to, pick a random well-past migration deadline, make it fatal, and then
go start removing boards.  I think I'll go pick a not-PCI (as some
number of PowerPC ones will fail, and that's not as interesting until
Priyanka can chime in) one right now and see what fails there.
Bin Meng Feb. 10, 2021, 12:46 a.m. UTC | #3
Hi Simon,

On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> >
> > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > changes 'struct pci_controller'.regions from pre-allocated array of
> > regions to dynamically allocated, which unfortunately broken lots of
> > boards that still use the non-DM PCI driver.
> >
> > We may update every non-DM PCI board codes to do the dynamical
> > allocation of PCI regions but that's a lot of work (e.g.: almost
> > all Freescale PowerPC boards are broken now and need to be fixed).
> > Let's do the easy way.
>
> No one has noticed since July, apparently. I think it would be better
> to disable PCI on these boards, until either someone migrates them or
> they are removed. The PCI deadline was about 18 months ago.
>

Yep, but I'd like to keep this revert instead of just fixing the
qemu-ppce500 here, to give people a chance to test their original
non-DM version of PCI driver before the DM conversion.

Once all boards have converted to DM PCI, we can revert this revert patch again.

> Tom, do you know the situation here?
>
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> >  drivers/pci/pci-uclass.c | 14 ++++++--------
> >  include/pci.h            |  4 +++-
> >  2 files changed, 9 insertions(+), 9 deletions(-)

Regards,
Bin
Tom Rini Feb. 10, 2021, 2:36 a.m. UTC | #4
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> Hi Simon,
> 
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > regions to dynamically allocated, which unfortunately broken lots of
> > > boards that still use the non-DM PCI driver.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
> 
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
> 
> Once all boards have converted to DM PCI, we can revert this revert patch again.

I'm not quite sure as a number of PowerPC boards did convert.  I will
see what's left, on top of the series I'm currently testing that deals
with LIBATA+AHCI (and in turn kills off some PowerPC stuff).
Simon Glass Feb. 10, 2021, 5:10 a.m. UTC | #5
Hi Bin,

On Tue, 9 Feb 2021 at 17:47, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > regions to dynamically allocated, which unfortunately broken lots of
> > > boards that still use the non-DM PCI driver.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
>
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
>
> Once all boards have converted to DM PCI, we can revert this revert patch again.

I'm fine with that if Tom is. But deleting unmaintained code is always
another option!

>
> > Tom, do you know the situation here?
> >

Regards,
Simon
Stefan Roese Feb. 10, 2021, 7:13 a.m. UTC | #6
Hi Simon, Bin & Tom,

On 10.02.21 06:10, Simon Glass wrote:
> Hi Bin,
> 
> On Tue, 9 Feb 2021 at 17:47, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Simon,
>>
>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>
>>> Hi Bin,
>>>
>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>
>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>
>>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
>>>> changes 'struct pci_controller'.regions from pre-allocated array of
>>>> regions to dynamically allocated, which unfortunately broken lots of
>>>> boards that still use the non-DM PCI driver.
>>>>
>>>> We may update every non-DM PCI board codes to do the dynamical
>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>> Let's do the easy way.
>>>
>>> No one has noticed since July, apparently. I think it would be better
>>> to disable PCI on these boards, until either someone migrates them or
>>> they are removed. The PCI deadline was about 18 months ago.
>>>
>>
>> Yep, but I'd like to keep this revert instead of just fixing the
>> qemu-ppce500 here, to give people a chance to test their original
>> non-DM version of PCI driver before the DM conversion.
>>
>> Once all boards have converted to DM PCI, we can revert this revert patch again.
> 
> I'm fine with that if Tom is. But deleting unmaintained code is always
> another option!

Sorry for chiming in this late in this discussion. If we decide to
revert this patch, this will break OcteonTX/TX2 support. As we need
a higher value for the PCI regions here. Originally we just increased
MAX_PCI_REGIONS to 10. This dynamic allocation superseeded this change.
This increase might introduce size issues on other platforms though.

So please keep this in mind that with the revert the value of
MAX_PCI_REGIONS needs to get increased to 10 - at least for Octeon TX.

Thanks,
Stefan
Tom Rini Feb. 10, 2021, 2:13 p.m. UTC | #7
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> Hi Simon,
> 
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > regions to dynamically allocated, which unfortunately broken lots of
> > > boards that still use the non-DM PCI driver.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
> 
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
> 
> Once all boards have converted to DM PCI, we can revert this revert patch again.
> 
> > Tom, do you know the situation here?

So, I made a lack of DM_PCI migration be fatal and got a build done
here:
https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348

Of note, MIPS malta fails, so I had to drop that from pytest to complete
the world build.  There's then a handful of ARM boards, another large
chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
what to do here to me, other than PowerPC, as other than r2dplus
everything is missing the main "convert to DM" migration deadline as
well.
Marek Vasut Feb. 10, 2021, 2:27 p.m. UTC | #8
On 2/10/21 3:13 PM, Tom Rini wrote:
> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
>> Hi Simon,
>>
>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>
>>> Hi Bin,
>>>
>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>
>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>
>>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
>>>> changes 'struct pci_controller'.regions from pre-allocated array of
>>>> regions to dynamically allocated, which unfortunately broken lots of
>>>> boards that still use the non-DM PCI driver.
>>>>
>>>> We may update every non-DM PCI board codes to do the dynamical
>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>> Let's do the easy way.
>>>
>>> No one has noticed since July, apparently. I think it would be better
>>> to disable PCI on these boards, until either someone migrates them or
>>> they are removed. The PCI deadline was about 18 months ago.
>>>
>>
>> Yep, but I'd like to keep this revert instead of just fixing the
>> qemu-ppce500 here, to give people a chance to test their original
>> non-DM version of PCI driver before the DM conversion.
>>
>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>>
>>> Tom, do you know the situation here?
> 
> So, I made a lack of DM_PCI migration be fatal and got a build done
> here:
> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> 
> Of note, MIPS malta fails, so I had to drop that from pytest to complete
> the world build.  There's then a handful of ARM boards, another large
> chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
> what to do here to me, other than PowerPC, as other than r2dplus
> everything is missing the main "convert to DM" migration deadline as
> well.

Anything SH except r2dplus is likely dead.
Tom Rini Feb. 10, 2021, 2:48 p.m. UTC | #9
On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
> On 2/10/21 3:13 PM, Tom Rini wrote:
> > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > > 
> > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > > > 
> > > > Hi Bin,
> > > > 
> > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > 
> > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > > 
> > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > > > regions to dynamically allocated, which unfortunately broken lots of
> > > > > boards that still use the non-DM PCI driver.
> > > > > 
> > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > Let's do the easy way.
> > > > 
> > > > No one has noticed since July, apparently. I think it would be better
> > > > to disable PCI on these boards, until either someone migrates them or
> > > > they are removed. The PCI deadline was about 18 months ago.
> > > > 
> > > 
> > > Yep, but I'd like to keep this revert instead of just fixing the
> > > qemu-ppce500 here, to give people a chance to test their original
> > > non-DM version of PCI driver before the DM conversion.
> > > 
> > > Once all boards have converted to DM PCI, we can revert this revert patch again.
> > > 
> > > > Tom, do you know the situation here?
> > 
> > So, I made a lack of DM_PCI migration be fatal and got a build done
> > here:
> > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > 
> > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > the world build.  There's then a handful of ARM boards, another large
> > chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
> > what to do here to me, other than PowerPC, as other than r2dplus
> > everything is missing the main "convert to DM" migration deadline as
> > well.
> 
> Anything SH except r2dplus is likely dead.

Shall I send a series to remove most of the boards then?
Marek Vasut Feb. 10, 2021, 2:50 p.m. UTC | #10
On 2/10/21 3:48 PM, Tom Rini wrote:
> On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
>> On 2/10/21 3:13 PM, Tom Rini wrote:
>>> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>
>>>>> Hi Bin,
>>>>>
>>>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>
>>>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>>>
>>>>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
>>>>>> changes 'struct pci_controller'.regions from pre-allocated array of
>>>>>> regions to dynamically allocated, which unfortunately broken lots of
>>>>>> boards that still use the non-DM PCI driver.
>>>>>>
>>>>>> We may update every non-DM PCI board codes to do the dynamical
>>>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>>>> Let's do the easy way.
>>>>>
>>>>> No one has noticed since July, apparently. I think it would be better
>>>>> to disable PCI on these boards, until either someone migrates them or
>>>>> they are removed. The PCI deadline was about 18 months ago.
>>>>>
>>>>
>>>> Yep, but I'd like to keep this revert instead of just fixing the
>>>> qemu-ppce500 here, to give people a chance to test their original
>>>> non-DM version of PCI driver before the DM conversion.
>>>>
>>>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>>>>
>>>>> Tom, do you know the situation here?
>>>
>>> So, I made a lack of DM_PCI migration be fatal and got a build done
>>> here:
>>> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>>>
>>> Of note, MIPS malta fails, so I had to drop that from pytest to complete
>>> the world build.  There's then a handful of ARM boards, another large
>>> chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
>>> what to do here to me, other than PowerPC, as other than r2dplus
>>> everything is missing the main "convert to DM" migration deadline as
>>> well.
>>
>> Anything SH except r2dplus is likely dead.
> 
> Shall I send a series to remove most of the boards then?

You can.
Bin Meng Feb. 14, 2021, 4:53 a.m. UTC | #11
Hi Tom,

On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > >
> > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > > regions to dynamically allocated, which unfortunately broken lots of
> > > > boards that still use the non-DM PCI driver.
> > > >
> > > > We may update every non-DM PCI board codes to do the dynamical
> > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > Let's do the easy way.
> > >
> > > No one has noticed since July, apparently. I think it would be better
> > > to disable PCI on these boards, until either someone migrates them or
> > > they are removed. The PCI deadline was about 18 months ago.
> > >
> >
> > Yep, but I'd like to keep this revert instead of just fixing the
> > qemu-ppce500 here, to give people a chance to test their original
> > non-DM version of PCI driver before the DM conversion.
> >
> > Once all boards have converted to DM PCI, we can revert this revert patch again.
> >
> > > Tom, do you know the situation here?
>
> So, I made a lack of DM_PCI migration be fatal and got a build done
> here:
> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>
> Of note, MIPS malta fails, so I had to drop that from pytest to complete
> the world build.  There's then a handful of ARM boards, another large
> chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
> what to do here to me, other than PowerPC, as other than r2dplus
> everything is missing the main "convert to DM" migration deadline as
> well.

What should we do for this patch?

If the plan is to drop all boards that are not converted to DM PCI in
2021.04, I can drop this revert patch in v2.

Regards,
Bin
Tom Rini Feb. 14, 2021, 2:35 p.m. UTC | #12
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > >
> > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > > > regions to dynamically allocated, which unfortunately broken lots of
> > > > > boards that still use the non-DM PCI driver.
> > > > >
> > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > Let's do the easy way.
> > > >
> > > > No one has noticed since July, apparently. I think it would be better
> > > > to disable PCI on these boards, until either someone migrates them or
> > > > they are removed. The PCI deadline was about 18 months ago.
> > > >
> > >
> > > Yep, but I'd like to keep this revert instead of just fixing the
> > > qemu-ppce500 here, to give people a chance to test their original
> > > non-DM version of PCI driver before the DM conversion.
> > >
> > > Once all boards have converted to DM PCI, we can revert this revert patch again.
> > >
> > > > Tom, do you know the situation here?
> >
> > So, I made a lack of DM_PCI migration be fatal and got a build done
> > here:
> > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> >
> > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > the world build.  There's then a handful of ARM boards, another large
> > chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
> > what to do here to me, other than PowerPC, as other than r2dplus
> > everything is missing the main "convert to DM" migration deadline as
> > well.
> 
> What should we do for this patch?
> 
> If the plan is to drop all boards that are not converted to DM PCI in
> 2021.04, I can drop this revert patch in v2.

I've posted the patch to drop the SH boards.  Daniel, what about Malta?
I guess maybe the next steps are I need to pull in the already acked
board removal patches I've posted and then do another posting of "remove
these boards now" and see what shakes out.
Marek Vasut Feb. 14, 2021, 2:44 p.m. UTC | #13
On 2/14/21 3:35 PM, Tom Rini wrote:
> On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
>> Hi Tom,
>>
>> On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
>>>
>>> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>
>>>>> Hi Bin,
>>>>>
>>>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>
>>>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>>>
>>>>>> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
>>>>>> changes 'struct pci_controller'.regions from pre-allocated array of
>>>>>> regions to dynamically allocated, which unfortunately broken lots of
>>>>>> boards that still use the non-DM PCI driver.
>>>>>>
>>>>>> We may update every non-DM PCI board codes to do the dynamical
>>>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>>>> Let's do the easy way.
>>>>>
>>>>> No one has noticed since July, apparently. I think it would be better
>>>>> to disable PCI on these boards, until either someone migrates them or
>>>>> they are removed. The PCI deadline was about 18 months ago.
>>>>>
>>>>
>>>> Yep, but I'd like to keep this revert instead of just fixing the
>>>> qemu-ppce500 here, to give people a chance to test their original
>>>> non-DM version of PCI driver before the DM conversion.
>>>>
>>>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>>>>
>>>>> Tom, do you know the situation here?
>>>
>>> So, I made a lack of DM_PCI migration be fatal and got a build done
>>> here:
>>> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>>>
>>> Of note, MIPS malta fails, so I had to drop that from pytest to complete
>>> the world build.  There's then a handful of ARM boards, another large
>>> chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
>>> what to do here to me, other than PowerPC, as other than r2dplus
>>> everything is missing the main "convert to DM" migration deadline as
>>> well.
>>
>> What should we do for this patch?
>>
>> If the plan is to drop all boards that are not converted to DM PCI in
>> 2021.04, I can drop this revert patch in v2.
> 
> I've posted the patch to drop the SH boards.  Daniel, what about Malta?

Malta should be fixed, since it's mips used in CI.

> I guess maybe the next steps are I need to pull in the already acked
> board removal patches I've posted and then do another posting of "remove
> these boards now" and see what shakes out.

Yeah
Tom Rini Feb. 14, 2021, 2:52 p.m. UTC | #14
On Sun, Feb 14, 2021 at 03:44:26PM +0100, Marek Vasut wrote:
> On 2/14/21 3:35 PM, Tom Rini wrote:
> > On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
> > > Hi Tom,
> > > 
> > > On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
> > > > 
> > > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > > > Hi Simon,
> > > > > 
> > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > > 
> > > > > > Hi Bin,
> > > > > > 
> > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > 
> > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > > > > 
> > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > > > > > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > > > > > regions to dynamically allocated, which unfortunately broken lots of
> > > > > > > boards that still use the non-DM PCI driver.
> > > > > > > 
> > > > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > > > Let's do the easy way.
> > > > > > 
> > > > > > No one has noticed since July, apparently. I think it would be better
> > > > > > to disable PCI on these boards, until either someone migrates them or
> > > > > > they are removed. The PCI deadline was about 18 months ago.
> > > > > > 
> > > > > 
> > > > > Yep, but I'd like to keep this revert instead of just fixing the
> > > > > qemu-ppce500 here, to give people a chance to test their original
> > > > > non-DM version of PCI driver before the DM conversion.
> > > > > 
> > > > > Once all boards have converted to DM PCI, we can revert this revert patch again.
> > > > > 
> > > > > > Tom, do you know the situation here?
> > > > 
> > > > So, I made a lack of DM_PCI migration be fatal and got a build done
> > > > here:
> > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > 
> > > > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > > > the world build.  There's then a handful of ARM boards, another large
> > > > chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
> > > > what to do here to me, other than PowerPC, as other than r2dplus
> > > > everything is missing the main "convert to DM" migration deadline as
> > > > well.
> > > 
> > > What should we do for this patch?
> > > 
> > > If the plan is to drop all boards that are not converted to DM PCI in
> > > 2021.04, I can drop this revert patch in v2.
> > 
> > I've posted the patch to drop the SH boards.  Daniel, what about Malta?
> 
> Malta should be fixed, since it's mips used in CI.

There's also qemu_mips* in CI, so it depends on what Daniel thinks is
the right overall answer here.
Daniel Schwierzeck Feb. 14, 2021, 7:12 p.m. UTC | #15
Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:

...

> > > > > > 
> > > > > > > Tom, do you know the situation here?
> > > > > 
> > > > > So, I made a lack of DM_PCI migration be fatal and got a
> > > > > build done
> > > > > here:
> > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > > 
> > > > > Of note, MIPS malta fails, so I had to drop that from pytest
> > > > > to complete
> > > > > the world build.  There's then a handful of ARM boards,
> > > > > another large
> > > > > chunk of PowerPC, and then a few others such as r7780mp.  SH
> > > > > is the big
> > > > > what to do here to me, other than PowerPC, as other than
> > > > > r2dplus
> > > > > everything is missing the main "convert to DM" migration
> > > > > deadline as
> > > > > well.
> > > > 
> > > > What should we do for this patch?
> > > > 
> > > > If the plan is to drop all boards that are not converted to DM
> > > > PCI in
> > > > 2021.04, I can drop this revert patch in v2.
> > > 
> > > I've posted the patch to drop the SH boards.  Daniel, what about
> > > Malta?
> > 
> > Malta should be fixed, since it's mips used in CI.
> 
> There's also qemu_mips* in CI, so it depends on what Daniel thinks is
> the right overall answer here.
> 

Malta is the MIPS reference board physically as well as in Qemu.
qemu_mips is actually deprecated and is going to be removed from Qemu
sooner or later. That's why I added Malta to CI with the goal to remove
qemu_mips.

The problem with MIPS and DM_PCI is that there are some generic issues
with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual
address. Actually I have a pending patch queue from Paul Burton for
Malta for converting to DM_PCI, but that requires resolving the generic
issues with some refactoring for all MIPS boards. It's still on my TODO
list ;)

Until I can spare enough time to resolve all issues, I could try to
disable the PCI driver in Malta defconfig and mark the driver as broken
in Kconfig. This way we can avoid removing the whole board.
Tom Rini Feb. 14, 2021, 8:30 p.m. UTC | #16
On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote:
> Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
> 
> ...
> 
> > > > > > > 
> > > > > > > > Tom, do you know the situation here?
> > > > > > 
> > > > > > So, I made a lack of DM_PCI migration be fatal and got a
> > > > > > build done
> > > > > > here:
> > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > > > 
> > > > > > Of note, MIPS malta fails, so I had to drop that from pytest
> > > > > > to complete
> > > > > > the world build.  There's then a handful of ARM boards,
> > > > > > another large
> > > > > > chunk of PowerPC, and then a few others such as r7780mp.  SH
> > > > > > is the big
> > > > > > what to do here to me, other than PowerPC, as other than
> > > > > > r2dplus
> > > > > > everything is missing the main "convert to DM" migration
> > > > > > deadline as
> > > > > > well.
> > > > > 
> > > > > What should we do for this patch?
> > > > > 
> > > > > If the plan is to drop all boards that are not converted to DM
> > > > > PCI in
> > > > > 2021.04, I can drop this revert patch in v2.
> > > > 
> > > > I've posted the patch to drop the SH boards.  Daniel, what about
> > > > Malta?
> > > 
> > > Malta should be fixed, since it's mips used in CI.
> > 
> > There's also qemu_mips* in CI, so it depends on what Daniel thinks is
> > the right overall answer here.
> > 
> 
> Malta is the MIPS reference board physically as well as in Qemu.
> qemu_mips is actually deprecated and is going to be removed from Qemu
> sooner or later. That's why I added Malta to CI with the goal to remove
> qemu_mips.
> 
> The problem with MIPS and DM_PCI is that there are some generic issues
> with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual
> address. Actually I have a pending patch queue from Paul Burton for
> Malta for converting to DM_PCI, but that requires resolving the generic
> issues with some refactoring for all MIPS boards. It's still on my TODO
> list ;)
> 
> Until I can spare enough time to resolve all issues, I could try to
> disable the PCI driver in Malta defconfig and mark the driver as broken
> in Kconfig. This way we can avoid removing the whole board.

Thanks for explaining.  Yes, lets go that route for now.
Bin Meng Feb. 18, 2021, 12:32 a.m. UTC | #17
Hi Tom,

On Mon, Feb 15, 2021 at 4:30 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote:
> > Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
> >
> > ...
> >
> > > > > > > >
> > > > > > > > > Tom, do you know the situation here?
> > > > > > >
> > > > > > > So, I made a lack of DM_PCI migration be fatal and got a
> > > > > > > build done
> > > > > > > here:
> > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > > > >
> > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest
> > > > > > > to complete
> > > > > > > the world build.  There's then a handful of ARM boards,
> > > > > > > another large
> > > > > > > chunk of PowerPC, and then a few others such as r7780mp.  SH
> > > > > > > is the big
> > > > > > > what to do here to me, other than PowerPC, as other than
> > > > > > > r2dplus
> > > > > > > everything is missing the main "convert to DM" migration
> > > > > > > deadline as
> > > > > > > well.
> > > > > >
> > > > > > What should we do for this patch?
> > > > > >
> > > > > > If the plan is to drop all boards that are not converted to DM
> > > > > > PCI in
> > > > > > 2021.04, I can drop this revert patch in v2.
> > > > >
> > > > > I've posted the patch to drop the SH boards.  Daniel, what about
> > > > > Malta?
> > > >
> > > > Malta should be fixed, since it's mips used in CI.
> > >
> > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is
> > > the right overall answer here.
> > >
> >
> > Malta is the MIPS reference board physically as well as in Qemu.
> > qemu_mips is actually deprecated and is going to be removed from Qemu
> > sooner or later. That's why I added Malta to CI with the goal to remove
> > qemu_mips.
> >
> > The problem with MIPS and DM_PCI is that there are some generic issues
> > with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual
> > address. Actually I have a pending patch queue from Paul Burton for
> > Malta for converting to DM_PCI, but that requires resolving the generic
> > issues with some refactoring for all MIPS boards. It's still on my TODO
> > list ;)
> >
> > Until I can spare enough time to resolve all issues, I could try to
> > disable the PCI driver in Malta defconfig and mark the driver as broken
> > in Kconfig. This way we can avoid removing the whole board.
>
> Thanks for explaining.  Yes, lets go that route for now.

To make this series not to depend on board removal series, I will drop
this revert patch in v2, and fix the non-DM PCI driver of mpc85xx
instead.

Regards,
Bin
diff mbox series

Patch

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index ba65f47..8a94ea2 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -907,7 +907,6 @@  static void decode_regions(struct pci_controller *hose, ofnode parent_node,
 	int cells_per_record;
 	struct bd_info *bd;
 	const u32 *prop;
-	int max_regions;
 	int len;
 	int i;
 
@@ -927,13 +926,7 @@  static void decode_regions(struct pci_controller *hose, ofnode parent_node,
 	hose->region_count = 0;
 	debug("%s: len=%d, cells_per_record=%d\n", __func__, len,
 	      cells_per_record);
-
-	/* Dynamically allocate the regions array */
-	max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS;
-	hose->regions = (struct pci_region *)
-		calloc(1, max_regions * sizeof(struct pci_region));
-
-	for (i = 0; i < max_regions; i++, len -= cells_per_record) {
+	for (i = 0; i < MAX_PCI_REGIONS; i++, len -= cells_per_record) {
 		u64 pci_addr, addr, size;
 		int space_code;
 		u32 flags;
@@ -987,6 +980,11 @@  static void decode_regions(struct pci_controller *hose, ofnode parent_node,
 		return;
 
 	for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
+		if (hose->region_count == MAX_PCI_REGIONS) {
+			pr_err("maximum number of regions parsed, aborting\n");
+			break;
+		}
+
 		if (bd->bi_dram[i].size) {
 			pci_set_region(hose->regions + hose->region_count++,
 				       bd->bi_dram[i].start,
diff --git a/include/pci.h b/include/pci.h
index 5f36537..64dff55 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -610,6 +610,8 @@  extern void pci_cfgfunc_do_nothing(struct pci_controller* hose, pci_dev_t dev,
 extern void pci_cfgfunc_config_device(struct pci_controller* hose, pci_dev_t dev,
 				      struct pci_config_table *);
 
+#define MAX_PCI_REGIONS		7
+
 #define INDIRECT_TYPE_NO_PCIE_LINK	1
 
 /**
@@ -650,7 +652,7 @@  struct pci_controller {
 	 * for PCI controllers and a separate UCLASS (or perhaps
 	 * UCLASS_PCI_GENERIC) is used for bridges.
 	 */
-	struct pci_region *regions;
+	struct pci_region regions[MAX_PCI_REGIONS];
 	int region_count;
 
 	struct pci_config_table *config_table;