Hi Sergey,
On Wed, Mar 31, 2021 at 11:10 AM Serge Semin [off-list ref] wrote:
On Sun, Mar 28, 2021 at 06:59:26PM -0700, Brad Larson wrote:
quoted
This GPIO driver is for the Pensando Elba SoC which
provides control of four chip selects on two SPI busses.
[...]
quoted
+static int elba_spics_probe(struct platform_device *pdev)
+{
+ struct elba_spics_priv *p;
+ struct resource *res;
+ int ret = 0;
+
+ p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
quoted
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ p->base = devm_ioremap_resource(&pdev->dev, res);
In accordance with the DTS-node this is just a single register
0x307c2468-0x307c24C picked from some bigger block, which most likely
belongs to something like a system controller. PCIe node has got
another register from there "0x307c2480-0x307c2484/* MS CFG_WDT */",
and some BSM device too "0x307c2080-0x307c2084". Please consider using
syscon instead of directly requesting the resource here.
-Sergey
I've looked into a few syscon based implementations which resulted in
a regressions to include Elba spi probe failure and host machine check
trying to perform PCIe access to Elba SoC. I like the idea of
refactoring to use syscon but I don't have a functional solution to do
so.
Regards,
Brad
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel