Received-SPF: pass (google.com: domain of linux-kernel+bounces-210638-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Witold Sadowski <wsadowski@marvell.com>
To: Mark Brown <broonie@kernel.org>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "robh@kernel.org"
	<robh@kernel.org>,
        "krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
        "conor+dt@kernel.org"
	<conor+dt@kernel.org>,
        "pthombar@cadence.com" <pthombar@cadence.com>,
        Piyush
 Malgujar <pmalgujar@marvell.com>
Subject: RE: [EXTERNAL] Re: [PATCH v8 3/4] spi: cadence: Allow to read basic
 xSPI configuration from ACPI
Thread-Topic: [EXTERNAL] Re: [PATCH v8 3/4] spi: cadence: Allow to read basic
 xSPI configuration from ACPI
Thread-Index: AQHauO4K6zUk8Kb9I0eeU/kZ+sK2r7HBLw2AgAHyVVA=
Date: Tue, 11 Jun 2024 21:57:09 +0000
Message-ID: 
 <CO6PR18MB4098CD7676AA96B680FBC068B0C72@CO6PR18MB4098.namprd18.prod.outlook.com>
References: <20240607151831.3858304-1-wsadowski@marvell.com>
 <20240607151831.3858304-4-wsadowski@marvell.com>
 <ZmclB2CMhhkasiBw@finisterre.sirena.org.uk>
In-Reply-To: <ZmclB2CMhhkasiBw@finisterre.sirena.org.uk>
Accept-Language: en-US, pl-PL
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?PZ92c943RHoP1cFZ53ijSOKILB3JJsAdQCmPdcUXpduXcodrR7Qk7p9532vJ?=
 =?us-ascii?Q?ZGBZjhOHggVBO4ngK/6FvGZCFecDfwuQW5mhwg2B0lOgr0Dd7Ptpgy/MzjYh?=
 =?us-ascii?Q?/pe/G1q9FdkH/n++Al2lchAKN1seZEkXjtbrRy0SXWdmwjTYUirAyOVL39W/?=
 =?us-ascii?Q?NMJ7/PthcBKn/Dg3tZcopoWVhRdmIX8z4y6P8LJkUSH4LQBx91aUO/cHlt7a?=
 =?us-ascii?Q?G5L+uamQlBNUZMs+nKSg9q10y5ZbRRfh/2mE0f9hNUQL/x++nlqvB0cbxM4A?=
 =?us-ascii?Q?7srCVd9mwulTGsr07bhnoAfHvYEyM3i+WWZtPgEX1COcNf24rtWXkf2HPssI?=
 =?us-ascii?Q?Zdx1LVaPjTa4znj6bogKn2HrcGzxhFeDgbzGiCpto6c+Olx483guaPLU6uYX?=
 =?us-ascii?Q?1q6DhlixtasjSkkP21HsgHtJ5c7TCjOhknU8FfB/zvdh1JyH/vsbM6q1mzVb?=
 =?us-ascii?Q?xHbN38Rt9iTtQyrVBq1xGSYG3j5jeSyL7vkf55T/j1isTlKwWRoTg/a1Uk4d?=
 =?us-ascii?Q?rZCxEFzI0oYkx8Pd3gOCIe4Pm6M/A2lodN7pT8K7G68yNipu7YH1SxuLhGIu?=
 =?us-ascii?Q?reXNLljGkIkaVmBcHnYCn324F14AstocJ63a8dcw/FULHBMlek/gQfFCDGo2?=
 =?us-ascii?Q?qrRIhG7YQiVFvo9JquQBulJNKs4JteXico6mB8oCte6MEGGTplYEyViOF0w9?=
 =?us-ascii?Q?OgPOOTDi3SKrxwr2J6FEauJrAhoaqC/OyCIJqnvNDroDpKTbbxSdJxMjB2tf?=
 =?us-ascii?Q?6Sa9ZTiCfV7Tu9nd/o+nPMf6vDUULA06S+Nhr/lCi2O8DUX89O95peJJI48M?=
 =?us-ascii?Q?DX5dhbtj8zyhfXyFB/nFOU5zh1AtC7mjOaq1BPDvh9bV/CKG13077rNaP7iN?=
 =?us-ascii?Q?SleSLr7BaS5lc9IqOe4HJglkZi0wdIUbZCMSEPG+79GMyWt5pF/w8X8fqDYg?=
 =?us-ascii?Q?ZvibxNhh6p6liYNYm7qknAc6mrukRF5Tfd3vw/EghKMuryc7Ls8jgLsjKRqA?=
 =?us-ascii?Q?jJ47uC/twwVM+Xi8lbBO/ldObwH5ynQo3NJRQsvAqyOsdWjYvcZ3pY2N7wzA?=
 =?us-ascii?Q?MhKJAJd/2TrCOh8Tr8lfgP2PlzNjYcywU85FEoRETW1+DVb8fhsZXNkEclHr?=
 =?us-ascii?Q?wUcTprKP3T5rIN05DN+7J55B90zUvG8Q8ZPESIm0zr5d7SHVEoxl0vPSx8Kh?=
 =?us-ascii?Q?UgYJZCxNeNCYgzxDowKWXhJ5OLDhnFwEor1xakC90V+EsqIfWQ02iAtFyUqo?=
 =?us-ascii?Q?zxRa1vCehXSuF9rzBVRo/EGsrYGfiXrUMQB8Mdr3xFcnzPi5kHAQjBRl24EN?=
 =?us-ascii?Q?vedgC0z6sOZnf+/HOgt1X6NQ1Jvtni7RZ8IEAUV7PmD0X1xHFklTfZY6y7dc?=
 =?us-ascii?Q?B70cREjjSzvjoWsrCdYXXpHNyr+pXjy5ElOJfTPq9/sJuCFYTdCIHGD7TGEc?=
 =?us-ascii?Q?LYTNx82v+BCPXUmVhPzUxSKCDJftTUX8ESTbpiCmZ4k4ZM8ObEviNo5k7D06?=
 =?us-ascii?Q?DN10OhqKqHHuExCqHIDWg7wuaRD78J8hRxc+O2em6Vfz4AHGnEnG71tQOXNB?=
 =?us-ascii?Q?Ft4IXmqj82J38JDKJC9qrk1WgogAji4f3wk28+3w?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: marvell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO6PR18MB4098.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 766edca3-b5e1-42e1-d2c8-08dc8a617127
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2024 21:57:09.4579
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NGEgZ8R2EBPLbgqmoRptUHwDWiqqkbdamKSYG+AEx1USSboXYrZj1YY/rPakzJbkQhsC93mMNX4auG61oE9rlA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR18MB4250
X-Proofpoint-GUID: Ye9CQpVSG4Wj_MfgFyWK8PkUFXDxyPCg
X-Proofpoint-ORIG-GUID: Ye9CQpVSG4Wj_MfgFyWK8PkUFXDxyPCg
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-06-11_11,2024-06-11_01,2024-05-17_01

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.
>=20
> 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?

>=20
> > +#ifdef CONFIG_ACPI
> > +static bool cdns_xspi_supports_op(struct spi_mem *mem,
> > +				  const struct spi_mem_op *op)
> > +{
>=20
> > +	if (!acpi_dev_get_property(adev, "spi-tx-bus-width",
> ACPI_TYPE_INTEGER,
> > +				   &obj)) {
>=20
> > +	if (!acpi_dev_get_property(adev, "spi-rx-bus-width",
> ACPI_TYPE_INTEGER,
> > +				   &obj)) {
>=20
> 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.

>=20
> >  static int cdns_xspi_of_get_plat_data(struct platform_device *pdev)
> > {
> > -	struct device_node *node_prop =3D 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 >=3D CDNS_XSPI_MAX_BANKS) {
> >  			dev_err(&pdev->dev, "reg (cs) parameter value too
> large\n");
> > +			fwnode_handle_put(fwnode_child);
> >  			return -ENXIO;
> >  		}
> >  	}
>=20
> This is just a general refactoring to fwnode and could be split out.

Ok.

>=20
> > @@ -814,19 +890,19 @@ static int cdns_xspi_probe(struct platform_device
> *pdev)
> >  	if (ret)
> >  		return -ENODEV;
> >
> > -	cdns_xspi->iobase =3D devm_platform_ioremap_resource_byname(pdev,
> "io");
> > +	cdns_xspi->iobase =3D devm_platform_ioremap_resource(pdev, 0);
>=20
> > -	res =3D platform_get_resource_byname(pdev, IORESOURCE_MEM, "sdma");
> > +	res =3D platform_get_resource(pdev, IORESOURCE_MEM, 1);
>=20
> > -	cdns_xspi->auxbase =3D devm_platform_ioremap_resource_byname(pdev,
> "aux");
> > +	cdns_xspi->auxbase =3D devm_platform_ioremap_resource(pdev, 2);
>=20
> 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