mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@kernel.org>
To: Svyatoslav Ryhel <clamor95@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	 Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	 David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>, Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Jonathan Hunter <jonathanh@nvidia.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	 Jessica Zhang <jesszhan0024@gmail.com>,
	Mikko Perttunen <mperttunen@nvidia.com>,
	 dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 01/10] drm: Add MIPI DBI bus support for MIPI DBI Type A and B
Date: Fri, 6 Nov 2026 16:19:37 +0100	[thread overview]
Message-ID: <au3telUE9A43PDWv@orome> (raw)
In-Reply-To: <CAPVz0n3_oRz8aMr1W=8K7dnHhM=vuGpHjpq6+=80oXiFj5wfSg@mail.gmail.com>

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

On Fri, Nov 06, 2026 at 03:59:05PM +0200, Svyatoslav Ryhel wrote:
> пт, 6 лист. 2026 р. о 15:14 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Thu, Nov 05, 2026 at 04:05:01PM +0200, Svyatoslav Ryhel wrote:
> > [...]
> > > diff --git a/drivers/gpu/drm/drm_mipi_dbi_bus.c b/drivers/gpu/drm/drm_mipi_dbi_bus.c
> > [...]
> > > +/**
> > > + * devm_mipi_dbi_device_register() - create a managed MIPI DBI device
> > > + * @dev: device to tie the MIPI-DBI device lifetime to
> > > + * @host: DBI host to which this device is connected
> > > + * @np: device tree node associated with the panel MIPI DBI device
> > > + *
> > > + * This function is called by DBI host driver to create panel device.
> > > + * It automatically calls mipi_dbi_device_unregister() when @dev is
> > > + * unbound. It does not automatically free passed device node pointer,
> > > + * it must be put manually.
> > > + *
> > > + * Returns:
> > > + * A pointer to the newly created MIPI DBI device, or, a pointer encoded
> > > + * with an error.
> > > + */
> > > +struct mipi_dbi_device *
> > > +devm_mipi_dbi_device_register(struct device *dev, struct mipi_dbi_host *host,
> > > +                           struct device_node *np)
> > > +{
> > > +     struct mipi_dbi_device *dbidev;
> > > +     int ret;
> > > +
> > > +     if (!host || !host->dev || !host->dbi || !host->dbi->command ||
> > > +         !host->ops || !host->ops->attach || !host->ops->detach || !np)
> > > +             return ERR_PTR(-EINVAL);
> >
> > Do we want dev->of_node to serve as a fallback for !np?
> >
> 
> No we don't dev->of_node is hosts node, and np is panel node.

Fair enough. The parameter name is a bit generic, but I guess if you
read the documentation it becomes clearer what it means.

> > > +
> > > +     if (!of_device_is_available(np))
> > > +             return ERR_PTR(-ENODEV);
> > > +
> > > +     dbidev = kzalloc_obj(*dbidev);
> > > +     if (!dbidev)
> > > +             return ERR_PTR(-ENOMEM);
> > > +
> > > +     if (of_node_test_and_set_flag(np, OF_POPULATED)) {
> > > +             kfree(dbidev);
> > > +             return ERR_PTR(-EBUSY);
> > > +     }
> > > +
> > > +     dbidev->host = host;
> > > +     dbidev->dbi = host->dbi;
> > > +     device_initialize(&dbidev->dev);
> > > +     dbidev->dev.parent = host->dev;
> > > +     dbidev->dev.bus = &mipi_dbi_bus_type;
> > > +     dbidev->dev.release = mipi_dbi_device_release;
> > > +     device_set_node(&dbidev->dev, of_fwnode_handle(of_node_get(np)));
> > > +
> > > +     ret = dev_set_name(&dbidev->dev, "%s:%s", dev_name(host->dev), np->full_name);
> > > +     if (ret)
> > > +             goto put_device;
> > > +
> > > +     ret = device_add(&dbidev->dev);
> > > +     if (ret)
> > > +             goto put_device;
> > > +
> > > +     ret = devm_add_action_or_reset(dev, mipi_dbi_device_unregister,
> > > +                                    &dbidev->dev);
> > > +     if (ret)
> > > +             return ERR_PTR(ret);
> > > +
> > > +     return dbidev;
> > > +
> > > +put_device:
> > > +     of_node_clear_flag(np, OF_POPULATED);
> > > +     put_device(&dbidev->dev);
> > > +     return ERR_PTR(ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(devm_mipi_dbi_device_register);
> >
> > Don't we need to of_node_put() here on failure? Otherwise we're leaking
> > the reference that we obtained inside the device_set_node() argument.
> >
> 
> This is fully repeats device_register logic of drm_mipi_dsi.c so
> unless DSI framework has leak, this should be correct

Nobody said that drm_mipi_dsi.c is correct. I'm reviewing this patch and
it seems like it's wrong. If drm_mipi_dsi.c does the same thing it
probably is wrong, too.

> > > +static int mipi_dbi_drv_remove(struct device *dev)
> > > +{
> > > +     struct mipi_dbi_driver *drv = to_mipi_dbi_driver(dev->driver);
> > > +     struct mipi_dbi_device *dbidev = to_mipi_dbi_device(dev);
> > > +
> > > +     drv->remove(dbidev);
> > > +
> > > +     return 0;
> > > +}
> >
> > Might as well make drv->remove() return an error and propagate that
> > here.
> >
> 
> Have you even checked the code? remove() callback is and should be void.

I don't know what you're trying to say here. Yes I can see that the
remove callback returns void. My point is that device_driver.remove does
*not* return void and since this is merely a wrapper around it for DBI
it could also just return int for symmetry.

But there's also continuous work trying to convert all driver remove
callbacks to return void, so that's eventually going to get "fixed" here
anyway, so might as well leave it like this.

Thierry

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

  reply	other threads:[~2026-11-06 15:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 14:05 [PATCH v6 00/10] drm/tegra: Add support for Tegra20/Tegra30 8-bit CPU interface Svyatoslav Ryhel
2026-11-05 14:05 ` [PATCH v6 01/10] drm: Add MIPI DBI bus support for MIPI DBI Type A and B Svyatoslav Ryhel
2026-11-06 13:14   ` Thierry Reding
2026-11-06 13:59     ` Svyatoslav Ryhel
2026-11-06 15:19       ` Thierry Reding [this message]
2026-11-05 14:05 ` [PATCH v6 02/10] drm/panel: Convert Hitachi TX10D07VM0BAA to use MIPI DBI bus Svyatoslav Ryhel
2026-11-06 13:19   ` Thierry Reding
2026-11-06 14:00     ` Svyatoslav Ryhel
2026-11-06 15:26       ` Thierry Reding
2026-11-05 14:05 ` [PATCH v6 03/10] drm/panel: Convert LG LH400WV3-SD04 " Svyatoslav Ryhel
2026-11-06 13:23   ` Thierry Reding
2026-11-06 14:01     ` Svyatoslav Ryhel
2026-11-05 14:05 ` [PATCH v6 04/10] drm/tegra: dc: Refactor and expand header Svyatoslav Ryhel
2026-11-06 13:56   ` Thierry Reding
2026-11-06 14:06     ` Svyatoslav Ryhel
2026-11-05 14:05 ` [PATCH v6 05/10] dt-bindings: display: tegra: Document Tegra20 DSI port Svyatoslav Ryhel
2026-11-06 14:16   ` Rob Herring (Arm)
2026-11-05 14:05 ` [PATCH v6 06/10] drm/tegra: Make panel parsing by tegra_output_probe() optional Svyatoslav Ryhel
2026-11-06 14:00   ` Thierry Reding
2026-11-06 14:09     ` Svyatoslav Ryhel
2026-11-06 15:34       ` Thierry Reding
2026-11-05 14:05 ` [PATCH v6 07/10] drm/tegra: Convert to use atomic versions of drm_encoder_helper_funcs Svyatoslav Ryhel
2026-11-05 14:05 ` [PATCH v6 08/10] drm/tegra: rgb: Parameterize configuration based on bus flags Svyatoslav Ryhel
2026-11-05 14:05 ` [PATCH v6 09/10] dt-bindings: display: tegra: Document 8-bit CPU parallel interface Svyatoslav Ryhel
2026-11-05 22:58   ` Rob Herring (Arm)
2026-11-06 14:08   ` Thierry Reding
2026-11-06 14:11     ` Svyatoslav Ryhel
2026-11-06 14:40       ` Thierry Reding
2026-11-06 14:48         ` Svyatoslav Ryhel
2026-11-06 15:51           ` Thierry Reding
2026-11-05 14:05 ` [PATCH v6 10/10] drm/tegra: Add support for 8-bit CPU interface Svyatoslav Ryhel
2026-11-06 14:38   ` Thierry Reding
2026-11-06 14:53     ` Svyatoslav Ryhel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=au3telUE9A43PDWv@orome \
    --to=thierry.reding@kernel.org \
    --cc=airlied@gmail.com \
    --cc=clamor95@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jesszhan0024@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mperttunen@nvidia.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®