Hi Arnd, On Mon, 30 Sep 2024 16:26:16 +0200 Herve Codina <herve.codina@xxxxxxxxxxx> wrote: > On Mon, 30 Sep 2024 13:57:01 +0000 > "Arnd Bergmann" <arnd@xxxxxxxx> wrote: > > > On Mon, Sep 30, 2024, at 12:15, Herve Codina wrote: > > > In the LAN966x PCI device use case, syscon cannot be used as syscon > > > devices do not support removal [1]. A syscon device is a core "system" > > > device and not a device available in some addon boards and so, it is not > > > supposed to be removed. > > > > > > In order to remove the syscon usage, use a local mapping of a reg > > > address range when cpu-syscon is not present. > > > > > > Link: https://lore.kernel.org/all/20240923100741.11277439@xxxxxxxxxxx/ [1] > > > Signed-off-by: Herve Codina <herve.codina@xxxxxxxxxxx> > > > --- > > > > >> err = mchp_sparx5_map_syscon(pdev, "cpu-syscon", &ctx->cpu_ctrl); > > > - if (err) > > > + switch (err) { > > > + case 0: > > > + break; > > > + case -ENODEV: > > > > I was expecting a patch that would read the phandle and map the > > syscon node to keep the behavior unchanged, but I guess this one > > works as well. > > > > The downside of your approach is that it requires an different > > DT binding, which only works as long as there are no other > > users of the syscon registers. > > Yes, I knwow but keeping the binding with the syscon device (i.e. compatible > = "...", "syscon";) leads to confusion. > Indeed, the syscon API cannot be used because using this API leads issues > when the syscon device is removed. > That means the you have a "syscon" node (compatible = "syscon") but we cannot > use the syscon API (include/linux/mfd/syscon.h) with this node. > > Also, in order to share resources between several consumers of the "syscon" > registers, we need exactly what is done in syscon. I mean we need to map > resources only once, provide this resource throught a regmap an share this > regmap between the consumers. Indeed a lock needs to be shared in order to > protect against registers RMW accesses done by several consumers. > In other word, we need to copy/paste syscon code with support for removal > implemented (feature needed in the LAN966x PCI device use case). > > So, I found really simpler and less confusing to fully discard the syscon node > and handle registers directly in the only one consumer. > > With all of these, do you thing my approach can be acceptable ? > Well, the related binding has been rejected. In the next iteration, I will keep the syscon node and implement what you suggested (i.e. read the phandle and map the syscon node). This will look like this: --- 8< --- static const struct regmap_config mchp_lan966x_syscon_regmap_config = { .reg_bits = 32, .val_bits = 32, .reg_stride = 4, }; static struct regmap *mchp_lan966x_syscon_to_regmap(struct device *dev, struct device_node *syscon_np) { struct regmap_config regmap_config = mchp_lan966x_syscon_regmap_config; resource_size_t size; void __iomem *base; base = devm_of_iomap(dev, syscon_np, 0, &size); if (IS_ERR(base)) return ERR_CAST(base); regmap_config.max_register = size - 4; return devm_regmap_init_mmio(dev, base, ®map_config); } --- 8< --- In mchp_sparx5_map_syscon(), I will call the syscon API or the local function based on the device compatible string: --- 8< --- if (of_device_is_compatible(pdev->dev.of_node, "microchip,lan966x-switch-reset")) regmap = mchp_lan966x_syscon_to_regmap(&pdev->dev, syscon_np); else regmap = syscon_node_to_regmap(syscon_np); --- 8< --- Is this kind of solution you were expecting? If you have thought about something different, can you give me some pointers? Best regards, Hervé
