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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241001183038.1cc77490@bootlin.com>
Date: Tue, 1 Oct 2024 18:30:38 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: "Arnd Bergmann" <arnd@...db.de>
Cc: "Geert Uytterhoeven" <geert@...ux-m68k.org>, "Andy Shevchenko"
 <andy.shevchenko@...il.com>, "Simon Horman" <horms@...nel.org>, "Lee Jones"
 <lee@...nel.org>, "derek.kiernan@....com" <derek.kiernan@....com>,
 "dragan.cvetic@....com" <dragan.cvetic@....com>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, "Bjorn Helgaas" <bhelgaas@...gle.com>,
 "Philipp Zabel" <p.zabel@...gutronix.de>, "Lars Povlsen"
 <lars.povlsen@...rochip.com>, "Steen Hegelund"
 <Steen.Hegelund@...rochip.com>, "Daniel Machon"
 <daniel.machon@...rochip.com>, UNGLinuxDriver@...rochip.com, "Rob Herring"
 <robh@...nel.org>, "Krzysztof Kozlowski" <krzk+dt@...nel.org>, "Conor
 Dooley" <conor+dt@...nel.org>, "Saravana Kannan" <saravanak@...gle.com>,
 "David S . Miller" <davem@...emloft.net>, "Eric Dumazet"
 <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>, "Paolo Abeni"
 <pabeni@...hat.com>, "Horatiu Vultur" <horatiu.vultur@...rochip.com>,
 "Andrew Lunn" <andrew@...n.ch>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
 linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, "Allan
 Nielsen" <allan.nielsen@...rochip.com>, "Luca Ceresoli"
 <luca.ceresoli@...tlin.com>, "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v6 2/7] reset: mchp: sparx5: Use the second reg item
 when cpu-syscon is not present

Hi Arnd,

On Mon, 30 Sep 2024 16:26:16 +0200
Herve Codina <herve.codina@...tlin.com> wrote:

> On Mon, 30 Sep 2024 13:57:01 +0000
> "Arnd Bergmann" <arnd@...db.de> 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@bootlin.com/ [1]
> > > Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> > > ---    
> >   
> > >>  	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é