LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory
@ 2021-11-25  9:55 Krishna Yarlagadda
  2021-11-25  9:55 ` [PATCH 2/2] spi: tegra210-quad: add acpi support Krishna Yarlagadda
  2021-11-27  1:30 ` (subset) [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory Mark Brown
  0 siblings, 2 replies; 10+ messages in thread
From: Krishna Yarlagadda @ 2021-11-25  9:55 UTC (permalink / raw)
  To: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
	Laxman Dewangan, Mark Brown
  Cc: Krishna Yarlagadda, linux-tegra, linux-spi, linux-kernel

Use devm alloc call to allocate memory for spi controller data and
remove free calls from cleanup.

Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com>
---
 drivers/spi/spi-tegra210-quad.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
index c0f9a75..ce1bdb4 100644
--- a/drivers/spi/spi-tegra210-quad.c
+++ b/drivers/spi/spi-tegra210-quad.c
@@ -877,7 +877,7 @@ static struct tegra_qspi_client_data *tegra_qspi_parse_cdata_dt(struct spi_devic
 	struct tegra_qspi_client_data *cdata;
 	struct device_node *slave_np = spi->dev.of_node;
 
-	cdata = kzalloc(sizeof(*cdata), GFP_KERNEL);
+	cdata = devm_kzalloc(&spi->dev, sizeof(*cdata), GFP_KERNEL);
 	if (!cdata)
 		return NULL;
 
@@ -888,14 +888,6 @@ static struct tegra_qspi_client_data *tegra_qspi_parse_cdata_dt(struct spi_devic
 	return cdata;
 }
 
-static void tegra_qspi_cleanup(struct spi_device *spi)
-{
-	struct tegra_qspi_client_data *cdata = spi->controller_data;
-
-	spi->controller_data = NULL;
-	kfree(cdata);
-}
-
 static int tegra_qspi_setup(struct spi_device *spi)
 {
 	struct tegra_qspi *tqspi = spi_master_get_devdata(spi->master);
@@ -1229,7 +1221,6 @@ static int tegra_qspi_probe(struct platform_device *pdev)
 			    SPI_TX_DUAL | SPI_RX_DUAL | SPI_TX_QUAD | SPI_RX_QUAD;
 	master->bits_per_word_mask = SPI_BPW_MASK(32) | SPI_BPW_MASK(16) | SPI_BPW_MASK(8);
 	master->setup = tegra_qspi_setup;
-	master->cleanup = tegra_qspi_cleanup;
 	master->transfer_one_message = tegra_qspi_transfer_one_message;
 	master->num_chipselect = 1;
 	master->auto_runtime_pm = true;
-- 
2.7.4


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-25  9:55 [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory Krishna Yarlagadda
@ 2021-11-25  9:55 ` Krishna Yarlagadda
  2021-11-25 12:59   ` Mark Brown
  2021-11-27  1:30 ` (subset) [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory Mark Brown
  1 sibling, 1 reply; 10+ messages in thread
From: Krishna Yarlagadda @ 2021-11-25  9:55 UTC (permalink / raw)
  To: Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, Mark Brown, Philipp Zabel
  Cc: Krishna Yarlagadda, linux-tegra, linux-spi, linux-kernel

Support ACPI device enumeration for Tegra QUAD SPI driver.
Also pick device features from device tree.

Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com>
---
 drivers/spi/spi-tegra210-quad.c | 74 ++++++++++++++++++++++++++++-------------
 1 file changed, 51 insertions(+), 23 deletions(-)

diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
index ce1bdb4..20c1fa6 100644
--- a/drivers/spi/spi-tegra210-quad.c
+++ b/drivers/spi/spi-tegra210-quad.c
@@ -21,6 +21,8 @@
 #include <linux/of_device.h>
 #include <linux/reset.h>
 #include <linux/spi/spi.h>
+#include <linux/acpi.h>
+#include <linux/property.h>
 
 #define QSPI_COMMAND1				0x000
 #define QSPI_BIT_LENGTH(x)			(((x) & 0x1f) << 0)
@@ -767,7 +769,7 @@ static u32 tegra_qspi_setup_transfer_one(struct spi_device *spi, struct spi_tran
 	u32 tx_tap = 0, rx_tap = 0;
 	int req_mode;
 
-	if (speed != tqspi->cur_speed) {
+	if (!has_acpi_companion(tqspi->dev) && speed != tqspi->cur_speed) {
 		clk_set_rate(tqspi->clk, speed);
 		tqspi->cur_speed = speed;
 	}
@@ -875,16 +877,15 @@ static int tegra_qspi_start_transfer_one(struct spi_device *spi,
 static struct tegra_qspi_client_data *tegra_qspi_parse_cdata_dt(struct spi_device *spi)
 {
 	struct tegra_qspi_client_data *cdata;
-	struct device_node *slave_np = spi->dev.of_node;
 
 	cdata = devm_kzalloc(&spi->dev, sizeof(*cdata), GFP_KERNEL);
 	if (!cdata)
 		return NULL;
 
-	of_property_read_u32(slave_np, "nvidia,tx-clk-tap-delay",
-			     &cdata->tx_clk_tap_delay);
-	of_property_read_u32(slave_np, "nvidia,rx-clk-tap-delay",
-			     &cdata->rx_clk_tap_delay);
+	device_property_read_u32(&spi->dev, "nvidia,tx-clk-tap-delay",
+				 &cdata->tx_clk_tap_delay);
+	device_property_read_u32(&spi->dev, "nvidia,rx-clk-tap-delay",
+				 &cdata->rx_clk_tap_delay);
 	return cdata;
 }
 
@@ -943,14 +944,27 @@ static void tegra_qspi_dump_regs(struct tegra_qspi *tqspi)
 		tegra_qspi_readl(tqspi, QSPI_FIFO_STATUS));
 }
 
+static void tegra_qspi_reset(struct tegra_qspi *tqspi)
+{
+	if (tqspi->rst) {
+		reset_control_assert(tqspi->rst);
+		udelay(2);
+		reset_control_deassert(tqspi->rst);
+		return;
+	}
+#ifdef CONFIG_ACPI
+	if (ACPI_FAILURE(acpi_evaluate_object(ACPI_HANDLE(tqspi->dev),
+					      "_RST", NULL, NULL)))
+		dev_err(tqspi->dev, "failed to reset device\n");
+#endif
+}
+
 static void tegra_qspi_handle_error(struct tegra_qspi *tqspi)
 {
 	dev_err(tqspi->dev, "error in transfer, fifo status 0x%08x\n", tqspi->status_reg);
 	tegra_qspi_dump_regs(tqspi);
 	tegra_qspi_flush_fifos(tqspi, true);
-	reset_control_assert(tqspi->rst);
-	udelay(2);
-	reset_control_deassert(tqspi->rst);
+	tegra_qspi_reset(tqspi);
 }
 
 static void tegra_qspi_transfer_end(struct spi_device *spi)
@@ -1202,6 +1216,14 @@ static const struct of_device_id tegra_qspi_of_match[] = {
 
 MODULE_DEVICE_TABLE(of, tegra_qspi_of_match);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id tegra_qspi_acpi_match[] = {
+	{ .id = "NVDA14E2", },
+	{}
+};
+MODULE_DEVICE_TABLE(acpi, tegra_qspi_acpi_match);
+#endif
+
 static int tegra_qspi_probe(struct platform_device *pdev)
 {
 	struct spi_master	*master;
@@ -1242,18 +1264,20 @@ static int tegra_qspi_probe(struct platform_device *pdev)
 	qspi_irq = platform_get_irq(pdev, 0);
 	tqspi->irq = qspi_irq;
 
-	tqspi->clk = devm_clk_get(&pdev->dev, "qspi");
-	if (IS_ERR(tqspi->clk)) {
-		ret = PTR_ERR(tqspi->clk);
-		dev_err(&pdev->dev, "failed to get clock: %d\n", ret);
-		return ret;
-	}
+	if (!has_acpi_companion(tqspi->dev)) {
+		tqspi->clk = devm_clk_get(&pdev->dev, "qspi");
+		if (IS_ERR(tqspi->clk)) {
+			ret = PTR_ERR(tqspi->clk);
+			dev_err(&pdev->dev, "failed to get clock: %d\n", ret);
+			return ret;
+		}
 
-	tqspi->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
-	if (IS_ERR(tqspi->rst)) {
-		ret = PTR_ERR(tqspi->rst);
-		dev_err(&pdev->dev, "failed to get reset control: %d\n", ret);
-		return ret;
+		tqspi->rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+		if (IS_ERR(tqspi->rst)) {
+			dev_err(&pdev->dev, "failed to get reset control: %d\n", ret);
+			ret = PTR_ERR(tqspi->rst);
+			return ret;
+		}
 	}
 
 	tqspi->max_buf_size = QSPI_FIFO_DEPTH << 2;
@@ -1277,9 +1301,7 @@ static int tegra_qspi_probe(struct platform_device *pdev)
 		goto exit_pm_disable;
 	}
 
-	reset_control_assert(tqspi->rst);
-	udelay(2);
-	reset_control_deassert(tqspi->rst);
+	tegra_qspi_reset(tqspi);
 
 	tqspi->def_command1_reg = QSPI_M_S | QSPI_CS_SW_HW |  QSPI_CS_SW_VAL;
 	tegra_qspi_writel(tqspi, tqspi->def_command1_reg, QSPI_COMMAND1);
@@ -1353,6 +1375,10 @@ static int __maybe_unused tegra_qspi_resume(struct device *dev)
 	return spi_master_resume(master);
 }
 
+#ifdef CONFIG_ACPI
+static int __maybe_unused tegra_qspi_runtime_suspend(struct device *dev) { return 0; }
+static int __maybe_unused tegra_qspi_runtime_resume(struct device *dev) { return 0; }
+#else
 static int __maybe_unused tegra_qspi_runtime_suspend(struct device *dev)
 {
 	struct spi_master *master = dev_get_drvdata(dev);
@@ -1378,6 +1404,7 @@ static int __maybe_unused tegra_qspi_runtime_resume(struct device *dev)
 
 	return ret;
 }
+#endif
 
 static const struct dev_pm_ops tegra_qspi_pm_ops = {
 	SET_RUNTIME_PM_OPS(tegra_qspi_runtime_suspend, tegra_qspi_runtime_resume, NULL)
@@ -1389,6 +1416,7 @@ static struct platform_driver tegra_qspi_driver = {
 		.name		= "tegra-qspi",
 		.pm		= &tegra_qspi_pm_ops,
 		.of_match_table	= tegra_qspi_of_match,
+		.acpi_match_table = ACPI_PTR(tegra_qspi_acpi_match),
 	},
 	.probe =	tegra_qspi_probe,
 	.remove =	tegra_qspi_remove,
-- 
2.7.4


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-25  9:55 ` [PATCH 2/2] spi: tegra210-quad: add acpi support Krishna Yarlagadda
@ 2021-11-25 12:59   ` Mark Brown
  2021-11-29  9:09     ` Krishna Yarlagadda
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Brown @ 2021-11-25 12:59 UTC (permalink / raw)
  To: Krishna Yarlagadda
  Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, Philipp Zabel, linux-tegra, linux-spi,
	linux-kernel

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

On Thu, Nov 25, 2021 at 03:25:52PM +0530, Krishna Yarlagadda wrote:

> +#ifdef CONFIG_ACPI
> +	if (ACPI_FAILURE(acpi_evaluate_object(ACPI_HANDLE(tqspi->dev),
> +					      "_RST", NULL, NULL)))
> +		dev_err(tqspi->dev, "failed to reset device\n");
> +#endif

What happens when this runs on a DT system?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: (subset) [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory
  2021-11-25  9:55 [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory Krishna Yarlagadda
  2021-11-25  9:55 ` [PATCH 2/2] spi: tegra210-quad: add acpi support Krishna Yarlagadda
@ 2021-11-27  1:30 ` Mark Brown
  1 sibling, 0 replies; 10+ messages in thread
From: Mark Brown @ 2021-11-27  1:30 UTC (permalink / raw)
  To: Jonathan Hunter, Krishna Yarlagadda, Sowjanya Komatineni,
	Thierry Reding, Laxman Dewangan
  Cc: linux-kernel, linux-tegra, linux-spi

On Thu, 25 Nov 2021 15:25:51 +0530, Krishna Yarlagadda wrote:
> Use devm alloc call to allocate memory for spi controller data and
> remove free calls from cleanup.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: tegra210-quad: use devm call for cdata memory
      commit: f89d2cc3967af9948ffc58e4cc9a1331f1c4971a

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-25 12:59   ` Mark Brown
@ 2021-11-29  9:09     ` Krishna Yarlagadda
  2021-11-29 12:27       ` Mark Brown
  0 siblings, 1 reply; 10+ messages in thread
From: Krishna Yarlagadda @ 2021-11-29  9:09 UTC (permalink / raw)
  To: Mark Brown
  Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, Philipp Zabel, linux-tegra, linux-spi,
	linux-kernel

> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: 25 November 2021 18:29
> To: Krishna Yarlagadda <kyarlagadda@nvidia.com>
> Cc: Laxman Dewangan <ldewangan@nvidia.com>; Thierry Reding
> <thierry.reding@gmail.com>; Jonathan Hunter <jonathanh@nvidia.com>;
> Sowjanya Komatineni <skomatineni@nvidia.com>; Philipp Zabel
> <p.zabel@pengutronix.de>; linux-tegra@vger.kernel.org; linux-
> spi@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
> 
> On Thu, Nov 25, 2021 at 03:25:52PM +0530, Krishna Yarlagadda wrote:
> 
> > +#ifdef CONFIG_ACPI
> > +	if (ACPI_FAILURE(acpi_evaluate_object(ACPI_HANDLE(tqspi->dev),
> > +					      "_RST", NULL, NULL)))
> > +		dev_err(tqspi->dev, "failed to reset device\n"); #endif
> 
> What happens when this runs on a DT system?
For a DT system reset handle would be present and this code will not run
-KY

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-29  9:09     ` Krishna Yarlagadda
@ 2021-11-29 12:27       ` Mark Brown
  2021-11-30  1:50         ` Krishna Yarlagadda
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Brown @ 2021-11-29 12:27 UTC (permalink / raw)
  To: Krishna Yarlagadda, Philipp Zabel
  Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, linux-tegra, linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Mon, Nov 29, 2021 at 09:09:30AM +0000, Krishna Yarlagadda wrote:

> > > +#ifdef CONFIG_ACPI
> > > +	if (ACPI_FAILURE(acpi_evaluate_object(ACPI_HANDLE(tqspi->dev),
> > > +					      "_RST", NULL, NULL)))
> > > +		dev_err(tqspi->dev, "failed to reset device\n"); #endif

> > What happens when this runs on a DT system?

> For a DT system reset handle would be present and this code will not run

This code is really unclearly structured, the early return doesn't
match the normal kernel style and the ifdefs aren't helping with
clarity.  Please restructure it so it's clear that *both* cases have
checks for the correct firmware type being present.

That said frankly I'd expect this handling of ACPI reset to be pushed
into the reset code, it's obviously not good to be open coding this in
drivers when this looks like it's completely generic to any ACPI object
so shouldn't be being open coded in individual driers especially with
the ifdefery.  Shouldn't the reset API be able to figure out that an
object with _RST has a reset control and provide access to it through
the reset API?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-29 12:27       ` Mark Brown
@ 2021-11-30  1:50         ` Krishna Yarlagadda
  2021-11-30 13:05           ` Mark Brown
  0 siblings, 1 reply; 10+ messages in thread
From: Krishna Yarlagadda @ 2021-11-30  1:50 UTC (permalink / raw)
  To: Mark Brown, Philipp Zabel
  Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, linux-tegra, linux-spi, linux-kernel

> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: 29 November 2021 17:57
> To: Krishna Yarlagadda <kyarlagadda@nvidia.com>; Philipp Zabel
> <p.zabel@pengutronix.de>
> Cc: Laxman Dewangan <ldewangan@nvidia.com>; Thierry Reding
> <thierry.reding@gmail.com>; Jonathan Hunter <jonathanh@nvidia.com>;
> Sowjanya Komatineni <skomatineni@nvidia.com>; linux-
> tegra@vger.kernel.org; linux-spi@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
> 
> On Mon, Nov 29, 2021 at 09:09:30AM +0000, Krishna Yarlagadda wrote:
> 
> > > > +#ifdef CONFIG_ACPI
> > > > +	if (ACPI_FAILURE(acpi_evaluate_object(ACPI_HANDLE(tqspi->dev),
> > > > +					      "_RST", NULL, NULL)))
> > > > +		dev_err(tqspi->dev, "failed to reset device\n"); #endif
> 
> > > What happens when this runs on a DT system?
> 
> > For a DT system reset handle would be present and this code will not
> > run
> 
> This code is really unclearly structured, the early return doesn't match the
> normal kernel style and the ifdefs aren't helping with clarity.  Please
> restructure it so it's clear that *both* cases have checks for the correct
> firmware type being present.
I will move each reset method into their own function for readability.
> 
> That said frankly I'd expect this handling of ACPI reset to be pushed into the
> reset code, it's obviously not good to be open coding this in drivers when this
> looks like it's completely generic to any ACPI object so shouldn't be being
> open coded in individual driers especially with the ifdefery.  Shouldn't the
> reset API be able to figure out that an object with _RST has a reset control
> and provide access to it through the reset API?
Common reset apis are not handling _RST. Each driver is implementing
_RST method in ACPI and calling from drivers.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-30  1:50         ` Krishna Yarlagadda
@ 2021-11-30 13:05           ` Mark Brown
  2021-11-30 14:14             ` Dmitry Osipenko
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Brown @ 2021-11-30 13:05 UTC (permalink / raw)
  To: Krishna Yarlagadda
  Cc: Philipp Zabel, Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, linux-tegra, linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Tue, Nov 30, 2021 at 01:50:07AM +0000, Krishna Yarlagadda wrote:

> > That said frankly I'd expect this handling of ACPI reset to be pushed into the
> > reset code, it's obviously not good to be open coding this in drivers when this
> > looks like it's completely generic to any ACPI object so shouldn't be being
> > open coded in individual driers especially with the ifdefery.  Shouldn't the
> > reset API be able to figure out that an object with _RST has a reset control
> > and provide access to it through the reset API?

> Common reset apis are not handling _RST. Each driver is implementing
> _RST method in ACPI and calling from drivers.

I can see that.  What I'm saying is that this seems bad and we should
instead be implementing this in common code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-30 13:05           ` Mark Brown
@ 2021-11-30 14:14             ` Dmitry Osipenko
  2021-11-30 16:13               ` Mark Brown
  0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Osipenko @ 2021-11-30 14:14 UTC (permalink / raw)
  To: Mark Brown, Krishna Yarlagadda
  Cc: Philipp Zabel, Laxman Dewangan, Thierry Reding, Jonathan Hunter,
	Sowjanya Komatineni, linux-tegra, linux-spi, linux-kernel

30.11.2021 16:05, Mark Brown пишет:
> On Tue, Nov 30, 2021 at 01:50:07AM +0000, Krishna Yarlagadda wrote:
> 
>>> That said frankly I'd expect this handling of ACPI reset to be pushed into the
>>> reset code, it's obviously not good to be open coding this in drivers when this
>>> looks like it's completely generic to any ACPI object so shouldn't be being
>>> open coded in individual driers especially with the ifdefery.  Shouldn't the
>>> reset API be able to figure out that an object with _RST has a reset control
>>> and provide access to it through the reset API?
> 
>> Common reset apis are not handling _RST. Each driver is implementing
>> _RST method in ACPI and calling from drivers.

I see only two or three other drivers in kernel which do that.

> I can see that.  What I'm saying is that this seems bad and we should
> instead be implementing this in common code.
> 

The ifdefery, that this patch has, shouldn't be needed. We have a
similar ACPI patch for Tegra I2C [1] and it doesn't have that.

[1]
https://patchwork.ozlabs.org/project/linux-tegra/patch/1637859224-5179-1-git-send-email-akhilrajeev@nvidia.com/

I assume this patch could be reworked similarly to the I2C patch.

Agree that should be better to have a common reset driver for ACPI
instead of polluting each driver with a boilerplate code.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] spi: tegra210-quad: add acpi support
  2021-11-30 14:14             ` Dmitry Osipenko
@ 2021-11-30 16:13               ` Mark Brown
  0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2021-11-30 16:13 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: Krishna Yarlagadda, Philipp Zabel, Laxman Dewangan,
	Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
	linux-tegra, linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

On Tue, Nov 30, 2021 at 05:14:07PM +0300, Dmitry Osipenko wrote:

> The ifdefery, that this patch has, shouldn't be needed. We have a
> similar ACPI patch for Tegra I2C [1] and it doesn't have that.

> [1]
> https://patchwork.ozlabs.org/project/linux-tegra/patch/1637859224-5179-1-git-send-email-akhilrajeev@nvidia.com/

> I assume this patch could be reworked similarly to the I2C patch.

Yes, that looks much cleaner.

> Agree that should be better to have a common reset driver for ACPI
> instead of polluting each driver with a boilerplate code.

Right, I think that'd be even better.  It's probably best to split
adding reset support to the driver out from adding the ACPI ID - they
shouldn't really have been merged in the first place TBH - and then try
this approach first.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-11-30 16:13 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-25  9:55 [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory Krishna Yarlagadda
2021-11-25  9:55 ` [PATCH 2/2] spi: tegra210-quad: add acpi support Krishna Yarlagadda
2021-11-25 12:59   ` Mark Brown
2021-11-29  9:09     ` Krishna Yarlagadda
2021-11-29 12:27       ` Mark Brown
2021-11-30  1:50         ` Krishna Yarlagadda
2021-11-30 13:05           ` Mark Brown
2021-11-30 14:14             ` Dmitry Osipenko
2021-11-30 16:13               ` Mark Brown
2021-11-27  1:30 ` (subset) [PATCH 1/2] spi: tegra210-quad: use devm call for cdata memory Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).