[PATCH v4 2/4] mfd: lubbock_cplds: add lubbock IO board

[Nicolas Pitre]

On Tue, 17 Feb 2015, Lee Jones wrote:

> Arnd, Greg,
> 
>   Perhaps you have some ideas WRT programmables (PLDs/CPLDs/FPGAs)?

FWIW...

The Lubbock is an ancient development board (circa 2003) using a CPLD to 
multiplex a couple things on the board.  I really doubt anyone would 
reprogram this CPLD at this point. So I'd treat it just like another 
interrupt controller + random peripherals that will never change.  And 
yes, maybe a more appropriate name is needed.

And I happen to have one such beast on my desk wasting significant 
realestate and picking up dust.  I don't think I booted it even once in 
the last 3 years.  I'm seriously considering a trip to the recycling 
facility to dispose of it unless someone wants it and is ready to pay 
for the shipping.

> On Mon, 16 Feb 2015, Robert Jarzmik wrote:
> > Lee Jones wrote:
> > > What's all this?  Please configure your mail client correctly.
> > >
> > > For advice, see:
> > >
> > >   Documentation/email-clients.txt
> > While at day work, I have only access to web mail ...
> 
> Probably best to hold off your reply until you get home then.  It's
> not just a formatting issue, you also exposed many raw email addresses
> to the internet, which are easily harvested up by web crawlers.
> 
> See this:
>   https://lkml.org/lkml/2015/2/16/247
> 
> > >>  2) after v2, we _both_ agreed that the accurate name is "cplds"
> > >>     which exactly what is in this patch
> > >>     (see device registering with lubbock_cplds).
> > >
> > > There is no mention of this decision in the changelogs.  If it's not
> > > in the change logs, it didn't happen. ;)
> > Ah right.
> > 
> > > I'm still concerned with the fact that the driver file is named using
> > > and is populated by lots of instances of a "board" name.  I'm sure you
> > > would share my thoughts is someone submitted a driver called
> > > beaglebone.c or raspberrypi.c to MFD.
> > I understand your concern. Arnd, a thought about it ? The only viable
> > alternative would be to move it to arch/arm/plat-pxa AFAIS.
> 
> I don't think this is correct either.  CPLD handling would probably be
> slightly less out of place in drivers/misc, but perhaps a new
> subsystem for PLDs/CPLDs/FPGAs would be more appropriate
> drivers/programmables or similar maybe.
> 
> > >> > Besides, this is MFD, where we support single pieces of silicon which
> > >> > happen to support multiple devices.  I definitely don't want to support
> > >> > boards here.
> > >> > You might want to re-think the naming and your (sales) pitch.
> > >> I might need help. As for the (sales), no comment.
> > >
> > > By pitch, I mean to convince me that this belongs in MFD.
> > I've been trying.
> 
> I'm pretty convinced that it doesn't belong in MFD now, but it doesn't
> mean I'm going to leave you on the curb.  I'd like to help you get it
> into a better home.
> 
> [...]
> 
> > > Understanding was lost when I learned that the whole file was centred
> > > around the premise of board support.  I understand now that this is a
> > > driver for a CPLD, which I'm not sure is even MFD.  Also, if it is
> > > really a CPLD driver, shouldn't be named after the manufacturer/model
> > > number of the chip, rather than the PCB which it's connected to?
> > >
> > > I'm also concerned that this driver has no functional CPLD code
> > > contained.  All you're doing is defining an IRQ domain.  Why then
> > > isn't this really an drivers/irqchip (Suggested-by: Josh Cartwright)
> > > driver?
> > Is not only a irqchip because, as explained at the bottom of the commit message,
> > quoting myself :
> >   This patch moves all that handling to a mfd driver. It's only purpose
> >   for the time being is the interrupt handling, but in the future it
> >   should encompass all the motherboard CPLDs handling :
> >    - leds
> >    - switches
> >    - hexleds
> 
> I had a conversation about this on IRC yesterday and some good
> points/questions were posed.  This is a difficult area, because you
> can program these things to do whatever you like.  Depending on the
> 'intention' (and it is only an intention -- someone else can come
> along and reprogram these devices on a whim), the CPLD code could live
> anywhere.  If you wanted to put watchdog functionality in there, then
> there is an argument for it to live in drivers/watchdog, etc etc.  So
> just because the plan is to support a few (i.e. more than one) simple
> devices, it doesn't necessarily mean that the handling should be done
> in MFD.
> 
> Yesterday I was asked "Are you wanting to restrict drivers in
> drivers/mfd to those that make use of MFD_CORE functionality?".  My
> answer to that was "No, however; I only want devices which
> _intrinsically_ operate in multiple subsystems", which these
> programmables no not do.
> 
> FYI, you're not on your own here.  There is at least one of these
> devices in the kernel already and upon a short inspection there
> appears to be a number of Out-of-Tree (OoT) drivers out there which
> will require a home in Mainline sooner or later.
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
>