Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]

On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an arm allmodconfig due to:

> 	arm-allmodconfig
> ../drivers/pci/host/pcie-mediatek.c:485:8: error: implicit declaration of function 'pci_register_host_bridge' [-Werror=implicit-function-declaration]

caused by eaf3023b0498a (PCI: mediatek: Add MediaTek PCIe host
controller support).

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Ryder Lee]

Sorry for late reply, 

+Lorenzo

On Wed, 2017-06-21 at 18:04 +0800, Mark Brown wrote:
> On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:
> 
> Today's -next fails to build an arm allmodconfig due to:
> 
> > 	arm-allmodconfig
> > ../drivers/pci/host/pcie-mediatek.c:485:8: error: implicit declaration of function 'pci_register_host_bridge' [-Werror=implicit-function-declaration]
> 
> caused by eaf3023b0498a (PCI: mediatek: Add MediaTek PCIe host
> controller support).


Hi Lorenzo,

I picked up your changes and had some modifications like what you did
for other platforms:

9f8e3a5 PCI: Add devm_pci_alloc_host_bridge() interface 
35a1a84 PCI: Add pci_free_host_bridge() interface
e33aafd PCI: Initialize bridge release function at bridge allocation

...and it looks Okay.

I have also noticed that you continue sending patches for other
platforms but I have not yet had a look in detail. I'm quite busy these
days and don't have time to dig it, hence it is becoming a little
unmanageable for me.

Did you have a chance to send the same patches for MediaTek?  I
appreciate that and I can help to test it on our platforms.


Ryder.




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Lorenzo Pieralisi]

On Fri, Jun 23, 2017 at 05:13:16PM +0800, Ryder Lee wrote:
> Sorry for late reply, 
> 
> +Lorenzo
> 
> On Wed, 2017-06-21 at 18:04 +0800, Mark Brown wrote:
> > On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:
> > 
> > Today's -next fails to build an arm allmodconfig due to:
> > 
> > > 	arm-allmodconfig
> > > ../drivers/pci/host/pcie-mediatek.c:485:8: error: implicit declaration of function 'pci_register_host_bridge' [-Werror=implicit-function-declaration]
> > 
> > caused by eaf3023b0498a (PCI: mediatek: Add MediaTek PCIe host
> > controller support).
> 
> 
> Hi Lorenzo,
> 
> I picked up your changes and had some modifications like what you did
> for other platforms:
> 
> 9f8e3a5 PCI: Add devm_pci_alloc_host_bridge() interface 
> 35a1a84 PCI: Add pci_free_host_bridge() interface
> e33aafd PCI: Initialize bridge release function at bridge allocation
> 
> ...and it looks Okay.
> 
> I have also noticed that you continue sending patches for other
> platforms but I have not yet had a look in detail. I'm quite busy these
> days and don't have time to dig it, hence it is becoming a little
> unmanageable for me.

If it is unmanageable you don't add yourself as a maintainer of that
PCI host bridge driver, you know, we are all busy.

Your driver in the PCI tree as it stands contains already two bugs:

1) It leaks memory on the probe failure path
2) pci_fixup_irqs() is broken on configurations with multiple host
   bridges

And we keep copy'n'pasting that code.

> Did you have a chance to send the same patches for MediaTek?  I
> appreciate that and I can help to test it on our platforms.

No, how could I have sent them ? It is not upstream and it is a separate
branch in the PCI tree. As I mentioned in another thread it is probably
best to drop my pci_fixup_irqs() removal patches since it is impossible
to work on them without a stable branch to apply them against, in the
interim we keep adding PCI host bridges that use the wrong interfaces by
copy'n'pasting code that I have been trying to remove.

I think the best solution is to repost my series when v4.13-rc1 appears
and ask all new crop of host bridge drivers to rebase against it.

I won't be able to follow mailing lists till end of next week, which
is bad timing.

Bjorn, is the plan above ok ? Please let me know how you want to
proceed.

Thanks,
Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Ryder Lee]

On Fri, 2017-06-23 at 10:43 +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 23, 2017 at 05:13:16PM +0800, Ryder Lee wrote:
> > Sorry for late reply, 
> > 
> > +Lorenzo
> > 
> > On Wed, 2017-06-21 at 18:04 +0800, Mark Brown wrote:
> > > On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:
> > > 
> > > Today's -next fails to build an arm allmodconfig due to:
> > > 
> > > > 	arm-allmodconfig
> > > > ../drivers/pci/host/pcie-mediatek.c:485:8: error: implicit declaration of function 'pci_register_host_bridge' [-Werror=implicit-function-declaration]
> > > 
> > > caused by eaf3023b0498a (PCI: mediatek: Add MediaTek PCIe host
> > > controller support).
> > 
> > 
> > Hi Lorenzo,
> > 
> > I picked up your changes and had some modifications like what you did
> > for other platforms:
> > 
> > 9f8e3a5 PCI: Add devm_pci_alloc_host_bridge() interface 
> > 35a1a84 PCI: Add pci_free_host_bridge() interface
> > e33aafd PCI: Initialize bridge release function at bridge allocation
> > 
> > ...and it looks Okay.
> > 
> > I have also noticed that you continue sending patches for other
> > platforms but I have not yet had a look in detail. I'm quite busy these
> > days and don't have time to dig it, hence it is becoming a little
> > unmanageable for me.
> 
> If it is unmanageable you don't add yourself as a maintainer of that
> PCI host bridge driver, you know, we are all busy.
> 
> Your driver in the PCI tree as it stands contains already two bugs:
> 
> 1) It leaks memory on the probe failure path
> 2) pci_fixup_irqs() is broken on configurations with multiple host
>    bridges
> 
> And we keep copy'n'pasting that code.

Sure, I have already tested it, and I'll send a patch with your new
methods :)


> > Did you have a chance to send the same patches for MediaTek?  I
> > appreciate that and I can help to test it on our platforms.
> 
> No, how could I have sent them ? It is not upstream and it is a separate
> branch in the PCI tree. As I mentioned in another thread it is probably
> best to drop my pci_fixup_irqs() removal patches since it is impossible
> to work on them without a stable branch to apply them against, in the
> interim we keep adding PCI host bridges that use the wrong interfaces by
> copy'n'pasting code that I have been trying to remove.
> 
> I think the best solution is to repost my series when v4.13-rc1 appears
> and ask all new crop of host bridge drivers to rebase against it.
> 
> I won't be able to follow mailing lists till end of next week, which
> is bad timing.

I meant I'm also not sure how to do it in separate branch. I didn't
notice what you discussed in another thread. Sorry about that.

> Bjorn, is the plan above ok ? Please let me know how you want to
> proceed.
> 
> Thanks,
> Lorenzo

Ryder



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Lorenzo Pieralisi]

On Fri, Jun 23, 2017 at 06:22:13PM +0800, Ryder Lee wrote:
> On Fri, 2017-06-23 at 10:43 +0100, Lorenzo Pieralisi wrote:
> > On Fri, Jun 23, 2017 at 05:13:16PM +0800, Ryder Lee wrote:
> > > Sorry for late reply, 
> > > 
> > > +Lorenzo
> > > 
> > > On Wed, 2017-06-21 at 18:04 +0800, Mark Brown wrote:
> > > > On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:
> > > > 
> > > > Today's -next fails to build an arm allmodconfig due to:
> > > > 
> > > > > 	arm-allmodconfig
> > > > > ../drivers/pci/host/pcie-mediatek.c:485:8: error: implicit declaration of function 'pci_register_host_bridge' [-Werror=implicit-function-declaration]
> > > > 
> > > > caused by eaf3023b0498a (PCI: mediatek: Add MediaTek PCIe host
> > > > controller support).
> > > 
> > > 
> > > Hi Lorenzo,
> > > 
> > > I picked up your changes and had some modifications like what you did
> > > for other platforms:
> > > 
> > > 9f8e3a5 PCI: Add devm_pci_alloc_host_bridge() interface 
> > > 35a1a84 PCI: Add pci_free_host_bridge() interface
> > > e33aafd PCI: Initialize bridge release function at bridge allocation
> > > 
> > > ...and it looks Okay.
> > > 
> > > I have also noticed that you continue sending patches for other
> > > platforms but I have not yet had a look in detail. I'm quite busy these
> > > days and don't have time to dig it, hence it is becoming a little
> > > unmanageable for me.
> > 
> > If it is unmanageable you don't add yourself as a maintainer of that
> > PCI host bridge driver, you know, we are all busy.
> > 
> > Your driver in the PCI tree as it stands contains already two bugs:
> > 
> > 1) It leaks memory on the probe failure path
> > 2) pci_fixup_irqs() is broken on configurations with multiple host
> >    bridges
> > 
> > And we keep copy'n'pasting that code.
> 
> Sure, I have already tested it, and I'll send a patch with your new
> methods :)

Thank you for testing it but please do not send anything before we
decide what to do with my pci_fixup_irqs() removal series.

> > > Did you have a chance to send the same patches for MediaTek?  I
> > > appreciate that and I can help to test it on our platforms.
> > 
> > No, how could I have sent them ? It is not upstream and it is a separate
> > branch in the PCI tree. As I mentioned in another thread it is probably
> > best to drop my pci_fixup_irqs() removal patches since it is impossible
> > to work on them without a stable branch to apply them against, in the
> > interim we keep adding PCI host bridges that use the wrong interfaces by
> > copy'n'pasting code that I have been trying to remove.
> > 
> > I think the best solution is to repost my series when v4.13-rc1 appears
> > and ask all new crop of host bridge drivers to rebase against it.
> > 
> > I won't be able to follow mailing lists till end of next week, which
> > is bad timing.
> 
> I meant I'm also not sure how to do it in separate branch. I didn't
> notice what you discussed in another thread. Sorry about that.

No worries, yes we need to understand how to sync the changes, as I
said it is probably better for my series to be dropped, posted at
v4.13-rc1, create a branch out of it and ask all PCI host bridges
to be based against it, it is up to Bjorn to decide what's the least
complicated way for him to sync all these changes.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Bjorn Helgaas]

On Fri, Jun 23, 2017 at 10:43:56AM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 23, 2017 at 05:13:16PM +0800, Ryder Lee wrote:
> > Sorry for late reply, 
> > 
> > +Lorenzo
> > 
> > On Wed, 2017-06-21 at 18:04 +0800, Mark Brown wrote:
> > > On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:
> > > 
> > > Today's -next fails to build an arm allmodconfig due to:
> > > 
> > > > 	arm-allmodconfig
> > > > ../drivers/pci/host/pcie-mediatek.c:485:8: error: implicit declaration of function 'pci_register_host_bridge' [-Werror=implicit-function-declaration]
> > > 
> > > caused by eaf3023b0498a (PCI: mediatek: Add MediaTek PCIe host
> > > controller support).
> > 
> > 
> > Hi Lorenzo,
> > 
> > I picked up your changes and had some modifications like what you did
> > for other platforms:
> > 
> > 9f8e3a5 PCI: Add devm_pci_alloc_host_bridge() interface 
> > 35a1a84 PCI: Add pci_free_host_bridge() interface
> > e33aafd PCI: Initialize bridge release function at bridge allocation
> > 
> > ...and it looks Okay.
> > 
> > I have also noticed that you continue sending patches for other
> > platforms but I have not yet had a look in detail. I'm quite busy these
> > days and don't have time to dig it, hence it is becoming a little
> > unmanageable for me.
> 
> If it is unmanageable you don't add yourself as a maintainer of that
> PCI host bridge driver, you know, we are all busy.
> 
> Your driver in the PCI tree as it stands contains already two bugs:
> 
> 1) It leaks memory on the probe failure path
> 2) pci_fixup_irqs() is broken on configurations with multiple host
>    bridges
> 
> And we keep copy'n'pasting that code.
> 
> > Did you have a chance to send the same patches for MediaTek?  I
> > appreciate that and I can help to test it on our platforms.
> 
> No, how could I have sent them ? It is not upstream and it is a separate
> branch in the PCI tree. As I mentioned in another thread it is probably
> best to drop my pci_fixup_irqs() removal patches since it is impossible
> to work on them without a stable branch to apply them against, in the
> interim we keep adding PCI host bridges that use the wrong interfaces by
> copy'n'pasting code that I have been trying to remove.
> 
> I think the best solution is to repost my series when v4.13-rc1 appears
> and ask all new crop of host bridge drivers to rebase against it.
> 
> I won't be able to follow mailing lists till end of next week, which
> is bad timing.
> 
> Bjorn, is the plan above ok ? Please let me know how you want to
> proceed.

Sorry, I was on vacation myself most of last week, and you're
unavailable most of this week, but I'd still like to try to get this
into v4.13.

We may not get every host tested, but I'm not sure that will happen
even if we wait for the next cycle.  If we trip over something it will
likely be something small or for a relatively rare platform, so we can
fix it up after the fact.

I haven't looked at everything yet, but my plan is to try to
incorporate the fixes people have posted and keep pushing forward.  If
that turns out not to work, I'll drop the pci_fixup_irqs() series, but
I'll at least give it a try.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel