[PATCH] bcma: Kconfig: Let it depend on PCI

[PATCH] bcma: Kconfig: Let it depend on PCI

[Rafał Miłecki]

On 3 March 2015 at 22:16, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI,
> or will cause building break for allmodconfig under c6x:
>
>     CC [M]  drivers/bcma/driver_pcie2.o
>   drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>   drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function 'pcie_set_readrq' [-Werror=implicit-function-declaration]
>     err = pcie_set_readrq(dev, pcie2->reqsize);
>           ^
>
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
>  drivers/bcma/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
> index 0ee48be..8be284e 100644
> --- a/drivers/bcma/Kconfig
> +++ b/drivers/bcma/Kconfig
> @@ -1,6 +1,6 @@
>  config BCMA_POSSIBLE
>         bool
> -       depends on HAS_IOMEM && HAS_DMA
> +       depends on HAS_IOMEM && HAS_DMA && PCI
>         default y
>
>  menu "Broadcom specific AMBA"
> --
> 1.9.3

Hm, I'm not sure how to ideally handle this. Cc-ing few ppl, maybe
they have something to add.

In fact there are SoCs (not using PCI host code obviously) with
everything embedded (without any PCI host mode cores). So note
following info about driver_pci.c and driver_pcie2.c:
1) For BCMA_HOST_PCI
They are required, because of needed host-related PCI(e) core initialization.
2) For BCMA_HOST_SOC
They are needed only if your SoC has PCI(e) host cores and you want to use them.

So I guess in theory we could have BCMA_DRIVER_PCI and *require* it
for BCMA_HOST_PCI only.

This could save some little amount of space for users of some SoCs
like (ancient) BCM5352E, BCM5354 or (newer) BCM5357B0, BCM5358,
BCM47186B0, BCM5357C0, BCM5356C0, BCM4716B0.

-- 
Rafa?

[PATCH] bcma: Kconfig: Let it depend on PCI

[Rafał Miłecki]

On 4 March 2015 at 07:19, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 3 March 2015 at 22:16, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI,
>> or will cause building break for allmodconfig under c6x:
>>
>>     CC [M]  drivers/bcma/driver_pcie2.o
>>   drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>>   drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function 'pcie_set_readrq' [-Werror=implicit-function-declaration]
>>     err = pcie_set_readrq(dev, pcie2->reqsize);
>>           ^
>>
>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>> ---
>>  drivers/bcma/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
>> index 0ee48be..8be284e 100644
>> --- a/drivers/bcma/Kconfig
>> +++ b/drivers/bcma/Kconfig
>> @@ -1,6 +1,6 @@
>>  config BCMA_POSSIBLE
>>         bool
>> -       depends on HAS_IOMEM && HAS_DMA
>> +       depends on HAS_IOMEM && HAS_DMA && PCI
>>         default y
>>
>>  menu "Broadcom specific AMBA"
>> --
>> 1.9.3
>
> Hm, I'm not sure how to ideally handle this. Cc-ing few ppl, maybe
> they have something to add.
>
> In fact there are SoCs (not using PCI host code obviously) with
> everything embedded (without any PCI host mode cores). So note
> following info about driver_pci.c and driver_pcie2.c:
> 1) For BCMA_HOST_PCI
> They are required, because of needed host-related PCI(e) core initialization.
> 2) For BCMA_HOST_SOC
> They are needed only if your SoC has PCI(e) host cores and you want to use them.
>
> So I guess in theory we could have BCMA_DRIVER_PCI and *require* it
> for BCMA_HOST_PCI only.

After thinking about this.
We already have Kconfig entries for other internal drivers, so I guess
it makes sense to do the same for PCIe.

-- 
Rafa?

[PATCH] bcma: Kconfig: Let it depend on PCI

[Rafał Miłecki]

On 4 March 2015 at 13:08, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 4 March 2015 at 07:19, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> On 3 March 2015 at 22:16, Chen Gang <xili_gchen_5257@hotmail.com> wrote:
>>> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI,
>>> or will cause building break for allmodconfig under c6x:
>>>
>>>     CC [M]  drivers/bcma/driver_pcie2.o
>>>   drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>>>   drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function 'pcie_set_readrq' [-Werror=implicit-function-declaration]
>>>     err = pcie_set_readrq(dev, pcie2->reqsize);
>>>           ^
>>>
>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>> ---
>>>  drivers/bcma/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
>>> index 0ee48be..8be284e 100644
>>> --- a/drivers/bcma/Kconfig
>>> +++ b/drivers/bcma/Kconfig
>>> @@ -1,6 +1,6 @@
>>>  config BCMA_POSSIBLE
>>>         bool
>>> -       depends on HAS_IOMEM && HAS_DMA
>>> +       depends on HAS_IOMEM && HAS_DMA && PCI
>>>         default y
>>>
>>>  menu "Broadcom specific AMBA"
>>> --
>>> 1.9.3
>>
>> Hm, I'm not sure how to ideally handle this. Cc-ing few ppl, maybe
>> they have something to add.
>>
>> In fact there are SoCs (not using PCI host code obviously) with
>> everything embedded (without any PCI host mode cores). So note
>> following info about driver_pci.c and driver_pcie2.c:
>> 1) For BCMA_HOST_PCI
>> They are required, because of needed host-related PCI(e) core initialization.
>> 2) For BCMA_HOST_SOC
>> They are needed only if your SoC has PCI(e) host cores and you want to use them.
>>
>> So I guess in theory we could have BCMA_DRIVER_PCI and *require* it
>> for BCMA_HOST_PCI only.
>
> After thinking about this.
> We already have Kconfig entries for other internal drivers, so I guess
> it makes sense to do the same for PCIe.

I've just realized that implementing my idea (optional PCIe core
drivers) will require reworking following functions:
bcma_core_pci_irq_ctl
bcma_core_pci_power_save
bcma_core_pci_irq_ctl
bcma_core_pci_init
bcma_core_pcie2_init
bcma_core_pci_early_init
to make them safe to call ever without BCMA_DRIVER_PCI(E).

To do that we should clean headers first, which is what I started doing in
[PATCH next] bcma: move internal function declarations to private header

So I think that for now we could just accept Chen's patch and then
improve PCIe handling in bcma dropping this dependency at some point.

Any other opinions?

-- 
Rafa?

[PATCH] bcma: Kconfig: Let it depend on PCI

[Michael Büsch]

On Wed, 4 Mar 2015 14:36:10 +0100
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> Any other opinions?

I think this is the only way to go.
In ssb we always had optional pcicore driver, as far as I remember,
so we should have the same in bcma, too.
The old WRT54G kernel used to compile just fine with SSB and without any PCI enabled.

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20150304/149b38f6/attachment.sig>

[PATCH] bcma: Kconfig: Let it depend on PCI

[Rafał Miłecki]

On 4 March 2015 at 17:38, Michael B?sch <m@bues.ch> wrote:
> On Wed, 4 Mar 2015 14:36:10 +0100
> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>
>> Any other opinions?
>
> I think this is the only way to go.
> In ssb we always had optional pcicore driver, as far as I remember,
> so we should have the same in bcma, too.
> The old WRT54G kernel used to compile just fine with SSB and without any PCI enabled.

Thanks. I'll start working on this in a second.

-- 
Rafa?