linux-kernel - RE: [EXTERNAL] Re: [PATCH v8 3/4] spi: cadence: Allow to read basic xSPI configuration from ACPI

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 for Android: free password hash cracker in your pocket

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

Message-ID: 
 <CO6PR18MB4098CD7676AA96B680FBC068B0C72@CO6PR18MB4098.namprd18.prod.outlook.com>
Date: Tue, 11 Jun 2024 21:57:09 +0000
From: Witold Sadowski <wsadowski@...vell.com>
To: Mark Brown <broonie@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "robh@...nel.org"
	<robh@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org"
	<krzysztof.kozlowski+dt@...aro.org>,
        "conor+dt@...nel.org"
	<conor+dt@...nel.org>,
        "pthombar@...ence.com" <pthombar@...ence.com>,
        Piyush
 Malgujar <pmalgujar@...vell.com>
Subject: RE: [EXTERNAL] Re: [PATCH v8 3/4] spi: cadence: Allow to read basic
 xSPI configuration from ACPI

Hi

> > These changes enable reading the configurations from ACPI tables as
> > required for successful probing in an ACPI UEFI environment. In the
> > case of an ACPI-disabled or DTS-based environment, it will continue to
> > read configurations from DTS as before.
> 
> This doesn't describe what the ACPI tables are supposed to look like or
> anything, it's hard to review this...

There should be an example of ACPI table in commit message?

> 
> > +#ifdef CONFIG_ACPI
> > +static bool cdns_xspi_supports_op(struct spi_mem *mem,
> > +				  const struct spi_mem_op *op)
> > +{
> 
> > +	if (!acpi_dev_get_property(adev, "spi-tx-bus-width",
> ACPI_TYPE_INTEGER,
> > +				   &obj)) {
> 
> > +	if (!acpi_dev_get_property(adev, "spi-rx-bus-width",
> ACPI_TYPE_INTEGER,
> > +				   &obj)) {
> 
> Why is this Cadence specific?

So that part should do to generic spi? I think right now it is not
Supported to read tx/rx bus width from acpi.

> 
> >  static int cdns_xspi_of_get_plat_data(struct platform_device *pdev)
> > {
> > -	struct device_node *node_prop = pdev->dev.of_node;
> > +	struct fwnode_handle *fwnode_child;
> >  	unsigned int cs;
> >
> > -	for_each_available_child_of_node_scoped(node_prop, node_child) {
> > -		if (of_property_read_u32(node_child, "reg", &cs)) {
> > +	device_for_each_child_node(&pdev->dev, fwnode_child) {
> > +		if (!fwnode_device_is_available(fwnode_child))
> > +			continue;
> > +
> > +		if (fwnode_property_read_u32(fwnode_child, "reg", &cs)) {
> >  			dev_err(&pdev->dev, "Couldn't get memory chip
> select\n");
> > +			fwnode_handle_put(fwnode_child);
> >  			return -ENXIO;
> >  		} else if (cs >= CDNS_XSPI_MAX_BANKS) {
> >  			dev_err(&pdev->dev, "reg (cs) parameter value too
> large\n");
> > +			fwnode_handle_put(fwnode_child);
> >  			return -ENXIO;
> >  		}
> >  	}
> 
> This is just a general refactoring to fwnode and could be split out.

Ok.

> 
> > @@ -814,19 +890,19 @@ static int cdns_xspi_probe(struct platform_device
> *pdev)
> >  	if (ret)
> >  		return -ENODEV;
> >
> > -	cdns_xspi->iobase = devm_platform_ioremap_resource_byname(pdev,
> "io");
> > +	cdns_xspi->iobase = devm_platform_ioremap_resource(pdev, 0);
> 
> > -	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sdma");
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> 
> > -	cdns_xspi->auxbase = devm_platform_ioremap_resource_byname(pdev,
> "aux");
> > +	cdns_xspi->auxbase = devm_platform_ioremap_resource(pdev, 2);
> 
> This causes us to ignore naming on resources, that's an ABI break for
> other systems.

In that case acpi tables are not able to find resource by name. Or at
least I wasn't able to find a way to handle that in different way.
Is there better solution for that part?

Regards
Witek