On Wed, Mar 27, 2019 at 12:01 PM Patrick Venture <vent...@google.com> wrote: > > On Wed, Mar 27, 2019 at 11:54 AM Greg KH <gre...@linuxfoundation.org> wrote: > > > > On Wed, Mar 27, 2019 at 11:44:36AM -0700, Patrick Venture wrote: > > > On Wed, Mar 27, 2019 at 11:28 AM Greg KH <gre...@linuxfoundation.org> > > > wrote: > > > > > > > > On Tue, Mar 12, 2019 at 09:31:01AM -0700, Patrick Venture wrote: > > > > > + phys_addr_t mem_base; > > > > > > > > Is this really a 32bit value? > > > > > > It's going to be a 32-bit value if this is in the dts for one of the > > > correspondingly supported aspeed models. > > > > > > > > > > > Your ioctl thinks it is: > > > > > > > > > +struct aspeed_p2a_ctrl_mapping { > > > > > + __u32 addr; > > > > > > > > Does this driver not work on a 64bit kernel? > > > > > > This driver is aimed at only 32-bit hardware (ast2400/2500). I > > > modeled the approach after the aspeed-lpc-ctrl driver as it's > > > providing similar functionality. > > > > > > > > > > > > + __u32 length; > > > > > + __u32 flags; > > > > > +}; > > > > > > > > addr really should be __u32 here so you don't have to mess with 32/64 > > > > bit user/kernel issues, right? > > > > > > Add is __u32 there. Are you suggesting it shouldn't be? > > > > Ugh, yes, sorry, I meant to say "__u64". > > > > If you all insist that this is all that is ever going to be needed, ok, > > but I reserve the right to complain in 4 years when this needs to be > > changed :) > > In the event the ast2600 comes out and is 64-bit -- I can't imagine > that's likely to happen. I can take solace that this won't be the > only thing that needs retrofitting. But it wouldn't kill me to just > make the change. I'll just have to tweak it to return failure in the > event the address provided isn't found in any region... > > Is that all that needs to change for 64-bit addressing support - given > your read of the driver?
I should have v8 for review shortly. > > > > > thanks, > > > > greg k-h