Pensando Elba SoC platforms have a SPI connected CPLD
for platform management.
Signed-off-by: Brad Larson <[email protected]>
---
drivers/spi/spidev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 8cb4d923aeaa..8b285852ce82 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -683,6 +683,7 @@ static const struct of_device_id spidev_dt_ids[] = {
{ .compatible = "dh,dhcom-board" },
{ .compatible = "menlo,m53cpld" },
{ .compatible = "cisco,spi-petra" },
+ { .compatible = "pensando,cpld" },
{},
};
MODULE_DEVICE_TABLE(of, spidev_dt_ids);
--
2.17.1
On Mon, Mar 29, 2021 at 5:01 AM Brad Larson <[email protected]> wrote:
>
> Pensando Elba SoC platforms have a SPI connected CPLD
> for platform management.
And? It's not a good justification to spread the (debugging only)
spidev interface.
What tool is going to use it? Why can't you have a driver for that in
the kernel?
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 3:45 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Mar 29, 2021 at 5:01 AM Brad Larson <[email protected]> wrote:
> >
> > Pensando Elba SoC platforms have a SPI connected CPLD
> > for platform management.
>
> And? It's not a good justification to spread the (debugging only)
> spidev interface.
>
> What tool is going to use it? Why can't you have a driver for that in
> the kernel?
The driver is in userspace and we need to instantiate /dev/spi0.N
in the /dev directory. The CPLD includes a device id and version
id that userspace applications use to differentiate functionality on
different boards. It wouldn't really be appropriate to use one of
the existing entries.
For example even with high pin count SoCs we are offloading
low speed functionality into the CPLD connected over SPI. The
elba-asic-common.dtsi file shows a compatible string of
"pensando,cpld-rd1173" which does have a kernel driver we
intend to contribute later if there is interest. This IP in the CPLD
is readily available from Lattice which provides two I2C Masters
which in our case we use for access to the network port transceivers.
What was missing in the kernel was a bridge driver that exposes
what looks like a standard I2C device to userspace where the
drivers/i2c/busses/i2c-rd1173.c handles the spi transfers to the
Lattice IP in the CPLD.
>
> --
> With Best Regards,
> Andy Shevchenko