Hi Daniel,
On 21.07.20 16:59, Daniel Schwierzeck wrote:
Hi Daniel,
On 18.07.20 15:25, Daniel Schwierzeck wrote:
From: Suneel Garapati sgarapati@marvell.com
...
found another issue:
drivers/gpio/octeon_gpio.c: In function 'octeon_gpio_probe': drivers/gpio/octeon_gpio.c:189:16: warning: implicit declaration of function 'dm_pci_map_bar'; did you mean 'pci_map_bar'? [-Wimplicit- function-declaration] 189 | priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, | ^~~~~~~~~~~~~~ | pci_map_bar drivers/gpio/octeon_gpio.c:189:14: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 189 | priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, | ^
Ah, I did not see this in my local builds, as I have enabled DM_PCI here and forgot to add this dependency.
due to the dependency on DM_PCI you need to express this in Kconfig with "depends on DM_PCI ...". Alternatively you need to wrap the PCI specific code with a "#ifdef CONFIG_DM_PCI" as the DM_PCI specific function prototypes in pci.h are also wrapped with "#ifdef CONFIG_DM_PCI". The former option will build and link DM PCI code which is not used and therefore bloats the U-Boot binary.
I guess the choice mainly depends on whether you'll add a PCI host controller driver for Octeon MIPS64 in the future and can live with the extra but unused PCI code until then.
We can definitely live with the temporarily unused PCI code. I don't want to add these #ifdefs again, which I removed explicitly upon Simon's request.
To solve this, I would prefer to add a "select DM_PCI & PCI" to arch/mips/Kconfig for Octeon, as this PCI probing construct is not only used in this GPIO driver, but also in many other drivers shared between MIPS Octeon and the also upcoming ARM64 Octeon TX/TX2 support, like I2C, SPI etc. Here all devices are PCI based hence the PCI probing dependency.
Is this okay with you? Or should I stay with the dependency in the drivers Kconfig file?
I would also prefer a "select DM_PCI". I just struggle a bit with the "& PCI" part. IMHO DM_PCI should not depend on PCI because DM_PCI should be a hidden option which is selected by the SoC dependent on the SoC specific drivers and whether them support DM. It doesn't make sense to let the user choose all those DM_* options. Most other DM_* options already work like this except that them are not hidden.
BTW: When you prepare a patch, you can also "select DM_I2C" and "DM_SPI" which have the same issues with the PCI dependency.
Sure. But selecting only "DM_PCI" and not "PCI" leads to these issues:
WARNING: unmet direct dependencies detected for DM_PCI Depends on [n]: PCI [=n] && DM [=y] Selected by [y]: - ARCH_OCTEON [=y] && <choice>
It doesn't make sense to have DM_PCI enabled and PCI not. Same happens with DM_SPI BTW.
How would you like me to solve this? Enable PCI (and SPI etc) in the board defconfig file? This will lead to problems with git-bisecting though, as the Kconfig change depends on the defconfig change and vice versa. I'll squash the Kconfig and defconfig updates in one patch because of this.
I'll combine all these changes including the GPIO driver update, all the dts updates and a newly introduced simple clk driver in a new patchset shortly.
Thanks, Stefan