linux-kernel - Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci

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: <Y7/kw+JdGCHJdptI@phenom.ffwll.local>
Date:   Thu, 12 Jan 2023 11:45:23 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Thomas Zimmermann <tzimmermann@...e.de>
Cc:     DRI Development <dri-devel@...ts.freedesktop.org>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH 02/11] drm/gma500: Use
 drm_aperture_remove_conflicting_pci_framebuffers

On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 12.01.23 um 10:59 schrieb Daniel Vetter:
> > On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
> > > Hi
> > > 
> > > Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> > > > This one nukes all framebuffers, which is a bit much. In reality
> > > > gma500 is igpu and never shipped with anything discrete, so there should
> > > > not be any difference.
> > > > 
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@...el.com>
> > > > ---
> > > >    drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
> > > > index cd9c73f5a64a..9b0daf90dc50 100644
> > > > --- a/drivers/gpu/drm/gma500/psb_drv.c
> > > > +++ b/drivers/gpu/drm/gma500/psb_drv.c
> > > > @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> > > >    	 * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
> > > >    	 *       might be able to read the framebuffer range from the device.
> > > >    	 */
> > > > -	ret = drm_aperture_remove_framebuffers(true, &driver);
> > > > +	ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
> > > 
> > > This does not work. The comment just above the changed line explains why.
> > > The device uses shared memory similar to other integrated Intel chips. The
> > > console is somewhere in a 16 MiB range, which has been stolen by the BIOS
> > > from main memory. There's only a 1 MiB memory range on the device to program
> > > the device. Unless you want to refactor as described, this call has to cover
> > > the whole memory for now.
> > 
> > Uh. So it's maybe not so pretty, but what if I just call both functions?
> 
> That's ways more ugly IMHO.
> 
> > That way we get the vga handling through the pci one, and the "make sure
> > there's no fb left" through the other one. Plus comment of course.
> > 
> > Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
> > and that just feels all kinds of wrong to me.
> 
> With your patch applied, aperture_detach_devices() does all the work of
> removing. I'd add the following internal functions:
> 
> static void aperture_detach_head(bool is_primary)
> {
> 	/*
> 	 * lengthy comment here
> 	 */
> 	if (is_primary)
> 		sysfb_disable()
> }
> 
> static void aperture_detach_tail(bool remove_vga)
> {
> 	if (remove_vga) {
> 		aperture_detach_devices(VGA_PHYS_)
> 		vga_remove_vgacon()
> 	}
> }
> 
> And call both of them at the beginning/end of
> aperture_remove_conflicting_devices() and
> aperture_remove_conflicting_pci_devices().
> 
> You'd still need to primary argument to
> aperture_remove_conflicting_devices(), but there will be no code duplication
> with the aperture helpers and the purpose of each code fragment will be
> clearer.

Yeah I don't want the primary argument. Aside from this one case here it's
not needed. Also by pushing this special case into the one driver that
needs it we keep it contained, instead of spreading it all around.
Inflicting a parameter on every (and in total we have a lot of callers of
this stuff) just because of gma500 does not seem like a good idea to me.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch