All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Douglas Anderson <dianders@chromium.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>, Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	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>,
	dri-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi86: Fix multiple instances
Date: Fri, 18 Oct 2024 16:31:21 +0200	[thread overview]
Message-ID: <2024101837-crushed-emphasis-b496@gregkh> (raw)
In-Reply-To: <20241018142522.GA28934@pendragon.ideasonboard.com>

On Fri, Oct 18, 2024 at 05:25:22PM +0300, Laurent Pinchart wrote:
> Hi Greg,
> 
> On Fri, Oct 18, 2024 at 04:09:26PM +0200, Greg KH wrote:
> > On Fri, Oct 18, 2024 at 03:36:48PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Oct 18, 2024 at 3:10 PM Laurent Pinchart wrote:
> > > > On Fri, Oct 18, 2024 at 09:45:52AM +0200, Geert Uytterhoeven wrote:
> > > > > Each bridge instance creates up to four auxiliary devices with different
> > > > > names.  However, their IDs are always zero, causing duplicate filename
> > > > > errors when a system has multiple bridges:
> > > > >
> > > > >     sysfs: cannot create duplicate filename '/bus/auxiliary/devices/ti_sn65dsi86.gpio.0'
> > > > >
> > > > > Fix this by using a unique instance ID per bridge instance.
> > > >
> > > > Isn't this something that should be handled by the AUX core ? The code
> > > > below would otherwise need to be duplicated by all drivers, which seems
> > > > a burden we should avoid.
> > > 
> > > According to the documentation, this is the responsibility of the caller
> > > https://elixir.bootlin.com/linux/v6.11.4/source/include/linux/auxiliary_bus.h#L81
> > > I believe this is the same for platform devices.
> > > See also the example at
> > > https://elixir.bootlin.com/linux/v6.11.4/source/include/linux/auxiliary_bus.h#L116
> > > 
> > > Note: the platform bus supports PLATFORM_DEVID_AUTO, but the auxiliary
> > > bus does not.
> > 
> > Yes, it does not as it's up to the caller to create a unique name, like
> > your patch here does.  I'd argue that platform should also not do
> > automatic device ids, but that's a different argument :)
> 
> __auxiliary_device_add() creates the device name with
> 
> 	dev_set_name(dev, "%s.%s.%d", modname, auxdev->name, auxdev->id);
> 
> I'm not calling for a PLATFORM_DEVID_AUTO-like feature here, but
> shouldn't the first component of the device name use the parent's name
> instead of the module name ?

Why would the parent's name not be the module name?  That name is
guaranteed unique in the system.  If you want "uniqueness" within the
driver/module, use the name and id field please.

That's worked well so far, but to be fair, aux devices are pretty new.
What problem is this naming scheme causing?

thanks,

greg k-h

  reply	other threads:[~2024-10-18 14:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-18  7:45 [PATCH] drm/bridge: ti-sn65dsi86: Fix multiple instances Geert Uytterhoeven
2024-10-18 13:10 ` Laurent Pinchart
2024-10-18 13:36   ` Geert Uytterhoeven
2024-10-18 14:09     ` Greg KH
2024-10-18 14:25       ` Laurent Pinchart
2024-10-18 14:31         ` Greg KH [this message]
2024-10-20 14:36           ` Laurent Pinchart
2024-10-21  6:39             ` Greg KH
2024-10-21  6:58               ` Geert Uytterhoeven
2024-10-21  7:27                 ` Greg KH
2024-10-21  8:23                   ` Geert Uytterhoeven
2024-10-21  8:28                     ` Laurent Pinchart
2024-10-21  8:47                     ` Geert Uytterhoeven
2024-10-22  0:20                       ` Doug Anderson
2024-10-22  7:11                         ` Geert Uytterhoeven
2024-10-22 14:37                           ` Doug Anderson
2024-10-28 13:34                             ` Dmitry Baryshkov
2024-10-30 10:25                               ` Geert Uytterhoeven
2024-10-30 10:28                                 ` Laurent Pinchart
2024-10-31 23:08                                   ` Dmitry Baryshkov

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=2024101837-crushed-emphasis-b496@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.