Re: [PATCH v6 2/7] reset: mchp: sparx5: Use the second reg item when cpu-syscon is not present

[Herve Codina]

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, &regmap_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é