Source code organization

[Billie Alsup (balsup)]

> From: Greg KH <greg at kroah.com>
>        - is this something else?  Then pick a place and submit a patch
>          and people will tell you if you got it wrong :)

I think this is going to be my strategy, except per a separate recommendation,
I will put it in drivers/platform/cisco, similar to the existing chrome, goldfish,
mellanox, and surface already under drivers/platform.  These drivers really
are Cisco hardware specific, so I'd like to keep them grouped together,
if reviewers will allow it!

> But step back, why are you creating MFD devices anyway?  Why not make
> "real" devices in your hardware representation as you control the FPGA
> and DT definitions, right?

Currently the FPGAs themselves are discovered (for pci bus), or explicitly
instantiated (for i2c, whether via user mode script, device tree, or
ACPI configuration).  The slpc and p2pm MFD drivers also "discover"
the peer FPGA. Are you suggesting that I create a new bus driver
for a Cisco FPGA?  I was under the impression that the MFD framework
was explicitly meant for this type of application.  I do dynamically
create the array of struct mfd_cell passed to devm_mfd_add_devices
(versus having an fpga specific driver), which achieves the same 
purpose as a bus driver (I think).  It's just that I thought MFD framework
was meant for this type of application, and that's what I went with.
The drivers themselves have been written over the last several years
(starting with use in ONIE and SONiC, and now being used with FBOSS).  It
is only now that I have been authorized to make the source public.  Changing
to a bus driver top layer would seem to be a very big change.  There
are 30 or so drivers being used today with Cisco FPGAs, and
that number will only grow over time.

> Do that, then you can put your fpga interface in drivers/fpga :)

I will have to look into this more.  I don't think I can make such a
drastic change at this time, but it might be something we can put
on the roadmap if that is the right approach architecturally.  The code
is organized with a separation of layers already, so it
should be doable.  

Thanks for your feedback!