lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPY8ntBkKebzCM8uG0=YN_XngWS=Kgmgs_LBXmJb1nY3uPEWUw@mail.gmail.com>
Date:   Tue, 28 Apr 2020 17:19:38 +0100
From:   Dave Stevenson <dave.stevenson@...pberrypi.com>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Stefan Wahren <stefan.wahren@...e.com>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Eric Anholt <eric@...olt.net>,
        Tim Gover <tim.gover@...pberrypi.com>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel@...ts.freedesktop.org,
        bcm-kernel-feedback-list@...adcom.com,
        linux-rpi-kernel@...ts.infradead.org,
        Phil Elwell <phil@...pberrypi.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 79/91] drm/vc4: hdmi: Deal with multiple debugfs files

Hi Stefan and Maxime

On Tue, 28 Apr 2020 at 16:57, Maxime Ripard <maxime@...no.tech> wrote:
>
> Hi Stefan,
>
> On Sat, Apr 25, 2020 at 11:26:31PM +0200, Stefan Wahren wrote:
> > Am 24.04.20 um 17:35 schrieb Maxime Ripard:
> > > The HDMI driver was registering a single debugfs file so far with the name
> > > hdmi_regs.
> > >
> > > Obviously, this is not going to work anymore when will have multiple HDMI
> > > controllers since we will end up trying to register two files with the same
> > > name.
> > >
> > > Let's use the ID to avoid that name conflict.
> >
> > even with this patch there is a name conflict in debugfs using Linux
> > 5.7-rc1. Dave Stevenson addressed this by using different card names
> > [1]. Since this patch won't apply anymore here is my suggestion:
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 29287ab..7209397 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -1181,9 +1181,14 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi
> > *vc4_hdmi)
> >
> >      card->dai_link = dai_link;
> >      card->num_links = 1;
> > -    card->name = "vc4-hdmi";
> >      card->dev = dev;
> >
> > +    if (vc4_hdmi->variant->encoder_type == VC4_ENCODER_TYPE_HDMI1) {
> > +        card->name = "vc4-hdmi1";
> > +    } else {
> > +        card->name = "vc4-hdmi";
> > +    }
> > +
>
> Thinking about this some more, we don't really need VC4_ENCODER_TYPE_HDMI0 and
> HDMI1, and it can all work with the same encoder type for both, so I'll drop
> them.
>
> To address this issue though, we can add a card name string to the variant, like
> I did for debugfs. Is that alright for you?

My patch doesn't fix everything with the audio debugfs entries anyway.
I'm working against 5.4 on our downstream tree, and even with my patch
I get
[    7.459508] debugfs: Directory 'fef00700.hdmi' with parent
'vc4-hdmi' already present!
[    7.511017] debugfs: Directory 'fef05700.hdmi' with parent
'vc4-hdmi1' already present!
I seem to recall I reduced the number of complaints over 'vc4-hdmi',
but internal to sound/soc-core the node is still registered twice.

There was discussion about this a few months back.
https://lore.kernel.org/lkml/1jblpvraho.fsf@starbuckisacylon.baylibre.com/
seemed to conclude that it wasn't totally trivial to solve.

Regards,
  Dave

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ