Subject: Re: [PATCH v2] i2c: Driver to expose PowerNV platform i2c busses

From: Wolfram Sang <[email-masked]>
Date: Mon, 1 Dec 2014 17:56:24 +0100

> Suuure, let's create more process and committees, and make sure nothing
> gets done in any reasonable amount of time. Have we gone completely
> insane ?

I did not invent DT bindings. I did not invent that DT is/should be a
hardware description. For me, it is a burden that I (as a subsystem
maintainer for mainly drivers) have to prevent people from using DT for
software configuration (some people use it as an 1:1 mapping for
platform data even.) Since there are no guidelines (probably there can't
be), I developed a set of rules out of experience and when those don't
match I ask for help. Having a different set of rules for
powerpc/arm/... (or server/embedded for that matter) will increase this
burden a lot. People will come and say "But they did it as well..."

> It's getting quite tempting to just throw that driver into powerpc.git

Maybe this is the easiest. Just make sure that MAINTAINERS also point
this driver to you or PowerNV maintainers. And no Ack from me, please.
Then, I can always say "I dunno" if people start asking questions.

> > > +	pname = of_get_property(pdev->dev.of_node, "ibm,port-name", NULL);
> > > +	if (pname)
> > > +		strlcpy(adapter->name, pname, sizeof(adapter->name));
> > > +	else
> > > +		strlcpy(adapter->name, "opal", sizeof(adapter->name));
> > 
> > ... because I'd like to get an ack from them because of this binding.
> 
> And I don't give a flying crap about what random ARM SOC vendor thinks
> of my powerpc FW interface for a powerpc unique FW interface.

But you are not alone here. If you open the box for giving busses a
configurable name, I can see other people (without FW) wanting this,
too. So, this discussion will come anyhow IMO.