----- Original Message ----- > From: "Dan Carpenter" <dan.carpenter@xxxxxxxxxx> > To: "Alessio Igor Bogani" <alessioigorbogani@xxxxxxxxx> > Sent: Tuesday, May 3, 2016 8:18:38 AM > > On Tue, May 03, 2016 at 02:52:54PM +0200, Alessio Igor Bogani wrote: > > Dan, > > > > On 30 April 2016 at 12:16, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > On Fri, Apr 29, 2016 at 04:41:02PM -0500, Aaron Sierra wrote: > > >> There appear to be no in-kernel callers of vme_lm_attach (or > > >> vme_lme_request for that matter), so this change only affects the VME > > >> subsystem and bridge drivers. > > > > > > Are we planning to add in-kernel users soon? > > > > It would be great since we have a lot of VME drivers (for devices not > > for bridges) which we would like see mainlined. > > Unfortunately, considering the limitations of the current VME stack > > implementation, submit these is almost useless. > > What do we need to do to make it better? I'm interested to hear Alessio's thoughts; these are my own. The biggest challenge that I've found in developing VME drivers is defining and maintaining VME resource assignments across intelligent hosts. I've made a proof-of-concept Open Firmware layer for VME that enables a bridge's resources (inbound/outbound windows, IRQs, LMs, and outbound IRQs) to be defined concisely and allocated to child nodes (platform devices) from a single text file (later compiled into a DTB). This could be generally useful and allow each board's view of the bus to be more easily defined and maintained. I tested on PowerPC, but think it could also work on x86 now that it's device-tree capable. This resulted in my VME device driver requiring very little VME-awareness. -Aaron S. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
