As discussed on linux PCI, these 2 patches:
- Add a dev_sysdata structure to struct device whose content is arch
specific. It will allow architectures like powerpc, arm, i386, ... who
need different types of DMA ops for busses and other kind of auxilliary
data for devices in general (numa node id, firmware data, etc...) to put
them in there, without bloating all architectures. The patch adds an
empty definition for the structure to all architectures.
- As an example (patch test built but not test booted), I removed ACPI
usage of device->firmware_data, removed the firmware_data field
completely from struct device (as it was, apparently, the only user),
and instead used an "acpi_handle" field in x86 and x86_64 dev_sysdata.
I'd like to adapt my pending 2.6.20 patch set to use that instead of my
current "device_ext" thingy I've been doing, but that would mean having
an ack from Greg to merge the first patch in 2.6.20. Thus I'd like
feedback asap. The second patch is less critial, though Len is free to
take it and do whatever he wants with it :-)
Cheers,
Ben.
On Thu, 09 Nov 2006 11:45:21 +1100,
Benjamin Herrenschmidt <[email protected]> wrote:
> - Add a dev_sysdata structure to struct device whose content is arch
> specific. It will allow architectures like powerpc, arm, i386, ... who
> need different types of DMA ops for busses and other kind of auxilliary
> data for devices in general (numa node id, firmware data, etc...) to put
> them in there, without bloating all architectures. The patch adds an
> empty definition for the structure to all architectures.
I like this. If we could move the dma stuff in there, we could get rid
of it on s390 where it is just bloat we drag around...
(Maybe dev_archdata would be a better name, since the definition is
architecture specific?)
--
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [email protected]
On Thu, 2006-11-09 at 17:04 +0100, Cornelia Huck wrote:
> On Thu, 09 Nov 2006 11:45:21 +1100,
> Benjamin Herrenschmidt <[email protected]> wrote:
>
> > - Add a dev_sysdata structure to struct device whose content is arch
> > specific. It will allow architectures like powerpc, arm, i386, ... who
> > need different types of DMA ops for busses and other kind of auxilliary
> > data for devices in general (numa node id, firmware data, etc...) to put
> > them in there, without bloating all architectures. The patch adds an
> > empty definition for the structure to all architectures.
>
> I like this. If we could move the dma stuff in there, we could get rid
> of it on s390 where it is just bloat we drag around...
>
> (Maybe dev_archdata would be a better name, since the definition is
> architecture specific?)
Hrm... I wonder why I posted from my IBM address :-) I have no firm
preference on the name of the structure. So far, I had no feedback on
that patch at all appart from yours though.
Andrew, Greg ? Is that something you would take for 2.6.20 ? I need to
know wether I should rework my patches to use that or stick to my hacks
involving hijacking firmware_data.
Cheers,
Ben.
On Fri, Nov 10, 2006 at 09:35:37AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2006-11-09 at 17:04 +0100, Cornelia Huck wrote:
> > On Thu, 09 Nov 2006 11:45:21 +1100,
> > Benjamin Herrenschmidt <[email protected]> wrote:
> >
> > > - Add a dev_sysdata structure to struct device whose content is arch
> > > specific. It will allow architectures like powerpc, arm, i386, ... who
> > > need different types of DMA ops for busses and other kind of auxilliary
> > > data for devices in general (numa node id, firmware data, etc...) to put
> > > them in there, without bloating all architectures. The patch adds an
> > > empty definition for the structure to all architectures.
> >
> > I like this. If we could move the dma stuff in there, we could get rid
> > of it on s390 where it is just bloat we drag around...
> >
> > (Maybe dev_archdata would be a better name, since the definition is
> > architecture specific?)
>
> Hrm... I wonder why I posted from my IBM address :-) I have no firm
> preference on the name of the structure. So far, I had no feedback on
> that patch at all appart from yours though.
>
> Andrew, Greg ? Is that something you would take for 2.6.20 ? I need to
> know wether I should rework my patches to use that or stick to my hacks
> involving hijacking firmware_data.
Sorry, I'm in Japan this week, and access to email is limited.
I like this change, but I like the dev_archdata name better. It lets
people know who owns the pointer much better.
Care to respin these patches with this change?
And yes, I don't see a problem with such a change like this for 2.6.20,
it's pretty simple.
thanks,
greg k-h
> Sorry, I'm in Japan this week, and access to email is limited.
>
> I like this change, but I like the dev_archdata name better. It lets
> people know who owns the pointer much better.
>
> Care to respin these patches with this change?
Ok, changing that should be trivial, I'll send new patches tomorrow.
> And yes, I don't see a problem with such a change like this for 2.6.20,
> it's pretty simple.
Excellent, thanks, Hope your trip was good
(I loved the food last time I was in Tokyo :-)
Cheers,
Ben.
Greg KH writes:
> Care to respin these patches with this change?
>
> And yes, I don't see a problem with such a change like this for 2.6.20,
> it's pretty simple.
I need to put Ben's "Add arch specific dev_archdata to struct device"
patch into my tree in the for-2.6.20 branch, because it creates
include/asm-powerpc/device.h, and I have other patches queued up which
touch include/asm-powerpc/device.h.
Greg, if you want you can drop that patch, and Linus' tree will get it
via my tree, or if that's difficult, Linus' tree will get it from both
directions. I'm sure git will sort it out. :)
Paul.
On Mon, 2006-11-13 at 16:17 +1100, Paul Mackerras wrote:
> Greg KH writes:
>
> > Care to respin these patches with this change?
> >
> > And yes, I don't see a problem with such a change like this for 2.6.20,
> > it's pretty simple.
>
> I need to put Ben's "Add arch specific dev_archdata to struct device"
> patch into my tree in the for-2.6.20 branch, because it creates
> include/asm-powerpc/device.h, and I have other patches queued up which
> touch include/asm-powerpc/device.h.
>
> Greg, if you want you can drop that patch, and Linus' tree will get it
> via my tree, or if that's difficult, Linus' tree will get it from both
> directions. I'm sure git will sort it out. :)
Greg: Note that the patch paulus has is the respin I posted on Saturday
with the name change and the use of include/asm-generic/ as suggested by
Steven.
Ben.