> 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.
Attachment:
signature.asc
Description: Digital signature
