[PATCH v1 0/3] drm/panel: ili9341: Obvious fixes

[PATCH v1 0/3] drm/panel: ili9341: Obvious fixes

[Andy Shevchenko]

A few obvious fixes to the driver.

Andy Shevchenko (3):
  drm/panel: ili9341: Correct use of device property APIs
  drm/panel: ili9341: Respect deferred probe
  drm/panel: ili9341: Use predefined error codes

 drivers/gpu/drm/panel/Kconfig                |  2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 13 +++++++------
 2 files changed, 8 insertions(+), 7 deletions(-)

-- 
2.43.0.rc1.1336.g36b5255a03ac

[PATCH v1 1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

It seems driver missed the point of proper use of device property APIs.
Correct this by updating headers and calls respectively.

Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/panel/Kconfig                | 2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index e54f6f5604ed..2d4515555820 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -177,7 +177,7 @@ config DRM_PANEL_ILITEK_IL9322
 
 config DRM_PANEL_ILITEK_ILI9341
 	tristate "Ilitek ILI9341 240x320 QVGA panels"
-	depends on OF && SPI
+	depends on SPI
 	select DRM_KMS_HELPER
 	select DRM_GEM_DMA_HELPER
 	depends on BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 3574681891e8..7584ddb0e441 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -22,8 +22,9 @@
 #include <linux/bitops.h>
 #include <linux/delay.h>
 #include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
 #include <linux/module.h>
-#include <linux/of.h>
+#include <linux/property.h>
 #include <linux/regulator/consumer.h>
 #include <linux/spi/spi.h>
 
@@ -691,7 +692,7 @@ static int ili9341_dpi_probe(struct spi_device *spi, struct gpio_desc *dc,
 	 * Every new incarnation of this display must have a unique
 	 * data entry for the system in this driver.
 	 */
-	ili->conf = of_device_get_match_data(dev);
+	ili->conf = device_get_match_data(dev);
 	if (!ili->conf) {
 		dev_err(dev, "missing device configuration\n");
 		return -ENODEV;
-- 
2.43.0.rc1.1336.g36b5255a03ac

[PATCH v1 2/3] drm/panel: ili9341: Respect deferred probe

[Andy Shevchenko]

GPIO controller might not be available when driver is being probed.
There are plenty of reasons why, one of which is deferred probe.

Since GPIOs are optional, return any error code we got to the upper
layer, including deferred probe. With that in mind, use dev_err_probe()
in order to avoid spamming the logs.

Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 7584ddb0e441..24c74c56e564 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -715,11 +715,11 @@ static int ili9341_probe(struct spi_device *spi)
 
 	reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
 	if (IS_ERR(reset))
-		dev_err(dev, "Failed to get gpio 'reset'\n");
+		return dev_err_probe(dev, PTR_ERR(reset), "Failed to get gpio 'reset'\n");
 
 	dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
 	if (IS_ERR(dc))
-		dev_err(dev, "Failed to get gpio 'dc'\n");
+		return dev_err_probe(dev, PTR_ERR(dc), "Failed to get gpio 'dc'\n");
 
 	if (!strcmp(id->name, "sf-tc240t-9370-t"))
 		return ili9341_dpi_probe(spi, dc, reset);
-- 
2.43.0.rc1.1336.g36b5255a03ac

[PATCH v1 3/3] drm/panel: ili9341: Use predefined error codes

[Andy Shevchenko]

In one case the -1 is returned which is quite confusing code for
the wrong device ID, in another the ret is returning instead of
plain 0 that also confusing as readed may ask the possible meaning
of positive codes, which are never the case there. Convert both
to use explicit predefined error codes to make it clear what's going
on there.

Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 24c74c56e564..b933380b7eb7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -422,7 +422,7 @@ static int ili9341_dpi_prepare(struct drm_panel *panel)
 
 	ili9341_dpi_init(ili);
 
-	return ret;
+	return 0;
 }
 
 static int ili9341_dpi_enable(struct drm_panel *panel)
@@ -726,7 +726,7 @@ static int ili9341_probe(struct spi_device *spi)
 	else if (!strcmp(id->name, "yx240qv29"))
 		return ili9341_dbi_probe(spi, dc, reset);
 
-	return -1;
+	return -ENODEV;
 }
 
 static void ili9341_remove(struct spi_device *spi)
-- 
2.43.0.rc1.1336.g36b5255a03ac

Re: [PATCH v1 0/3] drm/panel: ili9341: Obvious fixes

[Andy Shevchenko]

On Thu, Apr 25, 2024 at 05:26:16PM +0300, Andy Shevchenko wrote:
> A few obvious fixes to the driver.

Note, despite the desire of removal Adafruit support from this driver,
the older (read: stable) kernels will need this.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] drm/panel: ili9341: Correct use of device property APIs

[Neil Armstrong]

On 25/04/2024 16:26, Andy Shevchenko wrote:
> It seems driver missed the point of proper use of device property APIs.
> Correct this by updating headers and calls respectively.
> 
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>   drivers/gpu/drm/panel/Kconfig                | 2 +-
>   drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 5 +++--
>   2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index e54f6f5604ed..2d4515555820 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -177,7 +177,7 @@ config DRM_PANEL_ILITEK_IL9322
>   
>   config DRM_PANEL_ILITEK_ILI9341
>   	tristate "Ilitek ILI9341 240x320 QVGA panels"
> -	depends on OF && SPI
> +	depends on SPI
>   	select DRM_KMS_HELPER
>   	select DRM_GEM_DMA_HELPER
>   	depends on BACKLIGHT_CLASS_DEVICE
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index 3574681891e8..7584ddb0e441 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -22,8 +22,9 @@
>   #include <linux/bitops.h>
>   #include <linux/delay.h>
>   #include <linux/gpio/consumer.h>
> +#include <linux/mod_devicetable.h>
>   #include <linux/module.h>
> -#include <linux/of.h>
> +#include <linux/property.h>
>   #include <linux/regulator/consumer.h>
>   #include <linux/spi/spi.h>
>   
> @@ -691,7 +692,7 @@ static int ili9341_dpi_probe(struct spi_device *spi, struct gpio_desc *dc,
>   	 * Every new incarnation of this display must have a unique
>   	 * data entry for the system in this driver.
>   	 */
> -	ili->conf = of_device_get_match_data(dev);
> +	ili->conf = device_get_match_data(dev);
>   	if (!ili->conf) {
>   		dev_err(dev, "missing device configuration\n");
>   		return -ENODEV;

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Re: [PATCH v1 2/3] drm/panel: ili9341: Respect deferred probe

[Neil Armstrong]

On 25/04/2024 16:26, Andy Shevchenko wrote:
> GPIO controller might not be available when driver is being probed.
> There are plenty of reasons why, one of which is deferred probe.
> 
> Since GPIOs are optional, return any error code we got to the upper
> layer, including deferred probe. With that in mind, use dev_err_probe()
> in order to avoid spamming the logs.
> 
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>   drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index 7584ddb0e441..24c74c56e564 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -715,11 +715,11 @@ static int ili9341_probe(struct spi_device *spi)
>   
>   	reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
>   	if (IS_ERR(reset))
> -		dev_err(dev, "Failed to get gpio 'reset'\n");
> +		return dev_err_probe(dev, PTR_ERR(reset), "Failed to get gpio 'reset'\n");
>   
>   	dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
>   	if (IS_ERR(dc))
> -		dev_err(dev, "Failed to get gpio 'dc'\n");
> +		return dev_err_probe(dev, PTR_ERR(dc), "Failed to get gpio 'dc'\n");
>   
>   	if (!strcmp(id->name, "sf-tc240t-9370-t"))
>   		return ili9341_dpi_probe(spi, dc, reset);

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Re: [PATCH v1 3/3] drm/panel: ili9341: Use predefined error codes

[Neil Armstrong]

On 25/04/2024 16:26, Andy Shevchenko wrote:
> In one case the -1 is returned which is quite confusing code for
> the wrong device ID, in another the ret is returning instead of
> plain 0 that also confusing as readed may ask the possible meaning
> of positive codes, which are never the case there. Convert both
> to use explicit predefined error codes to make it clear what's going
> on there.
> 
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>   drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index 24c74c56e564..b933380b7eb7 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -422,7 +422,7 @@ static int ili9341_dpi_prepare(struct drm_panel *panel)
>   
>   	ili9341_dpi_init(ili);
>   
> -	return ret;
> +	return 0;
>   }
>   
>   static int ili9341_dpi_enable(struct drm_panel *panel)
> @@ -726,7 +726,7 @@ static int ili9341_probe(struct spi_device *spi)
>   	else if (!strcmp(id->name, "yx240qv29"))
>   		return ili9341_dbi_probe(spi, dc, reset);
>   
> -	return -1;
> +	return -ENODEV;
>   }
>   
>   static void ili9341_remove(struct spi_device *spi)

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/25 22:26, Andy Shevchenko wrote:
> It seems driver missed the point of proper use of device property APIs.
> Correct this by updating headers and calls respectively.

You are using the 'seems' here exactly saying that you are not 100% sure.

Please allow me to tell you the truth: This patch again has ZERO effect.
It fix nothing. And this patch is has the risks to be wrong.

Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
is DT dependent.

First of all, the devm_of_find_backlight() is called in ili9341_dbi_probe()
under *non-DT* environment, devm_of_find_backlight() is just a just a
no-op and will return NULL. NULL is not an error code, so ili9341_dbi_probe()
won't rage quit. But the several side effect is that the backlight will
NOT works at all.

It is actually considered as fatal bug for *panels* if the backlight of
it is not light up, at least the brightness of *won't* be able to adjust.
What's worse, if there is no sane platform setup code at the firmware
or boot loader stage to set a proper initial state. The screen is complete
dark. Even though the itself panel is refreshing framebuffers, it can not
be seen by human's eye. Simple because of no backlight.
   
Second, the ili9341_dbi_probe() requires additional device properties to
be able to works very well on the rotation screen case. See the calling
of "device_property_read_u32(dev, "rotation", &rotation)" in
ili9341_dbi_probe() function.

Combine with those two factors, it is actually can conclude that the
panel-ilitek-ili9394 driver has the *implicit* dependency on 'OF'.
Removing the 'OF' dependency from its Kconfig just trigger the
leakage of such risks.
  
My software node related patches can help to reduce part of the potential
risks, but it still need some extra work. And it is not landed yet.


> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
>   drivers/gpu/drm/panel/Kconfig                | 2 +-
>   drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 5 +++--
>   2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index e54f6f5604ed..2d4515555820 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -177,7 +177,7 @@ config DRM_PANEL_ILITEK_IL9322
>   
>   config DRM_PANEL_ILITEK_ILI9341
>   	tristate "Ilitek ILI9341 240x320 QVGA panels"
> -	depends on OF && SPI
> +	depends on SPI
>   	select DRM_KMS_HELPER
>   	select DRM_GEM_DMA_HELPER
>   	depends on BACKLIGHT_CLASS_DEVICE
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index 3574681891e8..7584ddb0e441 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -22,8 +22,9 @@
>   #include <linux/bitops.h>
>   #include <linux/delay.h>
>   #include <linux/gpio/consumer.h>
> +#include <linux/mod_devicetable.h>
>   #include <linux/module.h>
> -#include <linux/of.h>
> +#include <linux/property.h>
>   #include <linux/regulator/consumer.h>
>   #include <linux/spi/spi.h>
>   
> @@ -691,7 +692,7 @@ static int ili9341_dpi_probe(struct spi_device *spi, struct gpio_desc *dc,
>   	 * Every new incarnation of this display must have a unique
>   	 * data entry for the system in this driver.
>   	 */
> -	ili->conf = of_device_get_match_data(dev);
> +	ili->conf = device_get_match_data(dev);
>   	if (!ili->conf) {
>   		dev_err(dev, "missing device configuration\n");
>   		return -ENODEV;

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/26 02:08, Sui Jingfeng wrote:
> Hi,
>
>
> On 2024/4/25 22:26, Andy Shevchenko wrote:
>> It seems driver missed the point of proper use of device property APIs.
>> Correct this by updating headers and calls respectively.
>
> You are using the 'seems' here exactly saying that you are not 100% sure.
>
Using the word 'seems' here exactly saying that you are not 100% sure.


> And this patch is has the risks to be wrong.
>
This patch has the risks of to be wrong.


> Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
> is DT dependent.
>
Simply because part of the driver is DT dependent, plus its code(implementation)
is deep(tight) coupling, as a result, it is became total DT dependent.


> First of all, the devm_of_find_backlight() is called in 
> ili9341_dbi_probe()
,
> under *non-DT* environment, 

Under *non-DT* environment, the use case probably should take into consideration.
Since you remove it, then we can't stop imagining. But if we really care about
the usage case on DT based systems, There is *NO* difference between the
device_get_match_data() and the of_device_get_match_data(). This is the reason
why I'm saying that you patch has the *ZERO* effects.

And again, on non-DT systems, if there is no acpi_device_id stuff, calling
the device_get_match_data() function will just get NULL. Which is nearly a
undefined behavior. So the 'OF 'removal is don't really make much sense.

But there is a way to save the awkward situation, that is, helps to get
this patch[1] merged. Then we still tenable both at the practice side
and at the concept side.
  

[1] https://patchwork.freedesktop.org/patch/590653/?series=131296&rev=2

> devm_of_find_backlight() is just a just a  no-op and will return NULL. 
> NULL is not an error code, so ili9341_dbi_probe()
> won't rage quit. 

[...]

> But the several side effect is that the backlight will NOT works at all.
>
s/several/severe


> It is actually considered as fatal bug for *panels* if the backlight of
> it is not light up, 


It's fatal error if backlight is not adjustable or not light-up at all.


>

[...]


> Even though the itself panel is refreshing framebuffers, 

Even though the panel itself is consuming frame-buffers and displaying.
But if the backlight not work, the screen is extremely dark, we can not
see as well.

Besides the ili9341_dbi_probe() requires additional device properties to
able to work very well. Especially on the rotate screen use case.

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> On 2024/4/25 22:26, Andy Shevchenko wrote:
> > It seems driver missed the point of proper use of device property APIs.
> > Correct this by updating headers and calls respectively.
> 
> You are using the 'seems' here exactly saying that you are not 100% sure.
> 
> Please allow me to tell you the truth: This patch again has ZERO effect.
> It fix nothing. And this patch is has the risks to be wrong.

Huh?! Really, stop commenting the stuff you do not understand.

> Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
> is DT dependent.
> 
> First of all, the devm_of_find_backlight() is called in ili9341_dbi_probe()
> under *non-DT* environment, devm_of_find_backlight() is just a just a
> no-op and will return NULL. NULL is not an error code, so ili9341_dbi_probe()
> won't rage quit. But the several side effect is that the backlight will
> NOT works at all.

Is it a problem?

> It is actually considered as fatal bug for *panels* if the backlight of
> it is not light up, at least the brightness of *won't* be able to adjust.
> What's worse, if there is no sane platform setup code at the firmware
> or boot loader stage to set a proper initial state. The screen is complete
> dark. Even though the itself panel is refreshing framebuffers, it can not
> be seen by human's eye. Simple because of no backlight.

Can you imagine that I may have different hardware that considered
this is non-fatal error?

> Second, the ili9341_dbi_probe() requires additional device properties to
> be able to works very well on the rotation screen case. See the calling
> of "device_property_read_u32(dev, "rotation", &rotation)" in
> ili9341_dbi_probe() function.

Yes, exactly, and how does it object the purpose of this patch?

> Combine with those two factors, it is actually can conclude that the
> panel-ilitek-ili9394 driver has the *implicit* dependency on 'OF'.
> Removing the 'OF' dependency from its Kconfig just trigger the
> leakage of such risks.

What?!

> My software node related patches can help to reduce part of the potential
> risks, but it still need some extra work. And it is not landed yet.

Your patch has nothing to do with this series.

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 02:08, Sui Jingfeng wrote:

Are you speaking to yourself? I'm totally lost.

Please, if you want to give a constructive feedback, try to understand
the topic from different aspects and then clearly express it.

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/26 03:10, Andy Shevchenko wrote:
> On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
>> On 2024/4/25 22:26, Andy Shevchenko wrote:
>>> It seems driver missed the point of proper use of device property APIs.
>>> Correct this by updating headers and calls respectively.
>> You are using the 'seems' here exactly saying that you are not 100% sure.
>>
>> Please allow me to tell you the truth: This patch again has ZERO effect.
>> It fix nothing. And this patch is has the risks to be wrong.
> Huh?! Really, stop commenting the stuff you do not understand.


I'm actually a professional display drivers developer at the downstream
in the past, despite my contribution to upstream is less. But I believe
that all panel driver developers know what I'm talking about. So please
have take a look at my replies.


>> Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
>> is DT dependent.
>>
>> First of all, the devm_of_find_backlight() is called in ili9341_dbi_probe()
>> under *non-DT* environment, devm_of_find_backlight() is just a just a
>> no-op and will return NULL. NULL is not an error code, so ili9341_dbi_probe()
>> won't rage quit. But the several side effect is that the backlight will
>> NOT works at all.
> Is it a problem?

Yes, it is.
  

The core problem is that the driver you are modifying has *implicit* *dependency* on DT.
The implicit dependency is due to the calling of devm_of_find_backlight(). This function
is a no-op under non-DT systems. Therefore, before the devm_of_find_backlight() and
the device_get_match_data() function can truly DT independent.

Removing the "OF" dependency just let the tigers run out from the jail.

It is not really meant to targeting at you, but I thinks, all of drm_panel drivers
that has the devm_of_find_backlight() invoked will suffer such concerns.
In short, the reason is that the *implicit* *dependency* populates and
the undefined behavior gets triggered.


I'm sure you know that device_get_match_data() is same with of_device_get_match_data()
for DT based systems. For non DT based systems, device_get_match_data() is just *undefined*
Note that ACPI is not in the scope of the discussion here, as all of the drm bridges and
panels driver under drivers/gpu/drm/ hasn't the ACPI support yet. Therefore, at present,
it safe to say that device_get_match_data() is *undefined* under no-DT environment.

Removing the "OF" dependency hints to us that it allows the driver to be probed as a
pure SPI device under non DT systems. When device_get_match_data() is called, it returns
NULL to us now. As a result, the drm driver being modified will tears down.

See bellow code snippet extracted frompanel-ilitek-ili9341.c:


```
	ili->conf = of_device_get_match_data(dev);
	if (!ili->conf) {
		dev_err(dev, "missing device configuration\n");
		return -ENODEV;
	}
```

>> It is actually considered as fatal bug for *panels* if the backlight of
>> it is not light up, at least the brightness of *won't* be able to adjust.
>> What's worse, if there is no sane platform setup code at the firmware
>> or boot loader stage to set a proper initial state. The screen is complete
>> dark. Even though the itself panel is refreshing framebuffers, it can not
>> be seen by human's eye. Simple because of no backlight.
> Can you imagine that I may have different hardware that considered
> this is non-fatal error?
>
Yes, I can imagine.

I believe you have the hardware which make you patch correct to run
in 99.9% of all cases. But as long as there one bug happened, you patch
are going to be blamed.

Because its your patch that open the door, both from the perceptive of
practice and from the perceptive of the concept (static analysis).

>> Second, the ili9341_dbi_probe() requires additional device properties to
>> be able to works very well on the rotation screen case. See the calling
>> of "device_property_read_u32(dev, "rotation", &rotation)" in
>> ili9341_dbi_probe() function.
> Yes, exactly, and how does it object the purpose of this patch?

Because under *non-DT* environment, your commit message do not give a
valid description, how does the additional device property can be acquired
is not demonstrated.

And it is exactly your patch open the non-DT code path (way or possibility).
It isn't has such risks before your patch is applied. In other words,
previously, the driver has the 'OF' dependency as the guard, all of the
potential risk(or problem) are suppressed. It is a extremely safe policy,
and it is also a extremely perfect defend.

And suddenly, you patch release the dangerous tiger from the cage.
So I think you can imagine...

>> Combine with those two factors, it is actually can conclude that the
>> panel-ilitek-ili9394 driver has the *implicit* dependency on 'OF'.
>> Removing the 'OF' dependency from its Kconfig just trigger the
>> leakage of such risks.
> What?!
>
Posting a patch is actually doing the defensive works, such a saying
may not sound fair for you, but this is just the hash cruel reality.
Sorry for saying that. :(


>> My software node related patches can help to reduce part of the potential
>> risks, but it still need some extra work. And it is not landed yet.
> Your patch has nothing to do with this series.

With my patch applied, this is way to meet the gap under non-DT systems.
Users of this driver could managed to attach(complete) absent properties
to the SPI device with software node properties. Register the swnode
properties group into the system prior the panel driver is probed. There
may need some quirk. But at the least there has a way to go.  When there
has a way to go, things become self-consistent. Viewed from both the
practice of viewpoint and the concept of viewpoint.

And the dangerous tiger will steer its way to the direction of "ACPI
support is missing". But both of will be safe then.

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/26 03:12, Andy Shevchenko wrote:
> On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
>> On 2024/4/26 02:08, Sui Jingfeng wrote:
> Are you speaking to yourself? I'm totally lost.
>
> Please, if you want to give a constructive feedback, try to understand
> the topic from different aspects and then clearly express it.
>

OK,

The previous email analysis the non-DT cases exhaustively, this email intend to
demonstrate the more frequently use case.

That is, in the *DT('OF')* based systems,
device_get_match_data() is completely equivalent to 
of_device_get_match_data().
So the net results of applying this patch are "no gains and no lost".

Things will become clear if we divide the whole problem into two cases(DT and non-DT)
to discuss, that's it. That's all I can tell.

Sorry about my broken written and sorry for the noise. Thanks for your education in
the past.

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

On 2024/4/26 04:43, Sui Jingfeng wrote:
> But both of will be safe then. 

But both of us will be safe then.

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Maxime Ripard]

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

Hi,

On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:10, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > It seems driver missed the point of proper use of device property APIs.
> > > > Correct this by updating headers and calls respectively.
> > > You are using the 'seems' here exactly saying that you are not 100% sure.
> > > 
> > > Please allow me to tell you the truth: This patch again has ZERO effect.
> > > It fix nothing. And this patch is has the risks to be wrong.
> > Huh?! Really, stop commenting the stuff you do not understand.
> 
> I'm actually a professional display drivers developer at the downstream
> in the past, despite my contribution to upstream is less. But I believe
> that all panel driver developers know what I'm talking about. So please
> have take a look at my replies.

Most of the interactions you had in this series has been uncalled for.
You might be against a patch, but there's no need to go to such length.

As far as I'm concerned, this patch is fine to me in itself, and I don't
see anything that would prevent us from merging it.

Maxime

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

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/26 14:23, Maxime Ripard wrote:
> Hi,
>
> On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
>> On 2024/4/26 03:10, Andy Shevchenko wrote:
>>> On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
>>>> On 2024/4/25 22:26, Andy Shevchenko wrote:
>>>>> It seems driver missed the point of proper use of device property APIs.
>>>>> Correct this by updating headers and calls respectively.
>>>> You are using the 'seems' here exactly saying that you are not 100% sure.
>>>>
>>>> Please allow me to tell you the truth: This patch again has ZERO effect.
>>>> It fix nothing. And this patch is has the risks to be wrong.
>>> Huh?! Really, stop commenting the stuff you do not understand.
>> I'm actually a professional display drivers developer at the downstream
>> in the past, despite my contribution to upstream is less. But I believe
>> that all panel driver developers know what I'm talking about. So please
>> have take a look at my replies.
> Most of the interactions you had in this series has been uncalled for.
> You might be against a patch, but there's no need to go to such length.
>
> As far as I'm concerned, this patch is fine to me in itself, and I don't
> see anything that would prevent us from merging it.

No one is preventing you, as long as don't misunderstanding what other
people's technical replies intentionally. I'm just a usual and normal
contributor, I hope the world will better than yesterday. Saying such
thing to me may not proper, I guess you may want to talk to peoples
who has the push rights, just make sure it isn't a insult to the
professionalism of drm bridge community itself though.

We still grateful for you help and admire you numerous contribution,
thanks.

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Maxime Ripard]

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

On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
> Hi,
> 
> 
> On 2024/4/26 14:23, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 03:10, Andy Shevchenko wrote:
> > > > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > > > It seems driver missed the point of proper use of device property APIs.
> > > > > > Correct this by updating headers and calls respectively.
> > > > > You are using the 'seems' here exactly saying that you are not 100% sure.
> > > > > 
> > > > > Please allow me to tell you the truth: This patch again has ZERO effect.
> > > > > It fix nothing. And this patch is has the risks to be wrong.
> > > > Huh?! Really, stop commenting the stuff you do not understand.
> > > I'm actually a professional display drivers developer at the downstream
> > > in the past, despite my contribution to upstream is less. But I believe
> > > that all panel driver developers know what I'm talking about. So please
> > > have take a look at my replies.
> > Most of the interactions you had in this series has been uncalled for.
> > You might be against a patch, but there's no need to go to such length.
> > 
> > As far as I'm concerned, this patch is fine to me in itself, and I don't
> > see anything that would prevent us from merging it.
> 
> No one is preventing you, as long as don't misunderstanding what other
> people's technical replies intentionally. I'm just a usual and normal
> contributor, I hope the world will better than yesterday.

You should seriously consider your tone when replying then.

> Saying such thing to me may not proper, I guess you may want to talk
> to peoples who has the push rights

I think you misunderstood me. My point was that your several rants were
uncalled for and aren't the kind of things we're doing here.

I know very well how to get a patch merged, thanks.

> just make sure it isn't a insult to the professionalism of drm bridge
> community itself though.

I'm not sure why you're bringing the bridge community or its
professionalism. It's a panel, not a bridge, and I never doubted the
professionalism of anyone.

Maxime

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

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/29 19:55, Maxime Ripard wrote:
> On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
>> Hi,
>>
>>
>> On 2024/4/26 14:23, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
>>>> On 2024/4/26 03:10, Andy Shevchenko wrote:
>>>>> On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
>>>>>> On 2024/4/25 22:26, Andy Shevchenko wrote:
>>>>>>> It seems driver missed the point of proper use of device property APIs.
>>>>>>> Correct this by updating headers and calls respectively.
>>>>>> You are using the 'seems' here exactly saying that you are not 100% sure.
>>>>>>
>>>>>> Please allow me to tell you the truth: This patch again has ZERO effect.
>>>>>> It fix nothing. And this patch is has the risks to be wrong.
>>>>> Huh?! Really, stop commenting the stuff you do not understand.
>>>> I'm actually a professional display drivers developer at the downstream
>>>> in the past, despite my contribution to upstream is less. But I believe
>>>> that all panel driver developers know what I'm talking about. So please
>>>> have take a look at my replies.
>>> Most of the interactions you had in this series has been uncalled for.
>>> You might be against a patch, but there's no need to go to such length.
>>>
>>> As far as I'm concerned, this patch is fine to me in itself, and I don't
>>> see anything that would prevent us from merging it.
>> No one is preventing you, as long as don't misunderstanding what other
>> people's technical replies intentionally. I'm just a usual and normal
>> contributor, I hope the world will better than yesterday.
> You should seriously consider your tone when replying then.
>
>> Saying such thing to me may not proper, I guess you may want to talk
>> to peoples who has the push rights
> I think you misunderstood me. My point was that your several rants were
> uncalled for and aren't the kind of things we're doing here.
>
> I know very well how to get a patch merged, thanks.
>
>> just make sure it isn't a insult to the professionalism of drm bridge
>> community itself though.
> I'm not sure why you're bringing the bridge community or its
> professionalism. It's a panel, not a bridge, and I never doubted the
> professionalism of anyone.


I means that the code itself could be adopted, as newer and younger
programmer (like Andy) need to be encouraged to contribute. I express
no obvious objections, just hints him that something else probably
should also be taken into consideration as well.

On the other hand, we probably should allow other people participate
in discussion so that it is sufficient discussed and ensure that it
won't be reverted by someone in the future for some reasons. Backing
to out case happens here, we may need to move things forward. Therefore,
it definitely deserve to have a try. It is not a big deal even though
it gets reverted someday.

In the end, I don't mind if you think there is nothing that could
prevent you from merge it, but I still suggest you have a glance at
peoples siting at the Cc list. I'm busy now and I have a lot of other
tasks to do, and may not be able to reply you emails on time. So it up
to you and other maintainers to decide.
  
Thank you.

> Maxime

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Maxime Ripard]

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

On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
> On 2024/4/29 19:55, Maxime Ripard wrote:
> > On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 14:23, Maxime Ripard wrote:
> > > > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> > > > > On 2024/4/26 03:10, Andy Shevchenko wrote:
> > > > > > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > > > > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > > > > > It seems driver missed the point of proper use of device property APIs.
> > > > > > > > Correct this by updating headers and calls respectively.
> > > > > > > You are using the 'seems' here exactly saying that you are not 100% sure.
> > > > > > > 
> > > > > > > Please allow me to tell you the truth: This patch again has ZERO effect.
> > > > > > > It fix nothing. And this patch is has the risks to be wrong.
> > > > > > Huh?! Really, stop commenting the stuff you do not understand.
> > > > > I'm actually a professional display drivers developer at the downstream
> > > > > in the past, despite my contribution to upstream is less. But I believe
> > > > > that all panel driver developers know what I'm talking about. So please
> > > > > have take a look at my replies.
> > > > Most of the interactions you had in this series has been uncalled for.
> > > > You might be against a patch, but there's no need to go to such length.
> > > > 
> > > > As far as I'm concerned, this patch is fine to me in itself, and I don't
> > > > see anything that would prevent us from merging it.
> > > No one is preventing you, as long as don't misunderstanding what other
> > > people's technical replies intentionally. I'm just a usual and normal
> > > contributor, I hope the world will better than yesterday.
> > You should seriously consider your tone when replying then.
> > 
> > > Saying such thing to me may not proper, I guess you may want to talk
> > > to peoples who has the push rights
> > I think you misunderstood me. My point was that your several rants were
> > uncalled for and aren't the kind of things we're doing here.
> > 
> > I know very well how to get a patch merged, thanks.
> > 
> > > just make sure it isn't a insult to the professionalism of drm bridge
> > > community itself though.
> > I'm not sure why you're bringing the bridge community or its
> > professionalism. It's a panel, not a bridge, and I never doubted the
> > professionalism of anyone.
> 
> 
> I means that the code itself could be adopted, as newer and younger
> programmer (like Andy) need to be encouraged to contribute.

Andy has thousands of commits in Linux. He's *very* far from being a new
contributor.

> I express no obvious objections, just hints him that something else
> probably should also be taken into consideration as well.

That might be what you wanted to express, but you definitely didn't
express it that way.

> On the other hand, we probably should allow other people participate
> in discussion so that it is sufficient discussed and ensure that it
> won't be reverted by someone in the future for some reasons. Backing
> to out case happens here, we may need to move things forward. Therefore,
> it definitely deserve to have a try. It is not a big deal even though
> it gets reverted someday.
> 
> In the end, I don't mind if you think there is nothing that could
> prevent you from merge it, but I still suggest you have a glance at
> peoples siting at the Cc list. I'm busy now and I have a lot of other
> tasks to do, and may not be able to reply you emails on time. So it up
> to you and other maintainers to decide.
> Thank you.

So far, you're the only one who reviewed those patches. I'm not sure
what you're talking about here.

Maxime

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

Re: [PATCH v1 1/3] drm/panel: ili9341: Correct use of device property APIs

[Dmitry Baryshkov]

On Thu, Apr 25, 2024 at 05:26:17PM +0300, Andy Shevchenko wrote:
> It seems driver missed the point of proper use of device property APIs.
> Correct this by updating headers and calls respectively.
> 
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/Kconfig                | 2 +-
>  drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

-- 
With best wishes
Dmitry

Re: [PATCH v1 2/3] drm/panel: ili9341: Respect deferred probe

[Dmitry Baryshkov]

On Thu, Apr 25, 2024 at 05:26:18PM +0300, Andy Shevchenko wrote:
> GPIO controller might not be available when driver is being probed.
> There are plenty of reasons why, one of which is deferred probe.
> 
> Since GPIOs are optional, return any error code we got to the upper
> layer, including deferred probe. With that in mind, use dev_err_probe()
> in order to avoid spamming the logs.
> 
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>


-- 
With best wishes
Dmitry

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:12, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 02:08, Sui Jingfeng wrote:

...

> > Are you speaking to yourself? I'm totally lost.
> > 
> > Please, if you want to give a constructive feedback, try to understand
> > the topic from different aspects and then clearly express it.
> 
> OK,
> 
> The previous email analysis the non-DT cases exhaustively, this email intend to
> demonstrate the more frequently use case.
> 
> That is, in the *DT('OF')* based systems,
> device_get_match_data() is completely equivalent to
> of_device_get_match_data().

> So the net results of applying this patch are "no gains and no lost".

This is not true. It's only part of the cases, i.e. DT. So, I assume you meant

  "So the net results of applying this patch are "no gains and no lost" in DT case".

> Things will become clear if we divide the whole problem into two cases(DT and non-DT)
> to discuss, that's it. That's all I can tell.

Not really. non-DT cases can also be divided to "fwnode backed or not", and
the former might be subdivided to "is it swnode backed or real fwnode one?"

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:10, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > It seems driver missed the point of proper use of device property APIs.
> > > > Correct this by updating headers and calls respectively.
> > > You are using the 'seems' here exactly saying that you are not 100% sure.

To add here, "seems" is used to show that I have no knowledge on what was
the idea behind this implementation by the original author. Plus my knowledge
in the firmware node / device property APIs and use cases in Linux kernel.

> > > Please allow me to tell you the truth: This patch again has ZERO effect.
> > > It fix nothing. And this patch is has the risks to be wrong.
> > Huh?! Really, stop commenting the stuff you do not understand.
> 
> I'm actually a professional display drivers developer at the downstream
> in the past, despite my contribution to upstream is less. But I believe
> that all panel driver developers know what I'm talking about. So please
> have take a look at my replies.

Okay.

> > > Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
> > > is DT dependent.
> > > 
> > > First of all, the devm_of_find_backlight() is called in ili9341_dbi_probe()
> > > under *non-DT* environment, devm_of_find_backlight() is just a just a
> > > no-op and will return NULL. NULL is not an error code, so ili9341_dbi_probe()
> > > won't rage quit. But the several side effect is that the backlight will
> > > NOT works at all.
> > Is it a problem?
> 
> Yes, it is.
> 
> The core problem is that the driver you are modifying has *implicit* *dependency* on DT.
> The implicit dependency is due to the calling of devm_of_find_backlight(). This function
> is a no-op under non-DT systems.

Okay.

> Therefore, before the devm_of_find_backlight() and
> the device_get_match_data() function can truly DT independent.

True for the first part, not true for the second.

> Removing the "OF" dependency just let the tigers run out from the jail.
> 
> It is not really meant to targeting at you, but I thinks, all of drm_panel drivers
> that has the devm_of_find_backlight() invoked will suffer such concerns.
> In short, the reason is that the *implicit* *dependency* populates and
> the undefined behavior gets triggered.

Still no problem statement. My hardware works nicely on non-DT environment.
(And since it's Arduino-based one, I assume it will work on DT environments
 the very same way.)

> I'm sure you know that device_get_match_data() is same with of_device_get_match_data()
> for DT based systems. For non DT based systems, device_get_match_data() is just *undefined*
> Note that ACPI is not in the scope of the discussion here, as all of the drm bridges and
> panels driver under drivers/gpu/drm/ hasn't the ACPI support yet.

This patch shows exactly how to bring back the ACPI support to one of them
(as it's done for tinyDRM cases).

> Therefore, at present,
> it safe to say that device_get_match_data() is *undefined* under no-DT environment.

This is not true.

> Removing the "OF" dependency hints to us that it allows the driver to be probed as a
> pure SPI device under non DT systems. When device_get_match_data() is called, it returns
> NULL to us now. As a result, the drm driver being modified will tears down.
> 
> See bellow code snippet extracted frompanel-ilitek-ili9341.c:
> 
> 
> ```
> 	ili->conf = of_device_get_match_data(dev);
> 	if (!ili->conf) {
> 		dev_err(dev, "missing device configuration\n");
> 		return -ENODEV;
> 	}
> ```
> 
> > > It is actually considered as fatal bug for *panels* if the backlight of
> > > it is not light up, at least the brightness of *won't* be able to adjust.
> > > What's worse, if there is no sane platform setup code at the firmware
> > > or boot loader stage to set a proper initial state. The screen is complete
> > > dark. Even though the itself panel is refreshing framebuffers, it can not
> > > be seen by human's eye. Simple because of no backlight.
> > Can you imagine that I may have different hardware that considered
> > this is non-fatal error?
> > 
> Yes, I can imagine.
> 
> I believe you have the hardware which make you patch correct to run
> in 99.9% of all cases. But as long as there one bug happened, you patch
> are going to be blamed.
> 
> Because its your patch that open the door, both from the perceptive of
> practice and from the perceptive of the concept (static analysis).
> 
> > > Second, the ili9341_dbi_probe() requires additional device properties to
> > > be able to works very well on the rotation screen case. See the calling
> > > of "device_property_read_u32(dev, "rotation", &rotation)" in
> > > ili9341_dbi_probe() function.
> > Yes, exactly, and how does it object the purpose of this patch?
> 
> Because under *non-DT* environment, your commit message do not give a
> valid description, how does the additional device property can be acquired
> is not demonstrated.
> 
> And it is exactly your patch open the non-DT code path (way or possibility).
> It isn't has such risks before your patch is applied. In other words,
> previously, the driver has the 'OF' dependency as the guard, all of the
> potential risk(or problem) are suppressed. It is a extremely safe policy,
> and it is also a extremely perfect defend.
> 
> And suddenly, you patch release the dangerous tiger from the cage.
> So I think you can imagine...

No, I can't, sorry. I don't see how dangerous will be the use of DRM panel
in a wrong configuration. The same can very well happen on improperly working
hardware (backlight part) or simply when somebody didn't correctly set a DT
or manually use it when it should not be. But again I see *no* problem
statement, only some worries.

And on top of that I made tinyDRM drivers to be accessible on ACPI platforms
and so far I have none complains about the tigers that left the cage.

> > > Combine with those two factors, it is actually can conclude that the
> > > panel-ilitek-ili9394 driver has the *implicit* dependency on 'OF'.
> > > Removing the 'OF' dependency from its Kconfig just trigger the
> > > leakage of such risks.
> > What?!
> > 
> Posting a patch is actually doing the defensive works, such a saying
> may not sound fair for you, but this is just the hash cruel reality.
> Sorry for saying that. :(

So, the summary of your message is that:
- there's no understanding how ACPI (or any other non-DT fwnode based
  environment) can utilise the driver
- there's a worry about some problems which can't be stated clearly
- there's a neglecting of the previous successful cases specific for DRM
  (tinyDRM drivers)

As a result of the false input, the non-constructive conclusion was given.

And note, I converted dozens if not hundredth of drivers that used to be
OF-only and haven't heart any negative feedback before this case. Maybe
we (reviewers of my patches and maintainers who applied them and end users)
miss a BIG DEAL here? Please, elaborate how dropping OF dependency can be
dangerous as a free walking tiger.

> > > My software node related patches can help to reduce part of the potential
> > > risks, but it still need some extra work. And it is not landed yet.

> > Your patch has nothing to do with this series.

I am not going to repeat the above.

> With my patch applied, this is way to meet the gap under non-DT systems.
> Users of this driver could managed to attach(complete) absent properties
> to the SPI device with software node properties. Register the swnode
> properties group into the system prior the panel driver is probed. There
> may need some quirk. But at the least there has a way to go.  When there
> has a way to go, things become self-consistent. Viewed from both the
> practice of viewpoint and the concept of viewpoint.
> 
> And the dangerous tiger will steer its way to the direction of "ACPI
> support is missing". But both of will be safe then.

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

On 2024/4/30 22:13, Andy Shevchenko wrote:
> On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
>> On 2024/4/26 03:12, Andy Shevchenko wrote:
>>> On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
>>>> On 2024/4/26 02:08, Sui Jingfeng wrote:
> ...
>
>>> Are you speaking to yourself? I'm totally lost.
>>>
>>> Please, if you want to give a constructive feedback, try to understand
>>> the topic from different aspects and then clearly express it.
>> OK,
>>
>> The previous email analysis the non-DT cases exhaustively, this email intend to
>> demonstrate the more frequently use case.
>>
>> That is, in the *DT('OF')* based systems,
>> device_get_match_data() is completely equivalent to
>> of_device_get_match_data().
>> So the net results of applying this patch are "no gains and no lost".
> This is not true.

Yes, I'm true.

I have mentionedin previous(earlier) paragraph  with "in the DT(OF) based systems" or similar words.


> It's only part of the cases, i.e. DT. So, I assume you meant
>
>    "So the net results of applying this patch are "no gains and no lost" in DT case".


Yeah,it is true that this patch are "no gains and no lost" in DT case.


>> Things will become clear if we divide the whole problem into two cases(DT and non-DT)
>> to discuss, that's it. That's all I can tell.
> Not really.


I'm very clear before our conversation, really!


> non-DT cases can also be divided to "fwnode backed or not",

For non fwnode backed case of non-DT cases, there is not decent way to acquire
large set of device properties. And is out of the scope of "Correct use of
device property APIs".


> and
> the former might be subdivided to "is it swnode backed or real fwnode one?"
>
Yeah,
On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode backed case.

  - For swnode backed case: the device_get_match_data() don't has a implemented backend.
  - For ACPI fwnode backed case: the device_get_match_data() has a implemented backend.

But the driver has *neither* software node support nor ACPI support, so that the rotation
property can not get and ili9341_dpi_probe() will fails. So in total, this is not a 100%
correct use of device property APIs.

But I'm fine that if you want to leave(ignore) those less frequent use cases temporarily,
there may have programmers want to post patches, to complete the missing in the future.


So, there do have some gains on non-DT cases.

  - As you make it be able to compiled on X86 with the drm-misc-defconfig.
  - You cleanup the code up (at least patch 2 in this series is no obvious problem).
  - You allow people to modprobe it, and maybe half right and half undefined.

But you do helps moving something forward, so congratulations for the wake up.

-- 
Best regards,
Sui

Re: [v1,2/3] drm/panel: ili9341: Respect deferred probe

[Sui Jingfeng]

Hi,


On 2024/4/25 22:26, Andy Shevchenko wrote:
> GPIO controller might not be available when driver is being probed.
> There are plenty of reasons why, one of which is deferred probe.
>
> Since GPIOs are optional, return any error code we got to the upper
> layer, including deferred probe. With that in mind, use dev_err_probe()
> in order to avoid spamming the logs.
>
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>


Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>

-- 
Best regards,
Sui

Re: [v1,3/3] drm/panel: ili9341: Use predefined error codes

[Sui Jingfeng]

On 2024/4/25 22:26, Andy Shevchenko wrote:
> In one case the -1 is returned which is quite confusing code for
> the wrong device ID, in another the ret is returning instead of
> plain 0 that also confusing as readed may ask the possible meaning
> of positive codes, which are never the case there. Convert both
> to use explicit predefined error codes to make it clear what's going
> on there.
>
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>


Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>


-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/4/30 22:32, Andy Shevchenko wrote:
> On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
>> On 2024/4/26 03:10, Andy Shevchenko wrote:
>>> On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
>>>> On 2024/4/25 22:26, Andy Shevchenko wrote:
>>>>> It seems driver missed the point of proper use of device property APIs.
>>>>> Correct this by updating headers and calls respectively.
>>>> You are using the 'seems' here exactly saying that you are not 100% sure.
> To add here, "seems" is used to show that I have no knowledge on what was
> the idea behind this implementation by the original author. Plus my knowledge
> in the firmware node / device property APIs and use cases in Linux kernel.
>
>>>> Please allow me to tell you the truth: This patch again has ZERO effect.
>>>> It fix nothing. And this patch is has the risks to be wrong.
>>> Huh?! Really, stop commenting the stuff you do not understand.
>> I'm actually a professional display drivers developer at the downstream
>> in the past, despite my contribution to upstream is less. But I believe
>> that all panel driver developers know what I'm talking about. So please
>> have take a look at my replies.
> Okay.
>
>>>> Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
>>>> is DT dependent.
>>>>
>>>> First of all, the devm_of_find_backlight() is called in ili9341_dbi_probe()
>>>> under *non-DT* environment, devm_of_find_backlight() is just a just a
>>>> no-op and will return NULL. NULL is not an error code, so ili9341_dbi_probe()
>>>> won't rage quit. But the several side effect is that the backlight will
>>>> NOT works at all.
>>> Is it a problem?
>> Yes, it is.
>>
>> The core problem is that the driver you are modifying has *implicit* *dependency* on DT.
>> The implicit dependency is due to the calling of devm_of_find_backlight(). This function
>> is a no-op under non-DT systems.
> Okay.
>
>> Therefore, before the devm_of_find_backlight() and
>> the device_get_match_data() function can truly DT independent.
> True for the first part, not true for the second.
>
>> Removing the "OF" dependency just let the tigers run out from the jail.
>>
>> It is not really meant to targeting at you, but I thinks, all of drm_panel drivers
>> that has the devm_of_find_backlight() invoked will suffer such concerns.
>> In short, the reason is that the *implicit* *dependency* populates and
>> the undefined behavior gets triggered.
> Still no problem statement. My hardware works nicely on non-DT environment.
> (And since it's Arduino-based one, I assume it will work on DT environments
>   the very same way.)
>
>> I'm sure you know that device_get_match_data() is same with of_device_get_match_data()
>> for DT based systems. For non DT based systems, device_get_match_data() is just *undefined*
>> Note that ACPI is not in the scope of the discussion here, as all of the drm bridges and
>> panels driver under drivers/gpu/drm/ hasn't the ACPI support yet.
> This patch shows exactly how to bring back the ACPI support to one of them
> (as it's done for tinyDRM cases).
>
>> Therefore, at present,
>> it safe to say that device_get_match_data() is *undefined* under no-DT environment.
> This is not true.
>
>> Removing the "OF" dependency hints to us that it allows the driver to be probed as a
>> pure SPI device under non DT systems. When device_get_match_data() is called, it returns
>> NULL to us now. As a result, the drm driver being modified will tears down.
>>
>> See bellow code snippet extracted frompanel-ilitek-ili9341.c:
>>
>>
>> ```
>> 	ili->conf = of_device_get_match_data(dev);
>> 	if (!ili->conf) {
>> 		dev_err(dev, "missing device configuration\n");
>> 		return -ENODEV;
>> 	}
>> ```
>>
>>>> It is actually considered as fatal bug for *panels* if the backlight of
>>>> it is not light up, at least the brightness of *won't* be able to adjust.
>>>> What's worse, if there is no sane platform setup code at the firmware
>>>> or boot loader stage to set a proper initial state. The screen is complete
>>>> dark. Even though the itself panel is refreshing framebuffers, it can not
>>>> be seen by human's eye. Simple because of no backlight.
>>> Can you imagine that I may have different hardware that considered
>>> this is non-fatal error?
>>>
>> Yes, I can imagine.
>>
>> I believe you have the hardware which make you patch correct to run
>> in 99.9% of all cases. But as long as there one bug happened, you patch
>> are going to be blamed.
>>
>> Because its your patch that open the door, both from the perceptive of
>> practice and from the perceptive of the concept (static analysis).
>>
>>>> Second, the ili9341_dbi_probe() requires additional device properties to
>>>> be able to works very well on the rotation screen case. See the calling
>>>> of "device_property_read_u32(dev, "rotation", &rotation)" in
>>>> ili9341_dbi_probe() function.
>>> Yes, exactly, and how does it object the purpose of this patch?
>> Because under *non-DT* environment, your commit message do not give a
>> valid description, how does the additional device property can be acquired
>> is not demonstrated.
>>
>> And it is exactly your patch open the non-DT code path (way or possibility).
>> It isn't has such risks before your patch is applied. In other words,
>> previously, the driver has the 'OF' dependency as the guard, all of the
>> potential risk(or problem) are suppressed. It is a extremely safe policy,
>> and it is also a extremely perfect defend.
>>
>> And suddenly, you patch release the dangerous tiger from the cage.
>> So I think you can imagine...
> No, I can't, sorry. I don't see how dangerous will be the use of DRM panel
> in a wrong configuration. The same can very well happen on improperly working
> hardware (backlight part) or simply when somebody didn't correctly set a DT
> or manually use it when it should not be. But again I see *no* problem
> statement, only some worries.
>
> And on top of that I made tinyDRM drivers to be accessible on ACPI platforms
> and so far I have none complains about the tigers that left the cage.
>
>>>> Combine with those two factors, it is actually can conclude that the
>>>> panel-ilitek-ili9394 driver has the *implicit* dependency on 'OF'.
>>>> Removing the 'OF' dependency from its Kconfig just trigger the
>>>> leakage of such risks.
>>> What?!
>>>
>> Posting a patch is actually doing the defensive works, such a saying
>> may not sound fair for you, but this is just the hash cruel reality.
>> Sorry for saying that. :(
> So, the summary of your message is that:
> - there's no understanding how ACPI (or any other non-DT fwnode based
>    environment) can utilise the driver
> - there's a worry about some problems which can't be stated clearly
> - there's a neglecting of the previous successful cases specific for DRM
>    (tinyDRM drivers)
>
> As a result of the false input, the non-constructive conclusion was given.
>
> And note, I converted dozens if not hundredth of drivers that used to be
> OF-only and haven't heart any negative feedback before this case. Maybe
> we (reviewers of my patches and maintainers who applied them and end users)
> miss a BIG DEAL here? Please, elaborate how dropping OF dependency can be
> dangerous as a free walking tiger.
>
>>>> My software node related patches can help to reduce part of the potential
>>>> risks, but it still need some extra work. And it is not landed yet.
>>> Your patch has nothing to do with this series.
> I am not going to repeat the above.
>
>> With my patch applied, this is way to meet the gap under non-DT systems.
>> Users of this driver could managed to attach(complete) absent properties
>> to the SPI device with software node properties. Register the swnode
>> properties group into the system prior the panel driver is probed. There
>> may need some quirk. But at the least there has a way to go.  When there
>> has a way to go, things become self-consistent. Viewed from both the
>> practice of viewpoint and the concept of viewpoint.
>>
>> And the dangerous tiger will steer its way to the direction of "ACPI
>> support is missing". But both of will be safe then.


I have no obvious opinions then, code inside this patch seems no obvious problem
for majority applications. Sorry about the noise and thanks for reply.


-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Neil Armstrong]

On 30/04/2024 11:34, Maxime Ripard wrote:
> On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
>> On 2024/4/29 19:55, Maxime Ripard wrote:
>>> On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
>>>> On 2024/4/26 14:23, Maxime Ripard wrote:
>>>>> On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
>>>>>> On 2024/4/26 03:10, Andy Shevchenko wrote:
>>>>>>> On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
>>>>>>>> On 2024/4/25 22:26, Andy Shevchenko wrote:
>>>>>>>>> It seems driver missed the point of proper use of device property APIs.
>>>>>>>>> Correct this by updating headers and calls respectively.
>>>>>>>> You are using the 'seems' here exactly saying that you are not 100% sure.
>>>>>>>>
>>>>>>>> Please allow me to tell you the truth: This patch again has ZERO effect.
>>>>>>>> It fix nothing. And this patch is has the risks to be wrong.
>>>>>>> Huh?! Really, stop commenting the stuff you do not understand.
>>>>>> I'm actually a professional display drivers developer at the downstream
>>>>>> in the past, despite my contribution to upstream is less. But I believe
>>>>>> that all panel driver developers know what I'm talking about. So please
>>>>>> have take a look at my replies.
>>>>> Most of the interactions you had in this series has been uncalled for.
>>>>> You might be against a patch, but there's no need to go to such length.
>>>>>
>>>>> As far as I'm concerned, this patch is fine to me in itself, and I don't
>>>>> see anything that would prevent us from merging it.
>>>> No one is preventing you, as long as don't misunderstanding what other
>>>> people's technical replies intentionally. I'm just a usual and normal
>>>> contributor, I hope the world will better than yesterday.
>>> You should seriously consider your tone when replying then.
>>>
>>>> Saying such thing to me may not proper, I guess you may want to talk
>>>> to peoples who has the push rights
>>> I think you misunderstood me. My point was that your several rants were
>>> uncalled for and aren't the kind of things we're doing here.
>>>
>>> I know very well how to get a patch merged, thanks.
>>>
>>>> just make sure it isn't a insult to the professionalism of drm bridge
>>>> community itself though.
>>> I'm not sure why you're bringing the bridge community or its
>>> professionalism. It's a panel, not a bridge, and I never doubted the
>>> professionalism of anyone.
>>
>>
>> I means that the code itself could be adopted, as newer and younger
>> programmer (like Andy) need to be encouraged to contribute.
> 
> Andy has thousands of commits in Linux. He's *very* far from being a new
> contributor.
> 
>> I express no obvious objections, just hints him that something else
>> probably should also be taken into consideration as well.
> 
> That might be what you wanted to express, but you definitely didn't
> express it that way.
> 
>> On the other hand, we probably should allow other people participate
>> in discussion so that it is sufficient discussed and ensure that it
>> won't be reverted by someone in the future for some reasons. Backing
>> to out case happens here, we may need to move things forward. Therefore,
>> it definitely deserve to have a try. It is not a big deal even though
>> it gets reverted someday.
>>
>> In the end, I don't mind if you think there is nothing that could
>> prevent you from merge it, but I still suggest you have a glance at
>> peoples siting at the Cc list. I'm busy now and I have a lot of other
>> tasks to do, and may not be able to reply you emails on time. So it up
>> to you and other maintainers to decide.
>> Thank you.
> 
> So far, you're the only one who reviewed those patches. I'm not sure
> what you're talking about here.

Well I (as drm-panel maintainer) did review them positively because the patches looked
perfectly correct in regards of the commit message and the patchset motivation and
because I trust Andy being a long time contributor with a lot of expertise.

Anyway since the rant is finished I'll land the patches.

Neil

> 
> Maxime

Re: [PATCH v1 0/3] drm/panel: ili9341: Obvious fixes

[Neil Armstrong]

Hi,

On Thu, 25 Apr 2024 17:26:16 +0300, Andy Shevchenko wrote:
> A few obvious fixes to the driver.
> 
> Andy Shevchenko (3):
>   drm/panel: ili9341: Correct use of device property APIs
>   drm/panel: ili9341: Respect deferred probe
>   drm/panel: ili9341: Use predefined error codes
> 
> [...]

Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes)

[1/3] drm/panel: ili9341: Correct use of device property APIs
      https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d43cd48ef1791801c61a54fade4a88d294dedf77
[2/3] drm/panel: ili9341: Respect deferred probe
      https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/740fc1e0509be3f7e2207e89125b06119ed62943
[3/3] drm/panel: ili9341: Use predefined error codes
      https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/da85f0aaa9f21999753b01d45c0343f885a8f905

-- 
Neil

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> On 2024/4/30 22:13, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:

...

> > the former might be subdivided to "is it swnode backed or real fwnode one?"
> > 
> Yeah,
> On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode backed case.
> 
>  - For swnode backed case: the device_get_match_data() don't has a implemented backend.
>  - For ACPI fwnode backed case: the device_get_match_data() has a implemented backend.
> 
> But the driver has *neither* software node support

True.

> nor ACPI support,

Not true.

So, slow down and take your time to get into the code and understand how it works.

> so that the rotation property can not get and ili9341_dpi_probe() will fails.
> So in total, this is not a 100% correct use of device property APIs.
> 
> But I'm fine that if you want to leave(ignore) those less frequent use cases temporarily,
> there may have programmers want to post patches, to complete the missing in the future.
> 
> So, there do have some gains on non-DT cases.
> 
>  - As you make it be able to compiled on X86 with the drm-misc-defconfig.
>  - You cleanup the code up (at least patch 2 in this series is no obvious problem).
>  - You allow people to modprobe it, and maybe half right and half undefined.
> 
> But you do helps moving something forward, so congratulations for the wake up.

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Thu, May 02, 2024 at 09:34:17AM +0200, Neil Armstrong wrote:
> On 30/04/2024 11:34, Maxime Ripard wrote:

...

> Anyway since the rant is finished I'll land the patches.

Thank you all for the review and discussion!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] drm/panel: ili9341: Obvious fixes

[Andy Shevchenko]

On Thu, May 02, 2024 at 09:43:42AM +0200, Neil Armstrong wrote:
> Hi,
> 
> On Thu, 25 Apr 2024 17:26:16 +0300, Andy Shevchenko wrote:
> > A few obvious fixes to the driver.
> > 
> > Andy Shevchenko (3):
> >   drm/panel: ili9341: Correct use of device property APIs
> >   drm/panel: ili9341: Respect deferred probe
> >   drm/panel: ili9341: Use predefined error codes
> > 
> > [...]
> 
> Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes)
> 
> [1/3] drm/panel: ili9341: Correct use of device property APIs
>       https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d43cd48ef1791801c61a54fade4a88d294dedf77
> [2/3] drm/panel: ili9341: Respect deferred probe
>       https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/740fc1e0509be3f7e2207e89125b06119ed62943
> [3/3] drm/panel: ili9341: Use predefined error codes
>       https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/da85f0aaa9f21999753b01d45c0343f885a8f905

Thank you, Neil, appreciated!

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/5/2 16:32, Andy Shevchenko wrote:
> On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
>> On 2024/4/30 22:13, Andy Shevchenko wrote:
>>> On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
> ...
>
>>> the former might be subdivided to "is it swnode backed or real fwnode one?"
>>>
>> Yeah,
>> On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode backed case.
>>
>>   - For swnode backed case: the device_get_match_data() don't has a implemented backend.
>>   - For ACPI fwnode backed case: the device_get_match_data() has a implemented backend.
>>
>> But the driver has *neither* software node support
> True.
>
>> nor ACPI support,
> Not true.

Why this is not true? Are you means that the panel-ilitek-ili9341 driver has ACPI support?
I'm asking because I don't see struct acpi_device_id related stuff in that source file,
am I miss something?


> So, slow down and take your time to get into the code and understand how it works.
>
>> so that the rotation property can not get and ili9341_dpi_probe() will fails.
>> So in total, this is not a 100% correct use of device property APIs.
>>
>> But I'm fine that if you want to leave(ignore) those less frequent use cases temporarily,
>> there may have programmers want to post patches, to complete the missing in the future.
>>
>> So, there do have some gains on non-DT cases.
>>
>>   - As you make it be able to compiled on X86 with the drm-misc-defconfig.
>>   - You cleanup the code up (at least patch 2 in this series is no obvious problem).
>>   - You allow people to modprobe it, and maybe half right and half undefined.
>>
>> But you do helps moving something forward, so congratulations for the wake up.

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,


On 2024/5/2 15:34, Neil Armstrong wrote:
> On 30/04/2024 11:34, Maxime Ripard wrote:
>> On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
>>> On 2024/4/29 19:55, Maxime Ripard wrote:
>>>> On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
>>>>> On 2024/4/26 14:23, Maxime Ripard wrote:
>>>>>> On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
>>>>>>> On 2024/4/26 03:10, Andy Shevchenko wrote:
>>>>>>>> On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
>>>>>>>>> On 2024/4/25 22:26, Andy Shevchenko wrote:
>>>>>>>>>> It seems driver missed the point of proper use of device 
>>>>>>>>>> property APIs.
>>>>>>>>>> Correct this by updating headers and calls respectively.
>>>>>>>>> You are using the 'seems' here exactly saying that you are not 
>>>>>>>>> 100% sure.
>>>>>>>>>
>>>>>>>>> Please allow me to tell you the truth: This patch again has 
>>>>>>>>> ZERO effect.
>>>>>>>>> It fix nothing. And this patch is has the risks to be wrong.
>>>>>>>> Huh?! Really, stop commenting the stuff you do not understand.
>>>>>>> I'm actually a professional display drivers developer at the 
>>>>>>> downstream
>>>>>>> in the past, despite my contribution to upstream is less. But I 
>>>>>>> believe
>>>>>>> that all panel driver developers know what I'm talking about. So 
>>>>>>> please
>>>>>>> have take a look at my replies.
>>>>>> Most of the interactions you had in this series has been uncalled 
>>>>>> for.
>>>>>> You might be against a patch, but there's no need to go to such 
>>>>>> length.
>>>>>>
>>>>>> As far as I'm concerned, this patch is fine to me in itself, and 
>>>>>> I don't
>>>>>> see anything that would prevent us from merging it.
>>>>> No one is preventing you, as long as don't misunderstanding what 
>>>>> other
>>>>> people's technical replies intentionally. I'm just a usual and normal
>>>>> contributor, I hope the world will better than yesterday.
>>>> You should seriously consider your tone when replying then.
>>>>
>>>>> Saying such thing to me may not proper, I guess you may want to talk
>>>>> to peoples who has the push rights
>>>> I think you misunderstood me. My point was that your several rants 
>>>> were
>>>> uncalled for and aren't the kind of things we're doing here.
>>>>
>>>> I know very well how to get a patch merged, thanks.
>>>>
>>>>> just make sure it isn't a insult to the professionalism of drm bridge
>>>>> community itself though.
>>>> I'm not sure why you're bringing the bridge community or its
>>>> professionalism. It's a panel, not a bridge, and I never doubted the
>>>> professionalism of anyone.
>>>
>>>
>>> I means that the code itself could be adopted, as newer and younger
>>> programmer (like Andy) need to be encouraged to contribute.
>>
>> Andy has thousands of commits in Linux. He's *very* far from being a new
>> contributor.
>>
>>> I express no obvious objections, just hints him that something else
>>> probably should also be taken into consideration as well.
>>
>> That might be what you wanted to express, but you definitely didn't
>> express it that way.
>>
>>> On the other hand, we probably should allow other people participate
>>> in discussion so that it is sufficient discussed and ensure that it
>>> won't be reverted by someone in the future for some reasons. Backing
>>> to out case happens here, we may need to move things forward. 
>>> Therefore,
>>> it definitely deserve to have a try. It is not a big deal even though
>>> it gets reverted someday.
>>>
>>> In the end, I don't mind if you think there is nothing that could
>>> prevent you from merge it, but I still suggest you have a glance at
>>> peoples siting at the Cc list. I'm busy now and I have a lot of other
>>> tasks to do, and may not be able to reply you emails on time. So it up
>>> to you and other maintainers to decide.
>>> Thank you.
>>
>> So far, you're the only one who reviewed those patches. I'm not sure
>> what you're talking about here.
>
> Well I (as drm-panel maintainer) did review them positively


[...]


> because the patches looked perfectly correct in regards of the commit 
> message 

The point is the 'fixes' tag.

Then, can I ask what's the issue it fixes? I'm asking because I see the
submitting-patches.html [1] documentation told us that a fixes tag indicates
that the patch fixes an issue in a previous commit.

Previously, the driver only meant to be used on the DT systems, so what's issue?

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight

I copy & paste the paragraph from link [1] for easier to read. See below:


"A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
is used to make it easy to determine where a bug originated, which can help
review a bug fix. This tag also assists the stable kernel team in determining
which stable kernel versions should receive your fix. This is the preferred
method for indicating a bug fixed by the patch."

> and the patchset motivation and


OK, the motivation is good, I agree and I admit.


> because I trust Andy being a long time contributor with a lot of 
> expertise.
>

Does this means that you are going to merge patches from the experts without have a glance and
reject or ignore novice's patches unconditionally?

I'm asking because I see there still have a lot of other panel drivers use of_device_get_match_data()
function to get a match, and most of them has the 'OF' guard. However, in theory, panel should be
able to use on any CPU architecture if necessary. Does the remains has the similar issue? or Do we
need to fixed them together?


$ find . -name "*.c" -type f | xargs grep "of_device_get_match_data"

./panel-ilitek-ili9882t.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-innolux-p079zca.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-simple.c:    desc = of_device_get_match_data(&pdev->dev);
./panel-simple.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-novatek-nt39016.c:    panel->panel_info = 
of_device_get_match_data(dev);
./panel-novatek-nt35950.c:    nt->desc = of_device_get_match_data(dev);
./panel-boe-himax8279d.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-sitronix-st7703.c:    ctx->desc = of_device_get_match_data(dev);
./panel-sony-td4353-jdi.c:    ctx->type = 
(uintptr_t)of_device_get_match_data(dev);
./panel-samsung-sofef00.c:    ctx->mode = of_device_get_match_data(dev);
./panel-synaptics-r63353.c:    panel->pdata = (struct r63353_desc 
*)of_device_get_match_data(dev);
./panel-abt-y030xx067a.c:    priv->panel_info = 
of_device_get_match_data(dev);
./panel-ilitek-ili9881c.c:    ctx->desc = 
of_device_get_match_data(&dsi->dev);
./panel-newvision-nv3052c.c:    priv->panel_info = 
of_device_get_match_data(dev);
./panel-mantix-mlaf057we51.c:    ctx->default_mode = 
of_device_get_match_data(dev);
./panel-himax-hx8394.c:    ctx->desc = of_device_get_match_data(dev);
./panel-ilitek-ili9805.c:    ctx->desc = 
of_device_get_match_data(&dsi->dev);
./panel-boe-tv101wum-nl6.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-samsung-s6d7aa0.c:    ctx->desc = of_device_get_match_data(dev);
./panel-novatek-nt36523.c:    pinfo->desc = of_device_get_match_data(dev);
./panel-novatek-nt35510.c:    nt->conf = of_device_get_match_data(dev);
./panel-newvision-nv3051d.c:    ctx->panel_info = 
of_device_get_match_data(dev);
./panel-khadas-ts050.c:    const void *data = 
of_device_get_match_data(&dsi->dev);
./panel-leadtek-ltk500hd1829.c:    ctx->panel_desc = 
of_device_get_match_data(dev);
./panel-truly-nt35597.c:    ctx->config = of_device_get_match_data(dev);
./panel-innolux-ej030na.c:    priv->panel_info = 
of_device_get_match_data(dev);
./panel-magnachip-d53e6ea8966.c:    db->panel_info = 
of_device_get_match_data(dev);
./panel-novatek-nt36672e.c:    ctx->desc = of_device_get_match_data(dev);
./panel-sitronix-st7701.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-dsi-cm.c:    ddata->panel_data = of_device_get_match_data(dev);
./panel-novatek-nt36672a.c:    desc = of_device_get_match_data(&dsi->dev);
./panel-novatek-nt35560.c:    nt->conf = of_device_get_match_data(dev);
./panel-ilitek-ili9341.c:    ili->conf = of_device_get_match_data(dev);
./panel-jadard-jd9365da-h3.c:    desc = of_device_get_match_data(dev);
./panel-leadtek-ltk050h3146w.c:    ctx->panel_desc = 
of_device_get_match_data(dev);
./panel-ilitek-ili9322.c:    ili->conf = of_device_get_match_data(dev);
./panel-samsung-s6e3ha2.c:    ctx->desc = of_device_get_match_data(dev);


> Anyway since the rant is finished I'll land the patches.
>

It's just *comments* or *remarks*, there really no need to use the 'rant'
to insult and/or devalue other peoples, as it make no sense.


> Neil
>
>>
>> Maxime
>
-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
> On 2024/5/2 16:32, Andy Shevchenko wrote:
> > On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/30 22:13, Andy Shevchenko wrote:
> > > > On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:

...

> > > > the former might be subdivided to "is it swnode backed or real fwnode one?"
> > > > 
> > > Yeah,
> > > On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode backed case.
> > > 
> > >   - For swnode backed case: the device_get_match_data() don't has a implemented backend.
> > >   - For ACPI fwnode backed case: the device_get_match_data() has a implemented backend.
> > > 
> > > But the driver has *neither* software node support
> > True.
> > 
> > > nor ACPI support,
> > Not true.
> 
> Why this is not true? Are you means that the panel-ilitek-ili9341 driver has ACPI support?

That's the idea (as far as I see the copy of the code from tinyDRM),
but broken over the copy'n'paste. This patch rectifies that to be
in align with the original code, which *does* support ACPI.

> I'm asking because I don't see struct acpi_device_id related stuff in that source file,
> am I miss something?

Yes, you are. I leave it for you to research.

> > So, slow down and take your time to get into the code and understand how it works.
> > 
> > > so that the rotation property can not get and ili9341_dpi_probe() will fails.
> > > So in total, this is not a 100% correct use of device property APIs.
> > > 
> > > But I'm fine that if you want to leave(ignore) those less frequent use cases temporarily,
> > > there may have programmers want to post patches, to complete the missing in the future.
> > > 
> > > So, there do have some gains on non-DT cases.
> > > 
> > >   - As you make it be able to compiled on X86 with the drm-misc-defconfig.
> > >   - You cleanup the code up (at least patch 2 in this series is no obvious problem).
> > >   - You allow people to modprobe it, and maybe half right and half undefined.
> > > 
> > > But you do helps moving something forward, so congratulations for the wake up.

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, May 03, 2024 at 01:28:26AM +0800, Sui Jingfeng wrote:
> On 2024/5/2 15:34, Neil Armstrong wrote:
> > On 30/04/2024 11:34, Maxime Ripard wrote:
> > > On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
> > > > On 2024/4/29 19:55, Maxime Ripard wrote:
> > > > > On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
> > > > > > On 2024/4/26 14:23, Maxime Ripard wrote:
> > > > > > > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> > > > > > > > On 2024/4/26 03:10, Andy Shevchenko wrote:
> > > > > > > > > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > > > > > > > > On 2024/4/25 22:26, Andy Shevchenko wrote:

...

> > > > > > > > > > > It seems driver missed the point of proper use of device
> > > > > > > > > > > property APIs.  Correct this by updating headers and
> > > > > > > > > > > calls respectively.

> > > > > > > > > > You are using the 'seems' here exactly saying that you are
> > > > > > > > > > not 100% sure.

> > > > > > > > > > Please allow me to tell you the truth: This patch again has
> > > > > > > > > > ZERO effect.  It fix nothing. And this patch is has the
> > > > > > > > > > risks to be wrong.

> > > > > > > > > Huh?! Really, stop commenting the stuff you do not understand.

> > > > > > > > I'm actually a professional display drivers developer at the
> > > > > > > > downstream in the past, despite my contribution to upstream is
> > > > > > > > less. But I believe that all panel driver developers know what
> > > > > > > > I'm talking about. So please have take a look at my replies.

> > > > > > > Most of the interactions you had in this series has been uncalled
> > > > > > > for.  You might be against a patch, but there's no need to go to
> > > > > > > such length.
> > > > > > > 
> > > > > > > As far as I'm concerned, this patch is fine to me in itself, and
> > > > > > > I don't see anything that would prevent us from merging it.

> > > > > > No one is preventing you, as long as don't misunderstanding what
> > > > > > other people's technical replies intentionally. I'm just a usual
> > > > > > and normal contributor, I hope the world will better than
> > > > > > yesterday.

> > > > > You should seriously consider your tone when replying then.
> > > > > 
> > > > > > Saying such thing to me may not proper, I guess you may want to talk
> > > > > > to peoples who has the push rights

> > > > > I think you misunderstood me. My point was that your several rants
> > > > > were uncalled for and aren't the kind of things we're doing here.
> > > > > 
> > > > > I know very well how to get a patch merged, thanks.
> > > > > 
> > > > > > just make sure it isn't a insult to the professionalism of drm bridge
> > > > > > community itself though.

> > > > > I'm not sure why you're bringing the bridge community or its
> > > > > professionalism. It's a panel, not a bridge, and I never doubted the
> > > > > professionalism of anyone.
> > > > 
> > > > I means that the code itself could be adopted, as newer and younger
> > > > programmer (like Andy) need to be encouraged to contribute.
> > > 
> > > Andy has thousands of commits in Linux. He's *very* far from being a new
> > > contributor.
> > > 
> > > > I express no obvious objections, just hints him that something else
> > > > probably should also be taken into consideration as well.
> > > 
> > > That might be what you wanted to express, but you definitely didn't
> > > express it that way.
> > > 
> > > > On the other hand, we probably should allow other people participate in
> > > > discussion so that it is sufficient discussed and ensure that it won't
> > > > be reverted by someone in the future for some reasons. Backing to out
> > > > case happens here, we may need to move things forward.  Therefore, it
> > > > definitely deserve to have a try. It is not a big deal even though it
> > > > gets reverted someday.
> > > > 
> > > > In the end, I don't mind if you think there is nothing that could
> > > > prevent you from merge it, but I still suggest you have a glance at
> > > > peoples siting at the Cc list. I'm busy now and I have a lot of other
> > > > tasks to do, and may not be able to reply you emails on time. So it up
> > > > to you and other maintainers to decide.
> > > > Thank you.
> > > 
> > > So far, you're the only one who reviewed those patches. I'm not sure
> > > what you're talking about here.
> > 
> > Well I (as drm-panel maintainer) did review them positively

[...]

> > because the patches looked perfectly correct in regards of the commit
> > message
> 
> The point is the 'fixes' tag.
> 
> Then, can I ask what's the issue it fixes? I'm asking because I see the
> submitting-patches.html [1] documentation told us that a fixes tag indicates
> that the patch fixes an issue in a previous commit.
> 
> Previously, the driver only meant to be used on the DT systems, so what's issue?

It fixes copy'n'paste error as far as I understand the motivation of this code.

> [1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight
> 
> I copy & paste the paragraph from link [1] for easier to read. See below:
> 
> "A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
> is used to make it easy to determine where a bug originated, which can help
> review a bug fix. This tag also assists the stable kernel team in determining
> which stable kernel versions should receive your fix. This is the preferred
> method for indicating a bug fixed by the patch."
> 
> > and the patchset motivation and
> 
> OK, the motivation is good, I agree and I admit.
> 
> > because I trust Andy being a long time contributor with a lot of
> > expertise.
> 
> Does this means that you are going to merge patches from the experts without have a glance and
> reject or ignore novice's patches unconditionally?
> 
> I'm asking because I see there still have a lot of other panel drivers use of_device_get_match_data()
> function to get a match, and most of them has the 'OF' guard. However, in theory, panel should be
> able to use on any CPU architecture if necessary. Does the remains has the similar issue? or Do we
> need to fixed them together?
> 
> $ find . -name "*.c" -type f | xargs grep "of_device_get_match_data"

$ git log --oneline --no-merges --grep device_get_match_data --author="Rob Herring"

So what does this prove?

> > Anyway since the rant is finished I'll land the patches.
> 
> It's just *comments* or *remarks*, there really no need to use the 'rant'
> to insult and/or devalue other peoples, as it make no sense.

P.S.
You really need to study a kernel code a bit more before replying with long messages.
It will help everybody, I believe.

-- 
With Best Regards,
Andy Shevchenko

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Sui Jingfeng]

Hi,

On 2024/5/3 01:28, Andy Shevchenko wrote:
> On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
>> On 2024/5/2 16:32, Andy Shevchenko wrote:
>>> On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
>>>> On 2024/4/30 22:13, Andy Shevchenko wrote:
>>>>> On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
> ...
>
>>>>> the former might be subdivided to "is it swnode backed or real fwnode one?"
>>>>>
>>>> Yeah,
>>>> On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode backed case.
>>>>
>>>>    - For swnode backed case: the device_get_match_data() don't has a implemented backend.
>>>>    - For ACPI fwnode backed case: the device_get_match_data() has a implemented backend.
>>>>
>>>> But the driver has *neither* software node support
>>> True.
>>>
>>>> nor ACPI support,
>>> Not true.
>> Why this is not true? Are you means that the panel-ilitek-ili9341 driver has ACPI support?
> That's the idea (as far as I see the copy of the code from tinyDRM),
> but broken over the copy'n'paste. This patch rectifies that to be
> in align with the original code, which *does* support ACPI.
>
>> I'm asking because I don't see struct acpi_device_id related stuff in that source file,
>> am I miss something?
> Yes, you are. I leave it for you to research.
>

After researching a few hours I still don't understand how does
the panel-ilitek-ili9341 driver has the ACPI support and be able
to ACPI probed when compiled as module.

As far as I know, drivers that has the ACPI support *must* has the
.acpi_match_table hooked, so that be able to be probed when the
driver is compiled as a module.

For example, see commit 75a1b44a54bd9 ("spi: tegra210-quad: add acpi support")
to get a feel what a SPI device with *real* ACPI support looks like.

I have double checked the panel-ilitek-ili9341 driver, it doesn't
has acpi_match_table hooked, which means that this driver won't
even be able probed. And probed as pure SPI device still out of
the scope of "correct use of device property APIs". Because SPI
device specific method don't belong to the device property API.
  
I don't really know what's we are missing, but we already intend
to let it go, thanks.


>>> So, slow down and take your time to get into the code and understand how it works.
>>>
>>>> so that the rotation property can not get and ili9341_dpi_probe() will fails.
>>>> So in total, this is not a 100% correct use of device property APIs.
>>>>
>>>> But I'm fine that if you want to leave(ignore) those less frequent use cases temporarily,
>>>> there may have programmers want to post patches, to complete the missing in the future.
>>>>
>>>> So, there do have some gains on non-DT cases.
>>>>
>>>>    - As you make it be able to compiled on X86 with the drm-misc-defconfig.
>>>>    - You cleanup the code up (at least patch 2 in this series is no obvious problem).
>>>>    - You allow people to modprobe it, and maybe half right and half undefined.
>>>>
>>>> But you do helps moving something forward, so congratulations for the wake up.

-- 
Best regards,
Sui

Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs

[Andy Shevchenko]

On Fri, May 03, 2024 at 12:57:33PM +0800, Sui Jingfeng wrote:
> On 2024/5/3 01:28, Andy Shevchenko wrote:
> > On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
> > > On 2024/5/2 16:32, Andy Shevchenko wrote:
> > > > On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> > > > > On 2024/4/30 22:13, Andy Shevchenko wrote:
> > > > > > On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:

...

> > > > > > the former might be subdivided to "is it swnode backed or real fwnode one?"
> > > > > > 
> > > > > Yeah,
> > > > > On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode backed case.
> > > > > 
> > > > >    - For swnode backed case: the device_get_match_data() don't has a implemented backend.
> > > > >    - For ACPI fwnode backed case: the device_get_match_data() has a implemented backend.
> > > > > 
> > > > > But the driver has *neither* software node support
> > > > True.
> > > > 
> > > > > nor ACPI support,
> > > > Not true.
> > > Why this is not true? Are you means that the panel-ilitek-ili9341 driver has ACPI support?
> > That's the idea (as far as I see the copy of the code from tinyDRM),
> > but broken over the copy'n'paste. This patch rectifies that to be
> > in align with the original code, which *does* support ACPI.
> > 
> > > I'm asking because I don't see struct acpi_device_id related stuff in that source file,
> > > am I miss something?
> > Yes, you are. I leave it for you to research.
> 
> After researching a few hours I still don't understand how does
> the panel-ilitek-ili9341 driver has the ACPI support and be able
> to ACPI probed when compiled as module.
> 
> As far as I know, drivers that has the ACPI support *must* has the
> .acpi_match_table hooked, so that be able to be probed when the
> driver is compiled as a module.

No, and this is the thing. Hint: there is a glue code to reuse compatible
strings from OF, that's why dependency to OF prevents *some* systems from
being able to use that. But it's easy to fix by enabling OF in the
configuration, however the ID tables are orthogonal to the environment.
That's why all those ACPI_PTR() and of_match_ptr() are design mistakes
that are going to be removed eventually (the work is ongoing, btw,
as well as killing specific *_device_get_match_data() calls).

> For example, see commit 75a1b44a54bd9 ("spi: tegra210-quad: add acpi support")
> to get a feel what a SPI device with *real* ACPI support looks like.

If under *real* you assume the allocated _HID in use, yes, that's how it's
done. But there is the other tricky way of achieving similar effect w/o
allocating a new / custom ACPI _HID.

Hint: it's all documented in kernel under firmware-guide/acpi/.

> I have double checked the panel-ilitek-ili9341 driver, it doesn't
> has acpi_match_table hooked, which means that this driver won't
> even be able probed. And probed as pure SPI device still out of
> the scope of "correct use of device property APIs". Because SPI
> device specific method don't belong to the device property API.
> I don't really know what's we are missing, but we already intend
> to let it go, thanks.
> 
> > > > So, slow down and take your time to get into the code and understand how it works.
> > > > 
> > > > > so that the rotation property can not get and ili9341_dpi_probe() will fails.
> > > > > So in total, this is not a 100% correct use of device property APIs.
> > > > > 
> > > > > But I'm fine that if you want to leave(ignore) those less frequent use cases temporarily,
> > > > > there may have programmers want to post patches, to complete the missing in the future.
> > > > > 
> > > > > So, there do have some gains on non-DT cases.
> > > > > 
> > > > >    - As you make it be able to compiled on X86 with the drm-misc-defconfig.
> > > > >    - You cleanup the code up (at least patch 2 in this series is no obvious problem).
> > > > >    - You allow people to modprobe it, and maybe half right and half undefined.
> > > > > 
> > > > > But you do helps moving something forward, so congratulations for the wake up.

-- 
With Best Regards,
Andy Shevchenko