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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100315192754.GE4536@sci.fi>
Date:	Mon, 15 Mar 2010 21:27:54 +0200
From:	Ville Syrjälä <syrjala@....fi>
To:	Jordan Crouse <jcrouse@...eaurora.org>
Cc:	dri-devel@...ts.sourceforge.net, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm: Allow platform devices to register as DRM devices

On Mon, Mar 01, 2010 at 09:00:09AM -0700, Jordan Crouse wrote:
> 
> Allow platform devices without PCI resources to be DRM devices.

I really dislike the fact that drm has bus specific junk all over the
generic code. Some ideas how to clean that up:

Add 'struct device *dev' into drm_device so you don't have to go through
the pdev/platformdev to get it every time. Also use dev_name() instead
of pci_name() and whatever you used for the platform device case.

Add 'int irq' into struct drm_device instead of adding more bus specific
hoops to get at the irq. Not sure I like the generic code mucking about
with the irq directly though but baby steps are easier to handle.

Get rid of the drm_resource_start/len wrappers. AFAICS they're all called
from the low level driver code anyway and the driver knows the bus type
so there's no need for the wrappers.

It would be nice to get the struct pci_driver out of the the drm_driver
structure. Since you now have a new pci specific drm_get_dev() thing
could you also pass the pci_driver as a function parameter instead
of having it live inside the drm_driver?

Also all cases where there's some PCI specific stuff (the busid stuff
mostly) you could just check the drm_device.pdev pointer instead of
having to add another driver flags to identify non-PCI devices. Although
I don't really like having the pdev/platformdev pointers in there at all.

That's sort of my secret drm TODO list but so far didn't have the time
to actually do the coding part.

-- 
Ville Syrjälä
syrjala@....fi
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ