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-next>] [day] [month] [year] [list]
Date:	Tue, 10 Oct 2006 13:36:08 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Greg KH <greg@...ah.com>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: driver,platform,firmware,system, data data data ....

Hi Greg !

I'm in need of something around the lines of pci "sysdata" but
generically (for all devices). So I had a look, and noticed that in
struct device, we have already 3 "data":

 - driver_data (ok, that one we know all about)
 - firmware_data (just discovered it, I already know what to use it
for :)
 - platform_data (ugh ?)

It's my understanding that the later is for use by platform drivers,
right ?

So except for the size of the patch and boredom of going through all of
them fixing them, do you see any reason why this later one shouldn't be
moved out to platform_driver ? (I haven't actually checked at all the
occurences in the tree though).

On the other hand, we have in pci_dev

 - sysdata (ok, let's call it system_data)

Which I would quite like to see in struct device instead :)

The reason is that I have to deal with setups with multiple iommu's and
non-PCI devices. The current powerpc infrastructure for findign the
right iommu for dma_ops tests various bus types (pci and vio for now for
pci and virtual ios) and get the right data structure defined by each of
these (in sysdata for pci, some other field for vio) to get the iommu
table pointer.

Now, with more non-pci bus types coming in, and the advent of some
platform-like OF (open firmware probed) devices, we end up with more of
these bus types and a fairly complicated situation to get to the iommu.
Since it's a fairly hot path, I'm not happy comparing the bus type with
3 or more types and going looking at various bus specific data
structures to find it.

Thus I want a arch-wide data structure that can be attached to any
struct device to carry the iommu table pointer (and maybe a couple of
other things in the future but it's mostly that for now).

Thus that would be a nice fit for a system_data there (and since that's
what we use sysdata in pci_dev for, basically, remove the later).

As a temporary measure, I'll hijack firmware_data which isn't used for
anything on powerpc at the moment (though I'd like to use it in the
future for a pointer to the OF device node if any).

Any comments on the approach ? If you are ok, I'll look into doing the
tedious work of converting the whole tree to those 2 changes (moving
platform_data to platform_driver and pci sysdata to generic system_data)
and cook some patches for after 2.6.19.

Cheers,
Ben.


-
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