RE: [PATCH 4/8] of/base.c: export property access/modification functions

[Stephen Neuendorffer <stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>]

> -----Original Message-----
> From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of Grant Likely
> Sent: Friday, July 16, 2010 2:44 PM
> To: Stephen Neuendorffer
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Subject: Re: [PATCH 4/8] of/base.c: export property access/modification functions
> 
> On Fri, Jul 16, 2010 at 2:07 PM, Stephen Neuendorffer
> <stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >
> >> -----Original Message-----
> >> From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of Grant Likely
> >> Sent: Friday, July 16, 2010 11:57 AM
> >> To: Stephen Neuendorffer
> >> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> >> Subject: Re: [PATCH 4/8] of/base.c: export property access/modification functions
> >>
> >> On Fri, Jul 16, 2010 at 12:38 PM, Stephen Neuendorffer
> >> <stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of
> >> > Grant Likely
> >> >> Sent: Friday, July 16, 2010 11:34 AM
> >> >> To: Stephen Neuendorffer
> >> >> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> >> >> Subject: Re: [PATCH 4/8] of/base.c: export property
> >> > access/modification functions
> >> >>
> >> >> On Fri, Jul 16, 2010 at 12:13 PM, Stephen Neuendorffer
> >> >> <stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> >> >> > These functions can be usefully used by device drivers.
> >> >>
> >> >> I'd like a little more description of the intended use case.  What are
> >> >> the circumstances where a driver needs to modify the data (this
> >> >> information should be part of the patch description)?
> >> >
> >> > The PCIPR driver code needs to stuff the ranges property using these
> >> > calls...
> >>
> >> I'd rather change the translation code to give you an intermediary
> >> value (an offset from a bar), and then use non-OF code to translate
> >> that into a physical address.
> >
> > I don't see how that will work, since there is no callback from the device-tree
> > code behind platform_get_resource/of_address_to_resource back into the pcipr driver to
> > do the last translation bit.  I considered having a new 'bus_type' registered in the
> > address translation code that would take care of it, but it seemed to still require
> > the information from somewhere and it wasn't clear where to get it.
> 
> You get the information from the PCI device instance.  We can change
> the bus_type infrastructure to allow instance specific data if need
> be.
> 
> Alternately, the translation could be done at device registration
> time.  With the changes being made to the of code, of_devices are
> going away, and being replaced with normal platform_devices which have
> a resource structure.  We could do the translation at device
> registration time so that drivers only need to look at the resource
> structure.  This will require some changes to the current
> of_platform_drivers, but in the long run I think it is the right thing
> to do.

OK, perhaps I'm being a little dense, but I don't see how to proceed here.
Can you make this more concrete?

Steve


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.